Calling a REXX exec from a COBOL program

satishboddu · New User Joined: 02 Aug 2011 Posts: 17 Location: India

Is there a possibility of calling a REXX exec from a COBOL program,if yes can we pass the copybook variables from the COBOL program to the REXX exec.

Thanks,
Satish Boddu.

dick scherrer · Posted: Fri Aug 12, 2011 1:27 pm

Hello,

REXX does not "know" cobol data definitions. . .

What is it your are actually trying to accomplish? Be specific rather than generic.

If we understand what you want to do, someone may have a suggestion.

superk · Posted: Fri Aug 12, 2011 2:23 pm

See this previous topic.

satishboddu · New User Joined: 02 Aug 2011 Posts: 17 Location: India

Hello Dick

here is my original problem statement,

I wanted to call a REXX routine from a cobol program, the REXX would contain call to DB2 tables which actually has REXX code saved in one of the columns. The REXX code present in the DB2 is likely to change frequently ,that is why i have embedded the REXX code in Db2. I would like to fetch the REXX code from DB2 and execute it . There are several data items present in the REXX code whose actual values should come from the COBOL program.I code present in DB2 will be meaningful only if the values from the COBOL program are populated into the REXX variables.

Thanks in Advance.
Satish Boddu.

dbzTHEdinosauer · Posted: Fri Aug 12, 2011 5:25 pm

reread the link provided by superk.

also, unless you are using compiled rexx, I don't think that you can do it.

Bill Woodger · Posted: Fri Aug 12, 2011 5:59 pm

What is all this with the desire to put "code" in a DB2 table. We had a request the other day to put Cobol code in a table as well.

If your rexx has to be compiled, that (almost) puts the cap on it, doesn't it?

How is this code that you'd like to sneak into your production system going to be tested? Or is it just some development "tool"?

If you really want to do this with the former, then your testing has to be as near exhaustive as you can make it. If someone is putting in code, how do you test it? How do you audit it? Is your Internal Audit department happy with this? If some sort of regulated banking, is your Compliance Derpartment OK with this? Is the Accounting Department OK with this? If it is for an external client, are they OK with this (remember, you have to explain to them the potential consequences)?

My opinion, go back and think about it all again and find a reasonable way to satisfy your business requirement.

If it is "A Tool", just change the damn rexx when needed.

satishboddu · New User Joined: 02 Aug 2011 Posts: 17 Location: India

Hi Bill,

I am the same person who the other day put the request to put COBOL code in to DB2, after much thought i felt it would not be feasible since we can not compile the COBOL code at run time. So finally thought of putting REXX code into DB2.

We don't use compiled REXX we use interpreted REXX. so i thought this is possible .

Answering your second part of your question , only few knowledgeable developers would use the facility of changing the REXX code in the DB2 , so the issue of compliance doesn't arise.

Akatsukami · Posted: Fri Aug 12, 2011 7:00 pm

satishboddu · New User Joined: 02 Aug 2011 Posts: 17 Location: India

But i have a long list of COBOL variables which should go in as input to the REXX exec and gets updates based on the REXX logic fetched from DB2 . Passing data between COBOL and REXX is the prime concern for me..

Thanks
Satish Boddu.

enrico-sorichetti · Posted: Fri Aug 12, 2011 7:08 pm

You should realize that the <quality> of answer is very much related to the <quality> of the question

if the more experienced people feel that the issue is not worth perusing
sadly the chances of getting good answers are pretty slim

moreover the general consensus is that when dealing with advanced implementation topics asking on a forum just shows that when defining the requirements the skills issue has been completely disregarded
and the same chances of getting good answers

anyway how to call rexx from cobol and cobol from rexx has been debated to death in the ibm literature

and if Your organization has the REXX compiler ( FAN... libraries ) the FAN140.SEAGSAM

contains all the samples for REXX interlanguage communication
( assembler,c,pl/i,cobol)

Akatsukami · Posted: Fri Aug 12, 2011 7:23 pm

enrico-sorichetti · Posted: Fri Aug 12, 2011 7:41 pm

follow on about the lack of skills for advanced application design and implementation ...

apart storing the <sources> in a db2 table
a simple google search with "rexx cobol interlanguage communication"
would have taken You here
publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=/com.ibm.zos.r12.rexa100/h1981605303.htm

which is the equivalent of You would have got here

publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/EAUGB10

the examples from the manuals work even if the rexx compiler is not installed
a visual inspection confirmed that the FAN stuff is not used
and I just tested it both the cobol samples

don.leahy · Posted: Fri Aug 12, 2011 11:53 pm

Akatsukami · Posted: Sat Aug 13, 2011 2:16 am

Bill Woodger · Posted: Sun Aug 14, 2011 12:41 am

Nic Clouston · Posted: Sun Aug 14, 2011 10:09 am

If using rexx code - or cobol for that matter - why put it in a db2 table? Why not simply pick it up from a PDS/seq file? Whichever, and whoever does it, it will still have to go through testing, chnge control, sign-off and promotion.

Marso · Posted: Sun Aug 14, 2011 1:47 pm

Bill Woodger · Posted: Sun Aug 14, 2011 2:46 pm

Yes, Marso, imagine trying a re-run? Does anyone remember what day we actually changed that code in DB2 last? Was it after the batch? Or just backing-out a messed-up implementation? Perhaps shoe-horn Endevor into DB2 as well, somehow?

What about the need of a "special run" that arises sometimes? One day you want to do the "special", the next and subsequent the normal code.

The list can go on.

People might suspect I don't like this idea. I don't, I think it is a non-starter.

It is bad enough as soon as you have about 5 on/off "flags" which are telling you stuff for any one piece of business processing. Code? Calculate how many things you have to cover in your testing, and be aware that all the testing has to be done each time the code changes, to even stand a chance. It is not really deliberate fraud that causes the problems (here, you increase the potential, but doesn't make it a certainty by any means) but mistakes. You get the code wrong. You have to catch it before the prod runs.

The way we normally do that is by planned releases of code. If you can't do that within you DB, so you'd have to build all that mechanism, then you are making a very small "window" to verify that any "code" change you make works.