Y and Z specs

[Legacy User]

Question of the moment:

We are using more and more the Z and Y specs to control compilations. But we are discovering a problem. For change control we use the ALDON/MoM software. When a promotion is submitted it can be 1 to x objects. The problem comes up with Y specs. Because the compilation is running in one job, any Y specs that occur in the second to x programs don't execute until after the compilation. This can be a real problem with the task is to add a library list entry.

Has anyone come across this before or have any Ideas?

Eamonn.

[Anon Anon]

Hello Community!

Any answers for Eamonn's question of the moment?

Thanks!
Mary

[Anon Anon]

Eamonn.

Are these Y specs after or before the Z specs (in a given source member)?

For instance, if you have this:

SRCMBR1

Y* SNDMSG('1. Precompile SRCMBR1') TOUSR(EAMONN)
Z* CRTBNDRPG
Y* SNDMSG('2. Postcompile SRCMBR1') TOUSR(EAMONN)

SRCMBR2

Y* SNDMSG('3. Precompile SRCMBR2') TOUSR(EAMONN)
Z* CRTBNDRPG
Y* SNDMSG('4. Postcompile SRCMBR2') TOUSR(EAMONN)

How do the messages get processed? Is it 1, then both compilations, then 2, 3 and 4 all together?

I'm surprised this is happening though - has it always been this way? We made some major changes to the compile preprocessor in r8.5 - I have attached a document whioch explains them (this was incorporated into the r8.5 user manuals, but I find it's easier to keep a copy handy). Of interest here is the "Integration with CA 2E using EXCUSRSRC" section at the end - have you seen this?

If necessary, please raise an issue and we can take a look. I'm off for a 4-day weekend, but I'll check in next week on this.

Regards,

Rory

Attachment(s)

Enhanced functionality within the CA 2E 400 Toolkit compi...doc   79 KB 1 version

[Anon Anon]

Eamonn,

Just a thought (not directly related to your current problem):

I was struck by this: "We are using more and more the Z and Y specs to control compilations."

Have you used (or considered using) the new X directive in your EXCUSRSRC - it allows you to create default commands which can be grouped together. I'm not talking about the 'old' X directives (which generate as Y directives after any Z directives). Read the document I sent in my previous post about the new X directive, if you don't know about it.

It may not help with the problem you're experiencing right now, but if you are indeed using lots of Z and Y directives, this might make things slightly easier to handle, as well as not ending up with loads of compile preprocessor directives at the top of your source members...

Rory

[Gary Haut]

G'day all

I think I have the same (or very similar) issue. I will be opening a issue request shortly with more details.

In short, our pre-compile *Y directives are not working during the CM promotion process. 
We are using CM Implementor 2010. This also fails using Implementor 10.2, which we have installed but is still under review and not released to the full development team.

source code example;

0000.10 PROCESS APOST GRAPHIC.
0000.20 ***************************************************************
0000.30 IDENTIFICATION DIVISION.
0000.40 H/TITLE PRO Upd Period End Acct Print file
0000.50 Y* OVRDBF PROSD1J1 PROSD1Q1
0000.60 Z* CRTCBLPGM
0000.70 Z* CVTOPT(*DATETIME)
0000.80 *
0000.90 H* SYNOPSIS :
0001.00 H* - Print report of file contents

This is a 2E generated COBOL with an override database precompile directive for a QRY access path.

The problem only occurrs during the CM promotion process, so we suspect something going wrong in there.
We have been able to work around this issue by utilizing CM special commands for our OVRDBF but we need to find the cause of this issue.

To the best of our recollection, this was not a problem while running 2Ev8.5 with CM 8.5.

Cheers!
Gary Haut
StoneRiver

[Legacy User]

Rory & anyone else lurking,

The Y specs are before the Z specs. So here is the order of events for 2 execute external functions each with a series of Y specs before the Z specs. Each compiles correctly on their own.

