Thanks to all that have contributed to this thread. To summarize what I have heard so far, there seems to be two basic ideas: (1) Post Process the JES Messages to extract the expanded JCL after a TYPRUN=SCAN or EXEC PGM=JCLTEST. (2) Use EXEC PGM=JSTTEST to generate special messages in the JES LOG that will show the connection between step names/DDNAME and dsnames.
The first idea is the most obvious and one I had already considered. Basically it becomes a problem of matching the IEFC653I SUBSTITUTION JCL messages against the XX and X/ lines in the listing. This would be a PITA to do in COBOL, a big job in ASM. Off platform I could do it easily in VB.Net or C#, but I would prefer to keep it all on the z/OS platform. Ed Jaffe's suggestion to employ the JES3 diagnostic of EXEC PGM=JSTTEST is something new for me. Basically if you toss in the EXEC PGM=JSTTEST anywhere in the JOB, it will cancel the job after the C/I phase and immediately produce the JES LOG. The log will contain a bunch of IAT4812 messages. The messages with the leading asterisk represent steps, and the others represent DDNAMES. But there are several problems with this approach: (1) The reported stepname is the procedure step. So if my original JCL statement is "//S001 EXEC PROC=ASMCL", I am going to see messages for steps ASM and LKED, and S001 will not be mentioned at all. (2) The message for the step has very little information. For example, the program name is omitted. (3) For DDNAMES, only the first 20 characters of the DSNAME are displayed. The bottom line is that neither approach is going to be a winner. Although a solution built around EXEC PGM=JSTTEST would be somewhat useful, its limitations would mean a step back from what the developers have become accustomed. Post processing the JES log is going to be too big a development task for the time I have available. So unless someone has already done it and is willing to share, this is a loser too. Fundamentally, the problem has its root in the design decisions made by the original developers of OS JCL. It would have made a lot more sense to treat PROC's as a special kind of MACRO call and then "PUNCH" out basic JCL statements. I am sure these early pioneers have moments in retirement when they think "if only I had ...". But of course, most of these guys probably never thought their creations would last the decade, let alone into the next century. And I have a lot of appreciation for what they achieved on machines with as little as 384K of core memory. John ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
