Link Edit processing in z/OS Dependency Builds
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
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:
- CICSTS.V5R2M0.CICS.SDFHCOB(DFHEILIC) - Contains INCLUDE SYSLIB(DFHECI)
- The generated object
- CICSTS.V5R2M0.CICS.SDFHLOAD(DSNCLI)
- 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.
2 other answers
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.
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
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.
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).