IBM Mainframe Forum

Hi,

Greetings.

I want to set a return code to the MAXCC before my JCL ends. For example, My JCL is right when it return 16 as MAXCC (Under condition of Empty file).Unfortunately it is not a valid return code in common. Hence i would like to go with execute IDCAMS or other utility to set the MAXCC to 4 or less then 4 as return code. My JCL will be like below

1. STEP01 --> This step will return the code 16
2. STEP02 --> This should be IDCAMS or other utility to change the MAXCC to less then 4 from the previous MAXCC 16.

Problem :

1. I have done the changes but unfortunately my JCL still throw the maximum return code for the step executed in entire JCL.

Needs :
1. I want to change the entire MAXCC value, so that the jcl will through the value which i have set at last
2. I want to change the particular step MAXCC or returncode in a subsequent another step.

MAXXCC only belongs to IDCAMS. You can change it as much as you like.

What you cannot do is change the the maximum CC in a JOB or STEP. Once a step has completed, the CC for that step is fixed and cannot be changed.

Needs :
1. I want to change the entire MAXCC value, so that the jcl will through the value which i have set at last
2. I want to change the particular step MAXCC or returncode in a subsequent another step.

You will have to start looking for psychiatric help
Your needs cannot be satisfied amen

It seems as if you haven't kept up-to-date with the latest changes to JCL for z/OS v1R13:

Changes made in z/OS Version 1 Release 13
New information:
“JOBRC Parameter” on page 404 is a new parameter on the JOB statement to
control how the job return code (presented by JES2 or JES3) is determined.

JOBRC Parameter

Use the JOBRC parameter to control how the job completion code (presented by
JES2 or JES3) is set. By default (when JOBRC is not specified), the job completion
code is set to the highest return code of any step, or if the job's execution fails
because of an ABEND, the job completion code is set to the last ABEND code;
however, this parameter can be used to request that the job completion code be set
to the return code of the last exe.

JOBRC= {MAXRC|LASTRC|(STEP,stepname[.procstepname]}

MAXRC
The job completion code is set to the highest return code of any step in the job,
or if the completion of the job fails because of an ABEND, the job completion
code is set to the last ABEND code; This is the default parameter.
LASTRC
The job completion code is set to the return code or ABEND code of the last
step that is executed in the job.
(STEP,stepname[.procstepname])
The job completion code is set to the return code or ABEND code of the step
that is indicated by the stepname.[.procstepname] parameter. If this step does
not exist, a JCL error is generated. If this step does not execute, the processing
is the same as if MAXRC is specified.

Thanks. You are right Mr Spock. I didn't read the updates, now I should

So, we can go back through all those "you can't do that..." as well I seem to remember one in particular, where a Unix guy was very confused... oh dear, someone even implied that it would never, ever be possible

I'm up to date... i' m up to date ... since feb 16
http://ibmmainframes.com/about53439.html

You might be right from a theoretical point of view..
from a practical point of view see :

for the preview
http://www-01.ibm.com/common/ssi/cgi-bi ... NUS211-007
http://www-01.ibm.com/common/ssi/rep_ca ... 11-007.PDF

Planned availability date
Description
September 2011
Previews provide insight into IBM plans and direction. Availability, prices, ordering information, and terms and conditions will be provided when the product is announced.

confirmed by the announcement letter
http://public.dhe.ibm.com/common/ssi/ec ... 57USEN.PDF

Availability
September 2011

it is hard to believe that it will be installed soon!
so if the TS needs it now ... the doctor is in

Any chance we could storm some fortress somewhere and prevent IBM from implementing this??? This is a nightmare!

Please at least tell me that it's RACF/ACF protected, so they can prevent everyone from using it just to keep their bean counters happy.

After how many years of JCL staying mostly static, all of a sudden this comes out, along with allowing instream data in PROC's. I'd love to know the story behind the scenes - I agree it seems as if it could be a potential disaster for all of the production support and/or scheduling teams out there.

Having now looked at the updates, it seems JES3 will still not have DD * in Procs, at least.

With the JOBRC, I suppose we'll have a variety of IEFBR14s and suchlike, which are only there to get a zero code, so the job can have a zero code. Some of those will test other steps, some will be at the top of the jcl, some at the bottom, some at a random point somewhere in between. How does the re-run/restart jcl ensure that the step which sets the code that is wanted, is executed this time, at least potentially, and should it be, and... it used to be simple, didn't it?

Now all those 100-step jcl behemoths will be able to get a guaranteed zero, no matter what goes on inside (almost). Job gets zero, who looks at the rest?

I have not looked at the manuals
I hope that the SMF record will be changed in order to report the TRUE state of things !

and usual all the analysis is done processing SMF, so there is still hope