IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Calling a REXX exec from a COBOL program


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
satishboddu

New User


Joined: 02 Aug 2011
Posts: 17
Location: India

PostPosted: Fri Aug 12, 2011 1:20 pm
Reply with quote

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.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Fri Aug 12, 2011 1:27 pm
Reply with quote

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.
Back to top
View user's profile Send private message
superk

Global Moderator


Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA

PostPosted: Fri Aug 12, 2011 2:23 pm
Reply with quote

See this previous topic.
Back to top
View user's profile Send private message
satishboddu

New User


Joined: 02 Aug 2011
Posts: 17
Location: India

PostPosted: Fri Aug 12, 2011 5:21 pm
Reply with quote

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.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Fri Aug 12, 2011 5:25 pm
Reply with quote

reread the link provided by superk.

also, unless you are using compiled rexx, I don't think that you can do it.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Fri Aug 12, 2011 5:59 pm
Reply with quote

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.
Back to top
View user's profile Send private message
satishboddu

New User


Joined: 02 Aug 2011
Posts: 17
Location: India

PostPosted: Fri Aug 12, 2011 6:49 pm
Reply with quote

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.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Fri Aug 12, 2011 7:00 pm
Reply with quote

satishboddu wrote:
only few knowledgeable developers would use the facility of changing the REXX code in the DB2 , so the issue of compliance doesn't arise.

36_11_6.gif

But seriously (as I can take this obvious attempt at evading controls for your convenience), superk's link provides you with pretty much everything that you to know. Vaya con Dios.
Back to top
View user's profile Send private message
satishboddu

New User


Joined: 02 Aug 2011
Posts: 17
Location: India

PostPosted: Fri Aug 12, 2011 7:03 pm
Reply with quote

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.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Fri Aug 12, 2011 7:08 pm
Reply with quote

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)
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Fri Aug 12, 2011 7:23 pm
Reply with quote

satishboddu wrote:
Passing data between COBOL and REXX is the prime concern for me.

Research IKJCT441.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Fri Aug 12, 2011 7:41 pm
Reply with quote

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
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Fri Aug 12, 2011 11:53 pm
Reply with quote

Akatsukami wrote:
satishboddu wrote:
Passing data between COBOL and REXX is the prime concern for me.

Research IKJCT441.
Also see IRXEXCOM.

The easiest way might be to run the process under ISPF and use the variable pools to communicate between Cobol and Rexx.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Sat Aug 13, 2011 2:16 am
Reply with quote

don.leahy wrote:
Akatsukami wrote:
satishboddu wrote:
Passing data between COBOL and REXX is the prime concern for me.

Research IKJCT441.
Also see IRXEXCOM.

The easiest way might be to run the process under ISPF and use the variable pools to communicate between Cobol and Rexx.

With VGETs and VPUTs? If the process is being run in the ISPF environment, why not just use the VDEFINE service?
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sun Aug 14, 2011 12:41 am
Reply with quote

satishboddu wrote:
only few knowledgeable developers would use the facility of changing the REXX code in the DB2 , so the issue of compliance doesn't arise.


Don't get things confused.

It is not you who decides if Compliance is involved. If you have a Compliance department, they decide if you can do it or not. If your company/client is under external regulation, it is not your job to see that the rules are followed, it is their job. If you do something which threatens the regulatory status of your company/client without making it clear to Compliance, then expect to find youself wandering the street with a listing-box of your personal effects.

If you are thinking of "trusted experienced developers" not carrying out computer frauds, that is something for the Audit and Accounts departments. Who do you think does carry out computer fraud? People who don't know where a STOP RUN goes in a program? Could one of your non-Seniors put some rexx code in your DB which would do something "naughty" without people knowing? Could one of your Seniors? How do you lessen the chances of that, if you continue down this route.

Look back through all the responses to your Cobol question (sorry for not recognising it was you). This is "worse" because it looks like you can get code in there (without having to compile the rexx). Are you going to effectively test the interpreter, limit the instructions that can be used, limit data that can be used, or just let the whole lot rip (mmm.... load some code to allocate a file (say for money transfers), insert a new transfer, amend the totals, post the accounts, and then deletes itself from the DB)?
Back to top
View user's profile Send private message
Nic Clouston

Global Moderator


Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK

PostPosted: Sun Aug 14, 2011 10:09 am
Reply with quote

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.
Back to top
View user's profile Send private message
Marso

REXX Moderator


Joined: 13 Mar 2006
Posts: 1353
Location: Israel

PostPosted: Sun Aug 14, 2011 1:47 pm
Reply with quote

Bill Woodger wrote:
How is this code that you'd like to sneak into your production system going to be tested?
That's a key question.

Also:
1. How often the code will change? Daily, weekly?
2. Will the old versions still be used, or only the last one?
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sun Aug 14, 2011 2:46 pm
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Replace each space in cobol string wi... COBOL Programming 3
No new posts Using API Gateway from CICS program CICS 0
No new posts Running REXX through JOB CLIST & REXX 13
No new posts Error to read log with rexx CLIST & REXX 11
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
Search our Forums:

Back to Top