It's all about the answers!

Ask a question

Link Edit processing in z/OS Dependency Builds


Alex Akilov (1211023) | asked Mar 12 '15, 2:03 p.m.
edited Mar 12 '15, 2:05 p.m.
We're trying to convert our current Cobol compilation and Link edit processing from Rexx+JCL to use RTC Language definitions/translators.  We have several thousand CICS online programs that need to be linked (currently done via INCLUDE statements in the JCL steps) with several of the CICS routines to enable them to leverage CICS services.  Do we have to create a link edit control deck (i.e. <program>.lnk) for each such CICS program or is there a way to generically specify this in the CICS link edit translator?

Accepted answer


permanent link
Liam Doherty (2312) | answered Apr 07 '15, 3:36 a.m.
JAZZ DEVELOPER
I have also been looking a similar scenario for another customer. Their scenario was they wanted to have extra things concatenated with the object deck. So:
  1. CICSTS.V5R2M0.CICS.SDFHCOB(DFHEILIC)  - Contains   INCLUDE SYSLIB(DFHECI)
  2. The generated object
  3. CICSTS.V5R2M0.CICS.SDFHLOAD(DSNCLI)
  4. DB2.V11R1M0.SDSNLOAD(DSNTIAR)

This is achievable in v5.0.2 by sending the generated object deck to a physical sequential data in the compile and then referencing that in the link-edit step. Then instead of allocating SYSLIN in the DD Allocations, create a SYSLIN concatenation.


Alex Akilov selected this answer as the correct answer

Comments
Alex Akilov commented Apr 16 '15, 9:17 a.m.

  Thanks Liam, that worked and much better than using an external sequential file.

2 other answers



permanent link
Liam Doherty (2312) | answered Mar 24 '15, 5:06 a.m.
JAZZ DEVELOPER
Hi Alex,

Can you send me a couple of examples of your current Link-edit JCL. Can you remind me what version of RTC are you on? There is probably a couple of ways to handle this depending on your version. In more recent versions we added the ability to add in-stream information, as well as extending how DD concatenations are handled. I currently have a separate <program>.lnk member for each load module, but we have been link-editing these since before v3, so that was, at the time the only option we had. I should look at updating and getting rid of the .lnk members.

Comments
Alex Akilov commented Mar 24 '15, 6:05 p.m.

 Liam,

We're on 5.0.2.  Adding a .lnk file for every single program is what we're trying to avoid having to do since in our case, the link directives are usually unique per language definition (rather than program).  I asked my colleagues to produce a copy of a build JCL and we'll send it to you via email tomorrow morning as they're gone for the day.  Thanks.


permanent link
Alex Akilov (1211023) | answered Apr 02 '15, 9:43 a.m.
 We ended up pointing SYSLIN to a sequential file (link control deck) that contained:

INCLUDE DD1, DD2

where DD1 is defined in the translator to point to the Object Decks data set definition with the current member name appended (i.e. Member=Yes) and DD2 was defined to point to the additional object that we wanted to link.  We initially tried to use the new Instream DD feature for SYSLIN with the above but ran into an apparent bug where RTC tries to allocate a data set for the contents of the instream DD using some default (hardcoded) allocation parameters which are not valid in our shop i.e. unit(vio).

Your answer


Register or to post your answer.