Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Calling a REXX exec from a COBOL program

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
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    Post subject: Calling a REXX exec from a COBOL program
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

Site Director


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

PostPosted: Fri Aug 12, 2011 1:27 pm    Post subject:
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

Moderator Team Head


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

PostPosted: Fri Aug 12, 2011 2:23 pm    Post subject: Reply to: Calling REXX exec from COBOL
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    Post subject:
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    Post subject:
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

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7224

PostPosted: Fri Aug 12, 2011 5:59 pm    Post subject: Reply to: Calling REXX exec from COBOL
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    Post subject:
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: 1738
Location: Bloomington, IL

PostPosted: Fri Aug 12, 2011 7:00 pm    Post subject:
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    Post subject:
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

Global Moderator


Joined: 14 Mar 2007
Posts: 10202
Location: italy

PostPosted: Fri Aug 12, 2011 7:08 pm    Post subject: Reply to: Calling REXX exec from COBOL
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: 1738
Location: Bloomington, IL

PostPosted: Fri Aug 12, 2011 7:23 pm    Post subject:
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

Global Moderator


Joined: 14 Mar 2007
Posts: 10202
Location: italy

PostPosted: Fri Aug 12, 2011 7:41 pm    Post subject: Reply to: Calling REXX exec from COBOL
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
http://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

http://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: 641
Location: Whitby, ON, Canada

PostPosted: Fri Aug 12, 2011 11:53 pm    Post subject:
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: 1738
Location: Bloomington, IL

PostPosted: Sat Aug 13, 2011 2:16 am    Post subject:
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

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7224

PostPosted: Sun Aug 14, 2011 12:41 am    Post subject:
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: 1712
Location: UK

PostPosted: Sun Aug 14, 2011 10:09 am    Post subject:
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: 1218
Location: Israel

PostPosted: Sun Aug 14, 2011 1:47 pm    Post subject: Re: Reply to: Calling REXX exec from COBOL
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

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7224

PostPosted: Sun Aug 14, 2011 2:46 pm    Post subject: Reply to: Calling REXX exec from COBOL
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    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts IMS BMP program causes 878 system abend Artemk IMS DB/DC 7 Tue Nov 22, 2016 8:26 pm
No new posts What is the command to check MODE of ... rohanthengal CLIST & REXX 6 Fri Nov 18, 2016 1:48 pm
This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm
No new posts Regarding COBOL Stored Procedure opti... selvamsrinivasan85 DB2 4 Fri Nov 04, 2016 8:57 pm
No new posts COBOL Version 6.1 Virendra Shambharkar COBOL Programming 5 Tue Nov 01, 2016 11:24 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us