JCL Question about the RC system Variable
Denis
to post-it)
I have a JCL question: Is it possible to reset the RC system variable in a
JCL ? for example, with a statement like:
// SET RC=0
Obviously this statement does not work as RC it is not a normal "variable"
The goal is to have a JCL like the following:
//S1 EXEC PGM=P1
...
// IF (RC GE 8) THEN <--- start of the "does not work" construction
// SET RC=4 <--- does not work the idea is to "reset" the
RC variable to 4
// ENDIF <--- end of the "does not work"
construction
// IF (RC GE 4) THEN <--- want to test with RC = 4 even if S1 ended with
RC=8
//S2 EXEC PGM=P2
...
// ENDIF
This JCL is generated via FTINCL statements from a REXX/ISPF proc and has a
(quite large) variable number of steps after the step S2. The idea is to
avoid to have to generate very complex IF/THEN/ENDIF construction for the
steps that follow S2 (for example by qualifying each test of RC with the
step name...)
Any idea?
Many thanks in advance
Frank Allan Rasmussen
<gros...@antispam.skynet.be> wrote:
>(I know that this question is off-topic but I do not know in which newsgroup
>to post-it)
You can also try bit.listserv.ibm-main
>I have a JCL question: Is it possible to reset the RC system variable in a
>JCL ?
>Any idea?
I have used IDCAMS to do this:
//RESETCC EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
SET MAXCC = 0 (or is it SET MACRC = 0)
/*
Frank Allan Rasmussen
Systemsprogrammer
Fyns Amts EDB-central
F...@OES.FYNS-AMT.DK
Terry Heinze
You can't set the RC in JCL with a JCL statement, but you COULD exec a COBOL
pgm that set the value of RETURN-CODE for the step the pgm was executed in.
The value of the RC in your first step would remain that value for the
during of the job. In other words, replace // SET RC=4 by // EXEC
PGM=SETRC4 then test the result of the step executing SETRC4. Each step
returns it's own RC, so in ob containing 4 steps, there are 4 different RCs
you can test.
Denis <gros...@antispam.skynet.be> wrote in message
news:8c1rst$dnl$1...@hardcopy.ny.jpmorgan.com...
> (I know that this question is off-topic but I do not know in which
newsgroup
> to post-it)
> I have a JCL question: Is it possible to reset the RC system variable in a
> JCL ? for example, with a statement like:
> // SET RC=0
> Obviously this statement does not work as RC it is not a normal "variable"
>
> The goal is to have a JCL like the following:
>
> EXEC PGM=P1
> ...
> // IF (RC GE 8) THEN <--- start of the "does not work" construction
> // SET RC=4 <--- does not work the idea is to "reset"
the
> RC variable to 4
> // ENDIF <--- end of the "does not work"
> construction
>
> // IF (RC GE 4) THEN <--- want to test with RC = 4 even if S1 ended with
> RC=8
> file://S2 EXEC PGM=P2
> ...
> // ENDIF
>SNIP<
docd...@clark.net
Denis <gros...@antispam.skynet.be> wrote:
>(I know that this question is off-topic but I do not know in which newsgroup
>to post-it)
>I have a JCL question: Is it possible to reset the RC system variable in a
>JCL ? for example, with a statement like:
Check into IDCAMS... as I recall one is able to do similar things with
statements like IF LASTCC = (n) THEN SET MAXCC = (o)
DD
>// SET RC=0
>Obviously this statement does not work as RC it is not a normal "variable"
>
>The goal is to have a JCL like the following:
>
>//S1 EXEC PGM=P1
>...
>// IF (RC GE 8) THEN <--- start of the "does not work" construction
>// SET RC=4 <--- does not work the idea is to "reset" the
>RC variable to 4
>// ENDIF <--- end of the "does not work"
>construction
>
>// IF (RC GE 4) THEN <--- want to test with RC = 4 even if S1 ended with
>RC=8
>//S2 EXEC PGM=P2
>...
>// ENDIF
>
Denis
The IDCAMS/SET MAXCC instructions does not works because its sets the MAXCC
for the AMS instructions executed during the IDCAMS step (DELET, DEFINE
CLUSTER...), it does not reset the RC of the whole JCL. Only the RC of the
IDCAMS is affected
docd...@clark.net wrote in message ...
Denis
The IDCAMS/SET MAXCC instructions does not works because its sets the MAXCC
for the AMS instructions executed during the IDCAMS step (DELET, DEFINE
CLUSTER...), it does not reset the RC of the whole JCL. Only the RC of the
IDCAMS is affected
Frank Allan Rasmussen wrote in message
<38e4a156....@news.inet.tele.dk>...
>On Fri, 31 Mar 2000 11:41:18 +0200, "Denis"
><gros...@antispam.skynet.be> wrote:
>
>>(I know that this question is off-topic but I do not know in which
newsgroup
>>to post-it)
>
>You can also try bit.listserv.ibm-main
>
>>I have a JCL question: Is it possible to reset the RC system variable in a
>>JCL ?
Peter Flass
>
> (I know that this question is off-topic but I do not know in which newsgroup
> to post-it)
I use a dumb little assembler program that sets the return code to 0 or
4 based on a parm.
Thomas David Rivers
> You can't set the RC in JCL with a JCL statement, but you COULD exec a COBOL
> pgm that set the value of RETURN-CODE for the step the pgm was executed in.
> The value of the RC in your first step would remain that value for the
> during of the job. In other words, replace // SET RC=4 by // EXEC
> PGM=SETRC4 then test the result of the step executing SETRC4. Each step
> returns it's own RC, so in ob containing 4 steps, there are 4 different RCs
> you can test.
Well - a COBOL program may be a little overboard; just write a quick
ASM program that puts 4 in R15 and does a BALR 14,15. That will
set the 4 as the RC.
Something like:
SET4RC CSECT
L 15,=F'4'
BALR 14,15
LTORG
END SET4RC
Assemble this, link it and there you go.
A fancier version might, perhaps, look at the incoming PARMS
value (off of R1) and simply set the return code to whatever
that specified, etc...
- Dave Rivers -
--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe (370) `C' compiler at http://www.dignus.com
DennisHarley
1) You can set the initial RC to 0 by executing IEFBR14.
If you test RC before a program has been executed, it is null.
2) You can nest your conditional JCL. I think 15 levels is the max.
3) There is also an ELSE condition which you can Use
4) You can break your job stream up into several jobs, and use the
internal reader to start them.
5) I don't know of any way to reset the RC for a JOB.
Denis <gros...@antispam.skynet.be> wrote in message
news:8c1rst$dnl$1...@hardcopy.ny.jpmorgan.com...
> (I know that this question is off-topic but I do not know in which
newsgroup
> to post-it)
> I have a JCL question: Is it possible to reset the RC system
variable in a
> JCL ? for example, with a statement like:
> // SET RC=0
> Obviously this statement does not work as RC it is not a normal
"variable"
>
> The goal is to have a JCL like the following:
>
> file://S1 EXEC PGM=P1
> ...
> // IF (RC GE 8) THEN <--- start of the "does not work"
construction
> // SET RC=4 <--- does not work the idea is to
"reset" the
> RC variable to 4
> // ENDIF <--- end of the "does not work"
> construction
>
> // IF (RC GE 4) THEN <--- want to test with RC = 4 even if S1 ended
with
> RC=8
> file://S2 EXEC PGM=P2
Warren Porter
> Terry Heinze wrote:
>
> > You can't set the RC in JCL with a JCL statement, but you COULD exec a COBOL
> > pgm that set the value of RETURN-CODE for the step the pgm was executed in.
> > The value of the RC in your first step would remain that value for the
> > during of the job. In other words, replace // SET RC=4 by // EXEC
> > PGM=SETRC4 then test the result of the step executing SETRC4. Each step
> > returns it's own RC, so in ob containing 4 steps, there are 4 different RCs
> > you can test.
>
> Well - a COBOL program may be a little overboard; just write a quick
> ASM program that puts 4 in R15 and does a BALR 14,15. That will
> set the 4 as the RC.
>
> Something like:
>
> SET4RC CSECT
> L 15,=F'4'
> BALR 14,15 ???????????
> LTORG
> END SET4RC
I think you are at the wrong end of the program for that instruction. Try
LA 15,4
BR 14
after the registers have been restored. The BALR would load the address of the
next instruction in Reg 14 and branch to the address in Reg 15, but the system
wouldn't let you branch to low core.
--
Warren Porter - Remove digits
Denis
The solutions you propose (COBOL, asm or IDCAMS) allows me to write a
program for which the RC of the execution step will be 4.
This is not what I want to achieve: What I want to do is, in the middle of a
JCL, reset the internal value of RC stored somewhere by JES
I want to say to JES is: From that execution point in the JCL, forget the
maximum return code of all the previously executed steps (i.e. the global RC
variable) and reset it to 4 (or force the value of the global RC indicator
to 4)
By "global RC indicator", I mean the RC variable handled by JES not related
to any particular step, present in any JCL and that you can test in IF
statements without the step qualifier.The solution you give allows me to
force the value of the step.RC value for a particular step, not the "global"
one.
Thomas David Rivers wrote in message <38E4B15C...@dignus.com>...
>Terry Heinze wrote:
>
>> You can't set the RC in JCL with a JCL statement, but you COULD exec a
COBOL
>> pgm that set the value of RETURN-CODE for the step the pgm was executed
in.
>> The value of the RC in your first step would remain that value for the
>> during of the job. In other words, replace // SET RC=4 by // EXEC
>> PGM=SETRC4 then test the result of the step executing SETRC4. Each step
>> returns it's own RC, so in ob containing 4 steps, there are 4 different
RCs
>> you can test.
>
>Well - a COBOL program may be a little overboard; just write a quick
>ASM program that puts 4 in R15 and does a BALR 14,15. That will
>set the 4 as the RC.
>
>Something like:
>
> SET4RC CSECT
> L 15,=F'4'
> BALR 14,15
docd...@clark.net
Denis <gro...@antispam.skynet.be> wrote:
>Thanks for for your answer but...
>
>The IDCAMS/SET MAXCC instructions does not works because its sets the MAXCC
>for the AMS instructions executed during the IDCAMS step (DELET, DEFINE
>CLUSTER...), it does not reset the RC of the whole JCL. Only the RC of the
>IDCAMS is affected
Righto... well, so much for a quick answer, then!
DD
Alex Vrenios
Denis <gro...@antispam.skynet.be> wrote:
>Thanx for your answers, but this does not answer my question
>The solutions you propose (COBOL, asm or IDCAMS) allows me to write a
>program for which the RC of the execution step will be 4.
>
STM 14,12,12(13)
LR 12,15
USING IEFSETRC,12
SR 15,15 ASUME RC 0
L 1,0(,1)
LTR 1,1 ANY PARM?
BNZ DONE
*
IC 15,0(,1) YES: GET PARM BYTE
N 15,=F'15' AND SET RC FROM PARM
DONE L 14,12(,13)
LM 0,12,20(13)
BR 14
END IEFSETRC
Now you can use
// EXEC IEFSETRC,PARM='0'
or
// EXEC IEFSETRC,PARM='4'
or
// EXEC IEFSETRC,PARM='8'
But I'm a bit rusty at this. Maybe someone can get you 12 and 16 by
making some small change. Hope this helps.
--
Regards,
Alex V.
docd...@clark.net
[snippage]
>By "global RC indicator", I mean the RC variable handled by JES not related
>to any particular step, present in any JCL and that you can test in IF
>statements without the step qualifier.The solution you give allows me to
>force the value of the step.RC value for a particular step, not the "global"
>one.
Ummmm... I do not know if there is such a thing as a 'global RC
indicator'... return codes are created in steps and the return code at EOJ
is just the highest one of these, as far as my understanding goes.
DD
Kerry Ellis
#1. Write a program -- presumably authorized or sets itself
that way -- that does "nonstandard" stuff to update con-
trol blocks in SWA; this approach is highly problematic,
does not lend itself to maintenance, and might require
adjustments with various new releases of the operating
system.
#2. Front-end the program with a harness; i.e., a program
that CALLs, LINKs, or ATTACHes program P1 (al-
most any "main" program in OS/MVS can be used as
a "subroutine") and have the harness test the contents
of R15 (or RETURN-CODE in COBOL, etc.) and re-
set it accordingly, as per your requirements.
Kerry
[P.S. The stuff expressed herein does not necessarily reflect
the views of my employer or client.]
Denis wrote:
> (I know that this question is off-topic but I do not know in which newsgroup
> to post-it)
> I have a JCL question: Is it possible to reset the RC system variable in a
> JCL ? for example, with a statement like:
> // SET RC=0
> Obviously this statement does not work as RC it is not a normal "variable"
>
> The goal is to have a JCL like the following:
>
> //S1 EXEC PGM=P1
> ...
> // IF (RC GE 8) THEN <--- start of the "does not work" construction
> // SET RC=4 <--- does not work the idea is to "reset" the
> RC variable to 4
> // ENDIF <--- end of the "does not work"
> construction
>
> // IF (RC GE 4) THEN <--- want to test with RC = 4 even if S1 ended with
> RC=8
Robzenuk
JES internal RC variable appears to be off-limits
All the other comments have been off track since I believe you want to
basically ignore the RC of S1 if RC>8 and use a "generic" RC=4 test for all the
remaining steps.
Even though a simple REXX EXEC with 1 line can accomplish the simple set a
known RC trick (execute with IRXJCL):
exit(0) /* or whatever RC you want */
put this line a member of a PDS ("my.exec.pds" for this purpose) called
anything ("setrcpgm" for this purpose) and run the following JCL:
//SETRC EXEC PGM=IRXJCL,PARM=SETRCPGM
//SYSEXEC DD DSN=my.exec.pds,DISP=SHR
//SYSTSIN DD DUMMY
//SYSTSPRT DD SYSOUT=*
I have a couple questions that may color the value of the 'first attempt
response".
I'm assuming you want the job to start flushing all remaining steps if any step
(other than S1) gets an RC>4. Is this a true statement?
Do you want a JCL only solution?
Do you have any control over the logic in PGM=P1. Is this an inhouse or a
vendor program? Can you modify the program to return an RC<=4 ?
Is a "fix" to the ISPF dialog a viable alternative?
You mentioned that this is JCL generated from an ISPF dialog using FTINCL. Do
you know enough about the dialog to determine if it is using Table Services to
generate all the steps? If so, is the generated stepname a variable available
during File Tailoring services? If you find a )DOT statement in the skeleton,
that lets you know you are generating a skeleton from a Table. If the stepname
is available in the dialog, you could )SET a temporary variable in the skeleton
to hold the prior step's name. This could be used in the following step to
create a "tailored" IF statement.
// IF (prevstep.RC GE 4) THEN
If this is a viable alternative, look for a sequence of statements in the
skeleton that resemble the following:
.
.
)DOT tabname
// IF (RC GE 4) THEN
//&stepname EXEC PGM=.. <--- hopefully you will see something like this
//...
//...
// ENDIF
)ENDDOT
If you add a:
)SET PREVSTEP=&stepname
just before the )ENDDOT, you capture the previous stepname for the next loop.
At this point just modify the IF statement as follows
// IF (&PREVSTEP..RC GE 4) THEN
Obviously if PREVSTEP is already used in the dialog, this could cause problems,
but I think you get the point.
Hopefully, this helps. If not, sorry to waste your time.
Rob
Peter Flass
>
> There are two ways to do this:
>
> #2. Front-end the program with a harness; i.e., a program
> that CALLs, LINKs, or ATTACHes program P1 (al-
> most any "main" program in OS/MVS can be used as
> a "subroutine") and have the harness test the contents
> of R15 (or RETURN-CODE in COBOL, etc.) and re-
> set it accordingly, as per your requirements.
>
Rexx?
Thomas David Rivers
> Thomas David Rivers wrote:
>
> > Terry Heinze wrote:
> >
> > > You can't set the RC in JCL with a JCL statement, but you COULD exec a COBOL
> > > pgm that set the value of RETURN-CODE for the step the pgm was executed in.
> > > The value of the RC in your first step would remain that value for the
> > > during of the job. In other words, replace // SET RC=4 by // EXEC
> > > PGM=SETRC4 then test the result of the step executing SETRC4. Each step
> > > returns it's own RC, so in ob containing 4 steps, there are 4 different RCs
> > > you can test.
> >
> > Well - a COBOL program may be a little overboard; just write a quick
> > ASM program that puts 4 in R15 and does a BALR 14,15. That will
> > set the 4 as the RC.
> >
> > Something like:
> >
> > SET4RC CSECT
> > L 15,=F'4'
> > BALR 14,15 ???????????
> > LTORG
> > END SET4RC
>
> I think you are at the wrong end of the program for that instruction. Try
> LA 15,4
> BR 14
> after the registers have been restored. The BALR would load the address of the
> next instruction in Reg 14 and branch to the address in Reg 15, but the system
> wouldn't let you branch to low core.
> --
> Warren Porter - Remove digits
Opps - you're right! That's what I get for programming "in mail" :-)
Ken Foskey
I assume that you look this up and maybe even tried it and it did not
work. Ok here are a couple of suggestions:
1. The RC variable can be associated to a step. Might become painful
quickly though.
2. Break the JCL up into two jobs. The first does a iebgener (copy)
of the second JCL at the last step to the internal reader submitting
the job:
//sysut2 dd sysout=(*,intrdr)
3. WRite a simple program that simply calls the program in the
parameter, interrogates the return and changes an 8 to something
useful:
procedure division using called-program.
call called-program.
if return-code = 8
move 1 to return-code
end-if
stop-run
Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/
Michael Mattias
>(I know that this question is off-topic but I do not know in which
newsgroup
>to post-it)
http://www.mvshelp.com, go to "message boards."
Can't beat it for mainframe peer support.
MCM
Robert Ngan
// IF previous.RC <= 8 | RC < 8 THEN
//STEPnn EXEC PEM=blah
This allows you to restart at STEPnn, just specifying previous.RC means
you can never restart at STEPnn since non-executed steps always generate
a false result on a RC test.
In article <20000331124004...@ng-fa1.aol.com>,
robz...@aol.com says...
--
Robert Ngan
CSC Financial Services Group
Paul Knudsen
with JCL alone!
On Sat, 01 Apr 2000 01:15:28 GMT, "Michael Mattias"
<michael...@gte.net> wrote:
>http://www.mvshelp.com, go to "message boards."
>
>Can't beat it for mainframe peer support.
>
>MCM
>
>
>
---------------------------------------------------------------
SuSE Linux Users meet at: http://clubs.yahoo.com/clubs/suselinuxusers
Kerry
ie
file://STEP010 EXEC PGM=IDCAMS
//SYSOUT
//SYSIN *
SET MAXCC=0 or LASTCC if you prefer
/*
Then
//NEXTSTEP exec whatever proc/pgm, COND=(0,LT,STEP010) etc or use
// (IF RC ?? value)
.
//NEXTSTEP exec whatever proc/pgm
.
// ENDIF
You can also set PLIRETC = 0; in your PL1 program, which also may give you
the result you require
Kerry
"DennisHarley" <Legac...@email.msn.com> wrote in message
news:e7yEi8xm$GA.257@cpmsnbbsa05...
Don't know if this helps:
1) You can set the initial RC to 0 by executing IEFBR14.
If you test RC before a program has been executed, it is null.
2) You can nest your conditional JCL. I think 15 levels is the max.
3) There is also an ELSE condition which you can Use
4) You can break your job stream up into several jobs, and use the
internal reader to start them.
5) I don't know of any way to reset the RC for a JOB.
Denis <gros...@antispam.skynet.be> wrote in message
news:8c1rst$dnl$1...@hardcopy.ny.jpmorgan.com...
> (I know that this question is off-topic but I do not know in which
newsgroup
> to post-it)
> I have a JCL question: Is it possible to reset the RC system
variable in a
> JCL ? for example, with a statement like:
> // SET RC=0
> Obviously this statement does not work as RC it is not a normal
"variable"
>
> The goal is to have a JCL like the following:
>
> file://S1 EXEC PGM=P1
> ...
> // IF (RC GE 8) THEN <--- start of the "does not work"
construction
> // SET RC=4 <--- does not work the idea is to
"reset" the
> RC variable to 4
> // ENDIF <--- end of the "does not work"
> construction
>
> // IF (RC GE 4) THEN <--- want to test with RC = 4 even if S1 ended
with
> RC=8
> file://S2 EXEC PGM=P2