🚀 go-pugleaf

On Fri, 31 Mar 2000 11:41:18 +0200, "Denis"
<grossnou@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
FAR@OES.FYNS-AMT.DK

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 <grossnou@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<

In article <8c1rst$dnl$1@hardcopy.ny.jpmorgan.com>,
Denis <grossnou@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
>
>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
>
>

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

docdwarf@clark.net wrote in message ...
>In article <8c1rst$dnl$1@hardcopy.ny.jpmorgan.com>,
>Denis <grossnou@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
>>
>>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
>>
>>
>
>

Thanks for the name of the NG and 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

Frank Allan Rasmussen wrote in message
<38e4a156.182679674@news.inet.tele.dk>...
>On Fri, 31 Mar 2000 11:41:18 +0200, "Denis"
><grossnou@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
>FAR@OES.FYNS-AMT.DK

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

I use a dumb little assembler program that sets the return code to 0 or
4 based on a parm.

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

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 -


--
rivers@dignus.com                         Work: (919) 676-0847
Get your mainframe (370) `C' compiler at http://www.dignus.com

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 <grossnou@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
> ...
> // 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
>
>

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

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.

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.B33B23C6@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
>               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 -
>
>
>--
>rivers@dignus.com                         Work: (919) 676-0847
>Get your mainframe (370) `C' compiler at http://www.dignus.com
>
>
>

In article <8c29vb$hkj$1@hardcopy.ny.jpmorgan.com>,
Denis <grosnou@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

In article <8c2drm$ir1$1@hardcopy.ny.jpmorgan.com>,
Denis <grosnou@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.
>
IEFSETRC CSECT
         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.

In article <8c2drm$ir1$1@hardcopy.ny.jpmorgan.com>,
Denis <grosnou@antispam.skynet.be> wrote:

[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

There are two ways to do this:

#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
> //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

Kerry Ellis wrote:
> 
> 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?

Warren Porter wrote:

> 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" :-)

    - Dave Rivers -



--
rivers@dignus.com                         Work: (919) 676-0847
Get your mainframe (370) `C' compiler at http://www.dignus.com

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/

Denis wrote in message <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...


http://www.mvshelp.com, go to "message boards."

Can't beat it for mainframe peer support.

MCM