Rexx to Compile a Cobol DB2 Program?

Deepak GN · New User Joined: 25 Apr 2009 Posts: 3 Location: Chennai

Hi all,

I am trying to get a Rexx code which can be used for the compilation of a cobol db2 program. Although there are queries raised before on similar subjects, i think there were no references provided for the query that i have raised. I require this code for the development of a tool for tracking the compilation errors.

Currently forum has posts on rexx code for compilation of cobol programs , but not a cobol/db2 program.

Thanks to all who post a reply for this query.

Cheers
Deepak

superk · Posted: Sun May 10, 2009 7:09 pm

Can't you just convert the steps of your current compile process into the same steps using REXX? I can't imagine that it would take much more than a few minutes to get it done.

Deepak GN · New User Joined: 25 Apr 2009 Posts: 3 Location: Chennai

Thanks Superk. I thought there were some complexities invloved in this process and the so the query. Anyway, I would try to see if I can code this. Not in few minutes because I am not an expert in Rexx.

Marso · Posted: Sun May 10, 2009 7:49 pm

You have to run 2 programs from your REXX:
1. The DB2 pre-compiler,
2. The COBOL compiler.

You will have to check (in a batch compile for example) which inputs and outputs there are in the pre-compiler, and add corresponding ALLOC in your REXX program.

The output of of the DB2 pre-compiler will be used as input by the COBOL compiler.

MBabu · Posted: Sun May 10, 2009 11:24 pm

Never done cobol/db2 but generally to convert from JCL to Rexx:

Run a working JCL that does what you want and make sure your MSGCLASS and MSGLEVEL will hold put the substituted JCL in your spool (SDSF, SYSVIEW, IOF, TSO OUTPUT command, etc).
Look at the original and substituted JCL, specifically for:
1. EXEC statements to see what programs to call
2. PARM= on the exec statements. Be sure you understand JCL continuation rules if parms span lines!!
3. DD and data set names.
4. Inline data
Change the DD statements to ALLOC commands. If the DD references a temp data set, it is best to create a real data set in the Rexx and delete it at the end of the rexx because referbacks are easier that way. If it references TAPE you are probably out of luck. GDGs need special handling because ALLOC doesn't handle them directly. SYSOUT=x are best to go to data sets and inline data should come from temp data sets you create in the Rexx.
Change the EXEC and PARM statements to TSO CALL *(pgm) 'parm statements, or to ISPEXEC SELECT PGM(pgm) PARM(parm) statements or to ISPEXEC SELECT CMD(pgm parm) statements. The choice of which one depends on the availablility of all the load modules you need. The ISPF calls let you change the search order by using ISPEXEC LIBDEF. If you use TSO CALL statements you can set up your search order using TSOLIB before you enter ISPF... easier to code, harder to use. There are less common ways to invoke the program(s) too: as rexx commands, TSOEXEC, and others, but each introduces its own problems.

The basic idea of conversion is very simple. In practice it can get very complicated. I've probably heard of dozens of attempts by highly skilled people to fully automate conversion and tried a few myself and never heard of anyone who didn't give up because of all of the idiosyncrasies of JCL, TSO commands, and load module search orders. Too bad IBM never made Rexx output a part of the JCL interpreter where they know things like search orders, data set sizes etc.

I assume you are writing an edit macro to put the error lines in the code within an edit session. It is the most common reason to ask this question. You can scan the listing(s) or look at some compiler generated files to get the messages and info you need for the editor. Listings are easiest to code from but it is hard to do this very well using compiler listings because the line numbers are often hard to find, especially if errors occur in copybooks, But start with the listings to see if they are good enough for your needs because using the compiler data files is much more involved. Again, ease of writing vs ease of use.

dbzTHEdinosauer · Posted: Mon May 11, 2009 4:54 am

everybody wants to re-invent the wheel!

INLINE COBOL ERROR DISPLAY Tool in REXX

provided free of charge, by the way, by IBM.

MBabu · Posted: Mon May 11, 2009 7:04 am

I've seen others say the same thing as what I'm about to say but I can't think of a good reason that someone should not reinvent a tool like this, especially if they are learning. Telling someone not to reinvent something while they are learning is like telling a budding electrician not to wire light bulbs because someone has already invented the lamp or telling a doctor not to learn make a basic dressing because you can buy a Band Aid.

Also, from the looks of it, the tool doesn't format the messages too well, requires a batch job and knowledge of job numbers (yuck), won't work with errors in copybooks, can't take you to errors in copybooks, requires that you maintain JCL with specific compiler parameters that may be specific to the tool, requires multiple steps and screens for each invocation, won't work directly with a source control system and probably has other limitations that may not be acceptable to Deepak (and are easy to code around but are often site specific).

I'd say that as long as the boss thinks it is a good use of your time and any other costs, reinvent anything you want.

(Sorry Dick - not meant to attack your generous contribution in any way!!!! Just offering another point of view)

Deepak GN · New User Joined: 25 Apr 2009 Posts: 3 Location: Chennai

Hi all, Thank you for your replies.

Hello Dick, I just tried the tool that is provided there and it doesnt seem to work fine. The reason being, the inline tool mentioned in IBM donot take care of expansion of copybooks and Includes and results in the incorrect display of messages. Also, compilation is done as a seperate process. My aim here is to include all in one step.

A complete package and not a half build one as mentioned in the link.
Thanks Babu, Marso and Dick.

dbzTHEdinosauer · Posted: Mon May 11, 2009 4:49 pm

everything supplied by IBM it is 'bare bones' (e.g. DEBUG TOOL, CEDF).

since the TS/OP seems to be a rookie, I suggested the tool as a starting place.

My own prejudices were at work in my answer.
Not knowing, but assuming, the motive for this tool was responsible for my attitude.

tracking compilation errors may seem a worthwhile endevor,
but checking for coding standards, IMUO, would be time better spent.

getting a zero free compile is like getting into a car.
how one drives is much more important.

Actually, if you are going to generate tools, create one that will help in testing.
Inadequate testing is the biggest problem in any shop.