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
 

 

Extend PROC
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
parsesource

New User


Joined: 06 Feb 2006
Posts: 97

PostPosted: Mon Jul 25, 2011 2:31 am    Post subject: Extend PROC
Reply with quote

hello

various jobs use a batch proc (let´s all it batabcd)

i want to extend it in a compatible manner adding dd:ceeopts and a few parms


Code:

//BATABCD PROC X1=NULL,X2=NULL
//...
//CEEOPTS DD DISP=SHR,DSN=xyz(&X1.)
      DD DISP=SHR,DSN=xyz(&X2.)
//....



Member NULL is empty. so the default behaviour is unchanged.

When calling the proc, i can add X1=membname,X2=membname to activate different LE-Options. That´s fine. But i have no solution to override LE-Options on a Job-Level using a single statement

JOB SET-Statements cannot override values in Procs, when a default-value is set within the proc.

A solution using different CEEROPT Modules in a dataset has the same problem. I have to set a default value for a dataset within the proc that cannot be overridden with a JOB SET Statement.


Is there a solution (different idea)?
Back to top
View user's profile Send private message

mtaylor

Active User


Joined: 20 Feb 2009
Posts: 108
Location: Kansas City

PostPosted: Mon Jul 25, 2011 4:42 am    Post subject:
Reply with quote

Basically you can't do that for the reasons you indicated, your only option is to add the dd to the step from the surrounding jcl by coding an override. I believe you can add a ddname to a step that's not coded in proc from the surrounding jcl, I may be wrong though.

Note NULL has no meaning in JCL and will either error or replace the parameter with 'NULL'. I don't recall which.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Mon Jul 25, 2011 4:52 am    Post subject:
Reply with quote

mtaylor wrote:
[...]

Note NULL has no meaning in JCL and will either error or replace the parameter with 'NULL'. I don't recall which.


parsesource wrote:
Member NULL is empty. so the default behaviour is unchanged.


The way I read it, NULL is an "empty" member on a PDS. So if X1 or X2 not specified, will take the default value NULL and look at the member NULL, which is "empty". I think this is how parsesource wants it.
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: Mon Jul 25, 2011 4:54 am    Post subject:
Reply with quote

Hello,

How did the "requirement" to use different LE Options originate icon_confused.gif

Some of the systems i support / have supported are made up of 10s of thousands of modules and all use the same (whatever they are) options throughout all of the batch jobs.

If you explain why this is being considered, someone may have an alternate suggestion.
Back to top
View user's profile Send private message
nevilh

Active User


Joined: 01 Sep 2006
Posts: 258

PostPosted: Mon Jul 25, 2011 12:04 pm    Post subject:
Reply with quote

Not a very elegant solution but could you not put the CEEROPTS member in a JOBLIB DD statement . Just a word of warning if your sysprogs have specified the NONOVR parm when they created the default options you cannot overwrite them.
Quote:
How did the "requirement" to use different LE Options originate
This is a common requirement at sites where multiple computer centres have been merged
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Mon Jul 25, 2011 2:00 pm    Post subject:
Reply with quote

nevilh wrote:
Not a very elegant solution but could you not put the CEEROPTS member in a JOBLIB DD statement . Just a word of warning if your sysprogs have specified the NONOVR parm when they created the default options you cannot overwrite them.
Quote:
How did the "requirement" to use different LE Options originate
This is a common requirement at sites where multiple computer centres have been merged


Isnt a JOBLIB used for program libraries?
Back to top
View user's profile Send private message
nevilh

Active User


Joined: 01 Sep 2006
Posts: 258

PostPosted: Mon Jul 25, 2011 2:12 pm    Post subject:
Reply with quote

Quote:
Isnt a JOBLIB used for program libraries?
yes but OP was talking about CEEROPTS (load module) and I assumed possibly incorrectly that this might be acceptable
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Mon Jul 25, 2011 2:19 pm    Post subject:
Reply with quote

Yeh,

the TS is talking about CEEOPTS and CEEROPTS. That makes it a bit
difficult to know what the TS wants.
Back to top
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 645
Location: Pennsylvania

PostPosted: Mon Jul 25, 2011 5:44 pm    Post subject:
Reply with quote

Quote:
JOB SET-Statements cannot override values in Procs, when a default-value is set within the proc.


I beg to differ. It can not do it on its own, but it can in conjunction with the call to the proc. See here:
Code:
//JOB1     JOB
//*
//SYMBOLIC   SET X1='MEMBER1'
//SYMBOLIC   SET X2='MEMBER2'
//*
//TRKLOG1    EXEC BATABCD,
//           X1=&X1,
//           X2=&X2


I use this method all the time, and it works for me.

I hope this is what you were looking for since the OP was confusing, and no examples were given.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Mon Jul 25, 2011 5:53 pm    Post subject:
Reply with quote

daveporcelan wrote:
Quote:
JOB SET-Statements cannot override values in Procs, when a default-value is set within the proc.


