It's all about the answers!

Ask a question

Reusing DD names in sequenced translators


Alex Akilov (1211224) | asked Aug 11 '14, 6:13 p.m.
edited Aug 13 '14, 4:13 p.m. by Stephanie Taylor (24115)
We need to run a pre-process step prior to a compile.  The pre-process step uses similar DD cards to the compile step.  The output of the pre-process step (e.g. SYSUT2) should go into the SYSIN of the compile step (which happens to also need a DD Card named SYSUT2).  Therefore, I specified the SYSUT2 in the pre-process step as keep.
We found this in the documentation https://www-01.ibm.com/support/knowledgecenter/SSYMRC_4.0.6/com.ibm.team.concert.doc/topics/r_rtcz_same_name_for_temp_data_set_with_keep_in_translator.html?lang=en.  Does this mean that I have to specify a different name for SYSUT2 in the DD Names list?  Would this work in other cases where we use our own DD Card names (as opposed to one of the "IBM" supported DD names that can be used in the DD Names List)?
If I don't do something in the DD Names list, I get an error File in Use when the second SYSUT2 allocation is attempted during the compile step.  This could be a major problem for us if we have to be very explicit about how we specify and sequence these steps so that they can use the needed DD cards.
BTW, we also have a similar problem with SYSXMLSD, both steps should be able to write error feedback into that file. 

2 answers



permanent link
Liam Doherty (2312) | answered Aug 13 '14, 2:58 p.m.
JAZZ DEVELOPER
edited Aug 13 '14, 3:02 p.m.
Hi Alex,

the DD Names List utilizes the DD Name substitution facility that the IBM compilers, assembler and DFSMS utilities use. You can find information relating to this in all of the programming guides and utility reference. But for ease of reference I provided this in an SCLM redbook in Appendix E - DDname substitution lists. So to answer your 2nd question, "would this work in other cases where we use our own DD Card names" the answer would be no. However there is an option that may work for that, I will come to that in a moment. So to answer your first question, "Does this mean that I have to specify a different name for SYSUT2 in the DD Names list?" the answer is yes. A good example is IEBGENER. I uses SYSUT1 and SYSUT2 for input and output. If the output from SYSUT2 needs to go into the COBOL compiler then there will be an issue, as COBOL also uses SYSUT2, but for a work data set. So to get this to work the IEBGENER step needs to use the DDname list, and specify Keep on the temporary data set.

The data set definition for the temporary data set defines a data set name of &&TEMPSRC.
&&TEMPSRC

Then language definition in the example I will use has a 1st translator of IEBGENER that will copy the actual source into a temporary data set. The 2nd translator is the COBOL compile that will take the temporary data set as input.

For the IEBGENER translator the DDnames list has ,,,,SYSIN,SYSPRINT,,SYSUT1,SRCOUT so we are replacing SYSUT2 with SRCOUT. Note the 4 "," at the beginning as the ddname substitution is positional. Then in the DD allocations we allocate DD SRCOUT instead of SYSUT2, and use the data set definition that defines &&TEMPSRC using the KEEP option.
IEBGENER

Finally in the COBOL compile translator we use the definition that defines &&TEMPSRC and associate that with the SYSIN DD. This will allow the compile to work as SYSUT2 can be allocated normally by the COBOL compile step.
Cobol Compile

We can use IEBGENER steps in a number of translators including your own home written ones. If there is a conflict in DD names between 2 translators you can always put an IEBGENER in between them to rename the data set names as IEBGENER supports the DD names list.

 

Comments
Alex Akilov commented Aug 13 '14, 4:40 p.m.

Hey Liam, thanks for the response.

So we kinda figured that, but the issue is that our source expander isn't an IBM supplied utility but a home grown one so it doesn't support DD names list.  How would we need to configure our translators if our source expander assumes SYSUT2 as the output DD?  Can IEBGENER help us in our case?.
Note that this implies that the translators can't really exist on their own as reusable entities but have to be aware of the sequence that they're supposed to be used in (i.e. the compile translator assumes somebody pre-populated the Temporary source dataset since it uses that as SYSIN).
Also, this is but one example of some of the home grown utilities we currently have that probably don't support DD names list. This makes the sequence of processing somewhat difficult to predict and somewhat brittle.


Alex Akilov commented Aug 13 '14, 4:40 p.m. | edited Aug 13 '14, 4:52 p.m.

BTW, where do we stand on conditional translator support?  I saw that there was some support planned for 5.0.1 but it seemed that some of the work was decommitted from reviewing the work item but I'm not sure exactly what made it in and what didn't.  We'd like to use the source expansion step as a means of figuring out if we need to invoke the CICS or DB2 preprocessing steps prior to running the compile step (rather than using the co-processor feature) since we don't know if the code will remain consistent with the language definition we associated with it at zimport time (i.e. it could have had CICS/DB2 processing at import time but perhaps this was removed later on which could invalidate the associated language definition).  We'd rather compute what preprocessing needs to happen based on the analysis we do during our source expander at build time.

Update: just found https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.Attachment/209489


Alex Akilov commented Aug 13 '14, 5:04 p.m.

While I have your attention, we ran into a strange situation when we tried to fix our source expander to allow overriding what DD card to use (instead of SYSUT2).  We added a new (Dev) loadmod into the front of the TASKLIB to run a new version of the source expander that supported this new capability.  Unfortunately, the build stopped at the call to the source expander.  Our theory is that the Dev loadmod was in a PDSE whereas the rest of the entries in the TASKLIB were in PDSs.  Is mixing data set types a limitation?

We then went ahead and removed the PDSE from the TASKLIB and rebuilt the base loadmod and that got us passed that step.


permanent link
Liam Doherty (2312) | answered Aug 15 '14, 3:57 p.m.
JAZZ DEVELOPER
For the first, it should be able to. I would need to set it up to test, I will have to wait till I am back in Australia. But it looks like you are reworking your first step to not use SYSUT2.
For the 2nd, looks like you found what you needed.
For the 3rd, not a limitation that I am aware of. I just checked my COBOL/CICS/DB2 co-processor translator and I have a mixture:
TASKLIB allocation

Were all your blocksizes the same? Not sure that would make a difference. Did all the libraries in TASKLIB need to be APF authed, and the one you added was not? I would expect to see a S047 abend in the system log if that was the case.

Your answer


Register or to post your answer.