1. ACMS (Aldon/Rocket Software CM product) submits a promotion job.
2. Job begins compiling PF, LF, DSPF/PRTF, Programs.
3. First program is compiled (it adds a library to the library list precompile). No errors.
4. Second program compiles (it adds a library into the library list. This time it happens after the compile but the Y specs are before the Z specs. Compile fails.

I have a global pre/post compiler option defined via data area YBRTPXA.

Eamonn

[Legacy User]

Ok, guess noone has any ideas, I'll open a ticket with the issue then.

Eamonn

[Yorkshireman]

FoleyE wrote:

Ok, guess noone has any ideas, I'll open a ticket with the issue then.

Eamonn

Is there an explanation / result on this?

Coincidentally, I'm here for something else, but earlier this week I was taking a look at using P* X* Y* Z* records to see if we could contrive some sort of 'make' type scripts that could run across several objects (we don't have a promotion tool - don't ask)

So I'm interested in the answer for this.



Richard Wilson

[Anon Anon]

Richard,

As far as 'make' scripts go, we use them extensively here, for all our hand-coded development (RPG, CL, PL/I, etc.)...

As an example, we have a file called QCMPSRC that contains one member per compile command. So for instance, there is an RPGLE member in there called CRTBNDRPG which has the following in it:

[font=Courier New]H*
H* This is an external source member which is referenced with an X*
H* compile preprocessor flag in each RPGLE source member which should
H* compiled as a *PGM using the CRTBNDRPG command. Any defaults     
H* specified here will be overridden using Z* compile preprocessor
H* lines appearing after the X* line which references this member.
H*
Z* CRTBNDRPG
Z* DBGVIEW(*SOURCE)
Z* CVTOPT(*DATETIME)
Z* OPTION(*NODEBUGIO)
Z* DFTACTGRP(*NO)
Z* ACTGRP(*CALLER)
Z* BNDDIR(QC2LE Y1BNDDIR)
[font]
Then, every RPGLE source member that should be compiled as a bound program simply contains the following compile preprocessor (CP) directive:

[font=Courier New]X* QCMPSRC,CRTBNDRPG[font]

and it will be compiled using the defaults in the CRTBNDRPG member. Of course, a specific member which wants to use slightly different defaults might contain the following

[font=Courier New]X* QCMPSRC,CRTBNDRPG
Z* ACTGRP(TESTACTGRP)
[font]
Additionally, we have a file called QSRVSRC which contains one member per service program. So for instance, there is a member called YGNRPRCS1R which has the following:

[font=Courier New]/*X: QCMPSRC,CRTSRVPGM */
/*Y: SRVPGM(&L/&E) + */
/*Y: MODULE(YGNRPRC + */
/*Y: YCHKOBJC + */
/*Y: YSYSVALR + */
/*Y: YSPCCHRR + */
/*Y: YSPDLUMX + */
/*Y: YSPDLUMR) + */
/*Y: BNDDIR(QC2LE Y1BNDDIR) + */
/*Y: TEXT('Generic procedures (I)') */

STRPGMEXP LVLCHK(*NO)

EXPORT SYMBOL(@generic) /* Proc */
EXPORT SYMBOL(@unspec) /* Proc */
EXPORT SYMBOL(@binary) /* Proc */
EXPORT SYMBOL(@max) /* Proc */
...
[font]
In each of the constituent modules, there are the following lines:

[font=Courier New]X* QCMPSRC,CRTRPGMOD
X* QSRVSRC,YGNRPRCS1R
[font]
In this case, whenever any one of the modules that are bound into the YGNRPRCS1R service program is recompiled, it uses the defaults from the CRTRPGMOD member in QCMPSRC to compile the module and then a copy of the YGNRPRCS1R service program is created (in the same library as the module) using the defaults from the CRTSRVPGM member in QCMPSRC plus the specific information in the Y* CP directives in the YGNRPRCS1R member in QSRVSRC...

Easy, eh?

You can get pretty fancy, with nested CP directives and stuff like that.

As far as including all this stuff with 2E, there is a document which describes how to create EXCUSRSRC which includes multiple CP directives. You should be able to get it from Support, or it is (I believe) included in the r8.5 User Guide.

Rory

[Yorkshireman]

Thanks for this Rory,

It's where I'm headed with attempting to rationalise our RPG coders as they slowly become RPGLE coders (another 'please don't ask')

To add some spice, we're also beginning to look into 'standardising' on TFS or Rational as an underlying tool for source code. Its all just text files, right?

There are some interesting questions and possibilities relating to 2e generated code and change controls amongst all of that.


I may be back with more questions!




Thanks

Richard Wilson

[Yorkshireman]

Replying to my reply...


At what point do we require licensed materials to make the pre processor work ?

Understandably, there is no documentation about exaclty 'which' implementation objects do the magic, or how to embed the functinoality into the wider IBM i environment.

At present, all our compiles go through ... ahem SHOULD.. go through the pre-precessor via the use of a standard job description.

With the advent of Rational into the RPGLE developers desktops, I'd like to be able to ensure that everything they need is 'Always' going to be somewhere they can't avoid, using their own job descriptions and library lists.


Given that embedding this functionality into RPG development extends the 2e reach, would it be possible to release a tad more information about what makees the black magic work?


for starters - maybe something on the lines of

'The following imp objects are used to make preprocessor commands work

aaaa - licence required
bbbb
cccc
dddd


(even better if some were open sourced, and 2e components crept into more sites. )



Richard Wilson
Yorkshireman

[Anon Anon]

Yorkshireman wrote:

Replying to my reply...


At what point do we require licensed materials to make the pre processor work ?

Understandably, there is no documentation about exaclty 'which' implementation objects do the magic, or how to embed the functinoality into the wider IBM i environment.

At present, all our compiles go through ... ahem SHOULD.. go through the pre-precessor via the use of a standard job description.

With the advent of Rational into the RPGLE developers desktops, I'd like to be able to ensure that everything they need is 'Always' going to be somewhere they can't avoid, using their own job descriptions and library lists.


Given that embedding this functionality into RPG development extends the 2e reach, would it be possible to release a tad more information about what makees the black magic work?


for starters - maybe something on the lines of

'The following imp objects are used to make preprocessor commands work

aaaa - licence required
bbbb
cccc
dddd


(even better if some were open sourced, and 2e components crept into more sites. )



Richard Wilson
Yorkshireman

Richard,

Actually, there is no license checking in the compile preprocessor at all - it was deliberately designed to not rely on any objects other than the base program (YBRTPRC). Of course, there is the whole issue of setting it up (creating routine entries etc.), but no license checking involved.

As far as the black magic, it should be pretty well documented in the 2E manuals. Also, if you do a YGO *Y1, you will see a step-by-step guide to setting it up. If you want to know more, let me know, and I will dig out some better docs.

Rory

[Yorkshireman]

roryhewitt wrote:

[
As far as the black magic, it should be pretty well documented in the 2E manuals. Also, if you do a YGO *Y1, you will see a step-by-step guide to setting it up. If you want to know more, let me know, and I will dig out some better docs.

Rory

Thanks for the offer, though I'm happy with the set up, and I've added some functionality via the 'exit program' facility.

We're a bit of a mongrel installation, when viewed as a whole. As explained whern I first arrived ' We've tried most things, and we keep a bit of each running in production'

The TMKMAKE command issued in QUSRTOOL was a start point for setting out to do more along these lines, with its notions of a meta language and possibility of macro definition. Most opf the RPG based tools require some syntax sensitive information embedding into individual components, and maybe a daisy chain of compiles reliant on detailed set up. - even more source members to keep track of.


my 'Challenge' is make it truly universal.



- and maybe publish the results?


Thanks for your help

[Legacy User]

Just an update,

CA issued a PTF for our issue and that resolved the problems we were having.

Sorry we took so long in testing that, paperwork and process are not always compatible with productivity.

Eamonn

[Anon Anon]

Eamonn,

Has this been resolved yet? I know that one of our engineers was working towards getting a fix to you, and I wanted to know if this fix had resolved the problem. If so, perhaps you could let us know here, so that Richard (Yorkshireman) Wilson can know whether to request a copy.

Cheers,

Rory