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
 

 

parms across different procs within a jcl

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
Nainesh A Jadwani

New User


Joined: 15 Jan 2013
Posts: 6
Location: India

PostPosted: Wed Feb 20, 2013 7:21 pm    Post subject: parms across different procs within a jcl
Reply with quote

Hi,

Is it possible to access parms across procs within the same jcl. Say JOB1 has the below calls:
Code:
//RSTART EXEC RSTART,JOBDET=123456
//STEP010 EXEC MAINPROC

I need to pass the value of JOBDET to a program within MAINPROC. To give some background. This is a job invoked from CICS and the JOBDET value is passed down by the CICS program. This is a key to a file containing user details which I need to access from within MAINPROC.

Please let me know if any additional information is needed. Thanks in advance.

Regards,
Nainesh A Jadwani
Back to top
View user's profile Send private message

prino

Active Member


Joined: 07 Feb 2009
Posts: 982
Location: Oostende, Belgium

PostPosted: Wed Feb 20, 2013 7:27 pm    Post subject:
Reply with quote

Of course it's possible, if you go through all the control blocks.

Why not pass the flucking parm also to "mainproc" and the required program in that proc?

Ever heard of KISS: "Keep It Simple, Stupid!"
Back to top
View user's profile Send private message
Nainesh A Jadwani

New User


Joined: 15 Jan 2013
Posts: 6
Location: India

PostPosted: Wed Feb 20, 2013 7:56 pm    Post subject:
Reply with quote

Hi Robert,

The thing is, CICS dynamically sends the key 123456 into JOBDET. In fact, the entire RSTART step is added by the CICS process (in the source of the proc, we can only see MAINPROC (this is the only step I can modify).

If I add something like...
Code:
//STEP010 EXEC MAINPROC,JOBDET=''
...and run the job, it still remains blank. I guess this is because the JOBDET in RSTART and the JOBDET in MAINPROC are treated as two separate entities.

What I want is to, somehow, be able to access the RSTART JOBDET and use it within MAINPROC.

Regards,
Nainesh A Jadwani
Back to top
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 645
Location: Pennsylvania

PostPosted: Wed Feb 20, 2013 8:27 pm    Post subject:
Reply with quote

Try this on for size:
Code:
//SYMBOLIC SET JOBDET=123456
//RSTART EXEC RSTART,JOBDET=&JOBDET
//STEP010 EXEC MAINPROC,JOBDET=&JOBDET


The question still remains, is JOBDET used within MAINPROC?

I assume it is YES. But we all know what happens when you assume.
Back to top
View user's profile Send private message
Nainesh A Jadwani

New User


Joined: 15 Jan 2013
Posts: 6
Location: India

PostPosted: Wed Feb 20, 2013 9:09 pm    Post subject:
Reply with quote

Hi Dave,

Actually, I meant to show 123456 as an arbitrary key. It has a different value each time the job runs (because CICS sends a different key value each time). Hence, I wouldn't be able to use...
Code:
//SYMBOLIC SET JOBDET=123456
Also, I can't make any changes to the RSTART step. This step is added by the CICS process.

Quote:
The question still remains, is JOBDET used within MAINPROC?

Yes. There is a program, say PROG1, which needs the value of JOBDET. This key is used to retrieve the correct record for obtaining the user details from a VSAM file. This is basically a report generation process in CICS that triggers a job in batch.

Regards,
Nainesh A Jadwani
Back to top
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 645
Location: Pennsylvania

PostPosted: Wed Feb 20, 2013 9:19 pm    Post subject:
Reply with quote

What can you change?

This is not going to happen just because you want it to.

This Job you speak of exists some where. You need to change that.

You also need to change the CICS process to populate the value of JOBDET into either the SYMBOLIC SET statement or directly into JOBDET= on the EXEC MAINPROC statement.

If you say 'I can not change....' then I am fresh out of ideas.

Maybe chase control blocks as prino stated above. Good luck with that.
Back to top
View user's profile Send private message
Nainesh A Jadwani

New User


Joined: 15 Jan 2013
Posts: 6
Location: India

PostPosted: Fri Feb 22, 2013 10:05 am    Post subject:
Reply with quote

Hi Dave/prino,

This is a generic CICS process (for users to submit reports from online) that dynamically creates a jcl and invokes different procs depending on the choice made by the user. It adds the RSTART to each proc and passes JOBDET as the key refering back to the details of the user and the request made by that user. I only want to refer to the key for the one new report that I have added to this process. Changing the CICS process and the RSTART step would impact the entire process and cause a lot of regression testing. Hence, I mentioned that I cannot change that.

What I basically wanted with the key was to obtain the email address of the submittor so that a mail could be sent back once the job completes. I guess a work around I might have to use is define a distribution list and hard code that into the job.

But just out of curiosity...would it have been possible to access the parms of an adjacent proc within a jcl using Control Blocks? How can this be done?

Regards,
Nainesh A Jadwani
Back to top
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 645
Location: Pennsylvania

PostPosted: Fri Feb 22, 2013 6:29 pm    Post subject:
Reply with quote

Quote:
would it have been possible to access the parms of an adjacent proc within a jcl using Control Blocks?


It may be possible.

Quote:
How can this be done?


I do not know. Working with control blocks is not an easy thing. Maybe you or Prino or someone else can spend the time to satisfy your curiosity.

I do think however it would be easier and a better idea to:
Quote:
Changing the CICS process and the RSTART step would impact the entire process and cause a lot of regression testing.


I have a hard time understanding not doing something like this because 'it is too much work'.
Back to top
View user's profile Send private message
prino

Active Member


Joined: 07 Feb 2009
Posts: 982
Location: Oostende, Belgium

PostPosted: Fri Feb 22, 2013 6:46 pm    Post subject:
Reply with quote

daveporcelan wrote:
I do think however it would be easier and a better idea to:
Quote:
Changing the CICS process and the RSTART step would impact the entire process and cause a lot of regression testing.

I have a hard time understanding not doing something like this because 'it is too much work'.

This is an Indian outsourcer, doing something like this would hurt their bottom line...
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 -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Passing parms when calling ISRSUPC(su... jasorn COBOL Programming 3 Mon Nov 16, 2015 12:06 pm
No new posts NDVRC1 Parms saikiran90 CA Products 0 Tue Mar 31, 2015 6:53 pm
No new posts Symbolic vaiable in procs instream data bhavya_sha JCL & VSAM 3 Fri Jan 16, 2015 4:45 pm
No new posts COND referback in nested PROCS? Claes Norreen JCL & VSAM 11 Thu May 15, 2014 6:34 pm
No new posts How to override a step in nested Procs ? Mohan D JCL & VSAM 2 Mon Apr 29, 2013 10:38 am


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