I beg to differ. It can not do it on its own, but it can in conjunction with the call to the proc. See here:
Code:
//JOB1     JOB
//*
//SYMBOLIC   SET X1='MEMBER1'
//SYMBOLIC   SET X2='MEMBER2'
//*
//TRKLOG1    EXEC BATABCD,
//           X1=&X1,
//           X2=&X2


I use this method all the time, and it works for me.

I hope this is what you were looking for since the OP was confusing, and no examples were given.


I think he is looking for the neatest way to do it so that "most" of the time, it just runs with the dummy "null" without having to change anything, and then when it is needed the "override" works.

As far as I can see, this presents a problem. By specifying default on the PROC or the EXEC, this default will over-ride the value on any SET.

So, is there any way to have a default value that is "transparent" to most pieces of JCL and then have a method to set a specific value for some pieces of JCL which happen to need it.

I think, since TS/OP is unclear.
Back to top
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 645
Location: Pennsylvania

PostPosted: Mon Jul 25, 2011 6:01 pm    Post subject:
Reply with quote

Quote:
By specifying default on the PROC or the EXEC, this default will over-ride the value on any SET.



I disagree with this statement.

The way I have shown my code, the values in the SET statement, passed into the Proc on the EXEC statement will override the default set in the Proc. I have many Production Jobs/Procs working this way.

This is very clean in my Opinion. If you want use the 'default' values, call the Proc without any overrides passed in.

Use an override without or without a SET statement to override the default.
Back to top
View user's profile Send private message
parsesource

New User


Joined: 06 Feb 2006
Posts: 97

PostPosted: Mon Jul 25, 2011 6:07 pm    Post subject:
Reply with quote

dick scherrer wrote:
Hello,

How did the "requirement" to use different LE Options originate icon_confused.gif

Some of the systems i support / have supported are made up of 10s of thousands of modules and all use the same (whatever they are) options throughout all of the batch jobs.

If you explain why this is being considered, someone may have an alternate suggestion.


There are storage related problems using all31(off),stack(below) in some programs. These options are the set defaults in CEEPRMxx (NONCICS area).
I want to add add a simple parm to jobstep (or the whole job), to override the default.
Back to top
View user's profile Send private message
parsesource

New User


Joined: 06 Feb 2006
Posts: 97

PostPosted: Mon Jul 25, 2011 6:09 pm    Post subject:
Reply with quote

nevilh wrote:
Quote:
Isnt a JOBLIB used for program libraries?
yes but OP was talking about CEEROPTS (load module) and I assumed possibly incorrectly that this might be acceptable



A jobstep ignores JOBLIB, if a STEPLIB is specified. So using a JOBLIB for CEEROPT is not an option.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Mon Jul 25, 2011 6:11 pm    Post subject: Reply to: Extend PROC
Reply with quote

Sorry daveporcelan, I was not being clear.

I have no problem with your code.

What I think (and maybe best if I stop speculating) is that TS/OP wants something different.

I think (just pretend I prefix every paragraph with this) he wants a proc which can be used in 90% of JCL without having to think about it.

Then, in the other 10%, to be able to include the code necessary to do something different than the 90%.

He has come up with setting a default value in the proc, so that if nothing is provided for X1 or X2 it will pick up the value NULL from the proc. This is what it will do 90% of the time.

Then he is faced with the other 10%. But, the SET will not work because of using a default value in the PROC (same on the EXEC as well). Here, according to the JCL manual, the default from the PROC/EXEC will over-ride the SET value.

/I think off

Your example does not use a default value, so your example works.

However, to use your example every piece of JCL needs the SET in it.

/I think on

Until TS/OP tells us more, I think I'll stay out of this one, cos I've done enough speculating on it.
Back to top
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 645
Location: Pennsylvania

PostPosted: Mon Jul 25, 2011 6:19 pm    Post subject:
Reply with quote

I agree, I am out as well.
Back to top
View user's profile Send private message
parsesource

New User


Joined: 06 Feb 2006
Posts: 97

PostPosted: Mon Jul 25, 2011 7:25 pm    Post subject: Re: Reply to: Extend PROC
Reply with quote

Bill Woodger wrote:
Sorry daveporcelan, I was not being clear.

I have no problem with your code.

What I think (and maybe best if I stop speculating) is that TS/OP wants something different.

I think (just pretend I prefix every paragraph with this) he wants a proc which can be used in 90% of JCL without having to think about it.

Then, in the other 10%, to be able to include the code necessary to do something different than the 90%.

He has come up with setting a default value in the proc, so that if nothing is provided for X1 or X2 it will pick up the value NULL from the proc. This is what it will do 90% of the time.

Then he is faced with the other 10%. But, the SET will not work because of using a default value in the PROC (same on the EXEC as well). Here, according to the JCL manual, the default from the PROC/EXEC will over-ride the SET value.

/I think off

Your example does not use a default value, so your example works.

However, to use your example every piece of JCL needs the SET in it.

/I think on

Until TS/OP tells us more, I think I'll stay out of this one, cos I've done enough speculating on it.


You are correct. i wrote "compatible extension". Changes within PROC must be transparent for existing jobs.
Member NULL is simply an empty member. Sorry this was confusing.

