|
View previous topic :: View next topic
|
| Author |
Message |
parsesource
New User
Joined: 06 Feb 2006
Posts: 97
|
|
|
|
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 |
|
 |
mtaylor
Active User
Joined: 20 Feb 2009
Posts: 108
Location: Kansas City
|
|
|
|
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 |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| 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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
How did the "requirement" to use different LE Options originate 
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 |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
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 |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| 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 |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
| 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 |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Yeh,
the TS is talking about CEEOPTS and CEEROPTS. That makes it a bit
difficult to know what the TS wants. |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
| 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 |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| 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 |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
| 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 |
|
|
parsesource
New User
Joined: 06 Feb 2006
Posts: 97
|
|
|
|
| dick scherrer wrote: |
Hello,
How did the "requirement" to use different LE Options originate
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 |
|
|
parsesource
New User
Joined: 06 Feb 2006
Posts: 97
|
|
|
|
| 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 |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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 |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
| I agree, I am out as well. |
|
| Back to top |
|
|
parsesource
New User
Joined: 06 Feb 2006
Posts: 97
|
|
|
|
| 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 |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| 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 |
|
|
mtaylor
Active User
Joined: 20 Feb 2009
Posts: 108
Location: Kansas City
|
|
|
|
| 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 |
|
|
parsesource
New User
Joined: 06 Feb 2006
Posts: 97
|
|
|
|
| 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 |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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 |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
The TS question is not very clear, to say the least.
Here are 3 things that can be done with procedures, maybe it will help:
1. Nested procedures
You can create a new procedure that calls the original one, with new defaults:
| Code: |
//BATXYZT PROC X1=OVER1,X2=OVER2
//RUNABCD EXEC PROC=BATABCD,X1=&X1,X2=&X2
// PEND |
2. Change DD statement
If the original statement has 2 DD cards, you can add a 3rd one by using blank operands:
| Code: |
//step.CEEOPTS DD
// DD
// DD DISP=SHR,DSN=xyz(OVER3) |
3. You can combine the 2 possibilities together
Create a new procedure with modified DD statement:
| Code: |
//BATXYZT PROC X1=OVER1,X2=OVER2,X3=OVER3
//RUNABCD EXEC PROC=BATABCD,X1=&X1,X2=&X2
//step.CEEOPTS DD
// DD
// DD DISP=SHR,DSN=xyz(&X3)
// PEND |
Note: I am at home, I am not able to verify this JCL. You'll have to try yourself. And read the manual... |
|
| Back to top |
|
|
|
|
