Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Resolving/Expanding all COPY statements to make single COBOL unit on MVS 2

Status
Not open for further replies.

CraigJConrad

IS-IT--Management
May 21, 2000
66
0
0
US
Hi,
I have my COBOL code on MVS, broken down into many PDS members, using COPY statements to pull the pieces together in the compile step. I'd like a tool/utility that will resolve all of the COPY statements, replacing them with the COPY'd member, leaving me with a single file that is a complete COBOL program (compiler-ready).

If done the "obvious" way of iterating through the code, finding a COPY, fetching the identified member and writing it out, etc ... then nested COPY would work, but any COPY REPLACING would not be resolved without further coding. This could get complex (I have no real use of the REPLACING at this time, so it would be ok for now).

However, it seems that the compiler should be able to provide the intermediate COBOL code -- after it has handled all the COPY statements, just before it goes to the real compile step. Is there a way to get the mainframe compiler (e.g. a current IBM Cobol compiler) to give me this file?

A colleague has suggested getting the listing from the compiler and re-formatting (removing the page heading/trailers, cropping the non-code space on left/right of each line, etc), but I'd prefer a cleaner approach.

Ideas? Thanks in advance ... Craig
 
Do you know REXX (or maybe a co-worker)?

You could write a bit of code to read the original source member copying each line to a temporary output dataset. Each time " COPY " is found in the source, read that member and copy all lines to the output file.

When the input module is completely processed, copy the "expanded" source into a new member (until it is tested, suggest not destroying the original).

If you don't want to use a sequential file, use a member in a different pds.
 
Thanks, papadba, I'll keep that in mind. I used to know RexX very well, though on the VM/CMS environment (where it all started, I believe) -- about 27 years ago when I was a Systems Programmer (at IBM). Haven't tried it on MVS.
 
You're welcome. Yup, i remember rexx on vm long before the other manframe operating systems and xedit instead of ispf (maybe?).

Other than operating system dependent structures/commands the language was quite similar last time i saw a VM exec. . .
 
Webrabbit -- yeah, I think that's the way we're heading. If we can turn off the pagination totally (and then ignore the COPY statements themselves, which it seems to leave in the listing), it shouldn't be difficult. Thanks for affirming that ...
 
That's a fair question! We use a third-party package that is a "code generator". After some customization, it generates Cobol programs, but in literally hundreds of separate pieces (many tens of thousands lines of code), which is brought together in a single member containing all the appropriate COPY statements. Now we are near the end of the project and there is some pressure to move this into a code management system, which will handle the compilation in the target environments. If I don't do what I propose above, the maintenance of placing all of these pieces (and ongoing changes) into that management system will be very time consuming and risky (IMO). So, if I can "assemble" all of the pieces into a single (large) piece of Cobol code, then I can (if still required) place only that resulting piece into the system, let it compile/link there into the various environments. Much easier, in my view, and has side benefits as well (a single place to scan code for references, etc).
 
Any proper VCS (Version Control System) can do the management of sourcecode for you.
Have a look at SVN (subversion), Mercurial or Git (or CVS if that is all what's supported on your system).
Usually all have free clients for any kind of platform.
 
It's not that simple. The package we use is itself source code, and it generates more source code. We would have to identify the source code it generates at various steps and put those into the VCS (ChangeMan in this particular installation), and replace them when the package updates them in one of its many processes. If we weren't using a code generator, this wouldn't be as big a deal. All this for a one-time event of data migration -- not worth the extra effort.
 
Hi CrgJConrad,
You want to use the IBM supplied program called ISRLEMX. This does exactly what you require I think.I can let you have JCL for it if you wish.
Marc
 
In fact, here's some:
Code:
//EXPAND  EXEC PGM=ISRLEMX,
//          PARM='COB,PROGNAME,B,N,E,,,,ENG,,,,,,'
//ISRLCODE DD  DISP=SHR,DSN=USERID.A.COBOL
//         DD  DISP=SHR,DSN=USERID.A.COPYBOOK
//         DD  DISP=SHR,DSN=USERID.B.COPYLIB
//ISRLEXPD DD SYSOUT=*
//ISRLMSG  DD SYSOUT=*

Hope this helps.
Marc
 
Marc -- WOW! I tried this and it produced perfect results the very first time. I can't thank you enough for this!
 
Wow! I've been off of MVS for nearly 12 years, but I would have given my left arm for this utility back then. Nice bit of research. Have to file this one away in my "treasure" chest.

Catch a star from me!

Thanks Marc!



Code what you mean,
and mean what you code!
But by all means post your code!

Razalas
 
Thanks for the stars all, much appreciated. I believe this works with other languages as well as cobol although I've not tried it. If you change the first parameter in the parm string from COB, you can get the same effect on the following languages:
ASM - Assembler
COB - COBOL
FOR - FORTRAN
PAS - Pascal
PLI - PL/I
SCR - Script

I've only ever tried this on Cobol, but thought I'd mention the other languages just in case it would be of use to anybody else.

Marc
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top