Instead of using this new structure using symbols another option would be to simply add DD CEEOPTS containig all overriding le options in Jobstep, when neccessary. But this structure using symbols gives me more flexibility. And it hides complexity.

In CICS Environment there is better performance when using ALL31(ON), STACK(ANY). It seems that EXEC CICS LINK is performing better (at least measureable). I have no batch-data yet. Maybe it´s similiar that performance increases at least a little bit.


I have not tested this yet, but i think it´s even possible to add CEEOPTS DD * as an override combined with X1,X2 using the following construct

Code:

//BATABCD PROC X1=NULL,X2=NULL
//...
//CEEOPTS DD DISP=SHR,DSN=xyz(NULL)
      DD DISP=SHR,DSN=xyz(&X1.)
      DD DISP=SHR,DSN=xyz(&X2.)
//....


if I add a CEEOPTS DD * in jobstep it overrides the first DD in CEEOPTS Concatenation. So CEEOPTS DD *, X1,X2 are merged in CEEOPTS. Can be helpful, when a programmer is adding DD CEEOPTS with Option TEST(...)


An interesting question is, why a SET cannot override a PROC Default. JCL has many quirks and issues. The reason for this design decision is unclear for me.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Tue Jul 26, 2011 5:08 am    Post subject: Re: Reply to: Extend PROC
Reply with quote

parsesource wrote:
[...]

I have not tested this yet, but i think it´s even possible to add CEEOPTS DD * as an override combined with X1,X2 using the following construct

Code:

//BATABCD PROC X1=NULL,X2=NULL
//...
//CEEOPTS DD DISP=SHR,DSN=xyz(NULL)
      DD DISP=SHR,DSN=xyz(&X1.)
      DD DISP=SHR,DSN=xyz(&X2.)
//....


if I add a CEEOPTS DD * in jobstep it overrides the first DD in CEEOPTS Concatenation. So CEEOPTS DD *, X1,X2 are merged in CEEOPTS. Can be helpful, when a programmer is adding DD CEEOPTS with Option TEST(...)


An interesting question is, why a SET cannot override a PROC Default. JCL has many quirks and issues. The reason for this design decision is unclear for me.



Override DD in a PROC to DD *. Never tried that. Let us know.

Thinking about the SET question, and looking at an example (not exactly clear) of nested procs, it does seem that SET should only work within some specific scope. Otherwise you could well change something in a proc-within-a-proc that you didn't even know used the same symbolic you were using. I think we can get agreement that as a "language", JCL is not very advanced.

I think you should try out daveporcelan's code, see if it'll do what you want. The manual is pretty specific, but I may be misunderstanding the context. So I'd try it (except I can't, so I suggest you do as the next best thing).
Back to top
View user's profile Send private message
mtaylor

Active User


Joined: 20 Feb 2009
Posts: 108
Location: Kansas City

PostPosted: Tue Jul 26, 2011 5:52 pm    Post subject:
Reply with quote

Yes, SET works only within the current JCL/PROC. You could try NOT coding the parameters &X1 and &X2 in the PROC statement, see if they carry thru from the parent JCL.
Back to top
View user's profile Send private message
parsesource

New User


Joined: 06 Feb 2006
Posts: 97

PostPosted: Thu Jul 28, 2011 8:37 pm    Post subject: Re: Reply to: Extend PROC
Reply with quote

Bill Woodger wrote:


Override DD in a PROC to DD *. Never tried that. Let us know.

Thinking about the SET question, and looking at an example (not exactly clear) of nested procs, it does seem that SET should only work within some specific scope. Otherwise you could well change something in a proc-within-a-proc that you didn't even know used the same symbolic you were using. I think we can get agreement that as a "language", JCL is not very advanced.

I think you should try out daveporcelan's code, see if it'll do what you want. The manual is pretty specific, but I may be misunderstanding the context. So I'd try it (except I can't, so I suggest you do as the next best thing).


I´ve tested combining a DD * override + concatenation within proc. It works ok. DD * only overrides the first dataset. So all set options are merged together. Nice.

Another problem in this context is that a jcl-var which is not set defaults to itself including &. There may be good reasons for this.

If it would default to a null-string (which is not the case), setting global Options for the whole job with a SET Statement would be possible.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Fri Jul 29, 2011 12:03 am    Post subject: Reply to: Extend PROC
Reply with quote

I think DD DUMMY would give you the same effect for the override, perhaps a little more clear, as obviously you can't get any card data to follow the DD *.

Did you try daveporcelan's suggestion?
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
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts New PROC not reflecting in prod even ... Musab Ahmed CA Products 9 Tue Mar 15, 2016 12:45 pm
No new posts PROC to JCL mapping jena_samirkumar JCL & VSAM 13 Tue Dec 08, 2015 12:37 pm
No new posts JCL/job to PROC -- Symbolic to be use... Elixir JCL & VSAM 2 Thu Aug 20, 2015 2:56 am
No new posts Calling Stored Proc with out holding ... rexx77 DB2 6 Mon Nov 03, 2014 7:20 pm
No new posts Passing pack-data in CHAR format var ... DS COBOL Programming 6 Fri Aug 15, 2014 9:29 am


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