How to end a REXX step with an abend?

Michael Ebert

unread,

Oct 15, 2003, 8:58:36 AM10/15/03

to

Hi List,

this is cross-posted to DB2-L and TSO-REXX.

How can I have a REXX step in a job abend (e.g. with S000 U1000)? There
should be no further side effects, e.g. I don't want a symptom dump in
JESMGSLG.
This was already asked by someone else on TSO-REXX 5 months ago, but with
unsatisfactory answers.

Background: for administration of my dozen DB2 subsystems, I generate &
automatically submit jobs - many dozens per day. Generally I'm not
interested in the output so I use MSGCLASS=Y which was set up by the MVS
team to disappear unless there is an abend. However, I often want to
retain a job output if a step ends with RC=4 or RC=8 as well. Currently
these are lost. I have things set up that I get an email in this case, but
it is missing information from the SYSPRINT of the failed step. Example
(abbreviated):

//useridS1 JOB (USERJOB,ME),'M.EBERT',CLASS=Y,MSGCLASS=Y,
// MSGLEVEL=(1,1),REGION=0M,NOTIFY=&SYSUID
//*=====================================================================
//* RUNSTATS on TS+IX in SSID DB2P.
//* Job created: 15OCT03:11:30:42
//*=====================================================================
//TERMUT PROC UTID=,DB=,TS=
//TERMUT EXEC PGM=IKJEFT1B,PARM='%TERMUT DB2P,&UTID,&DB,&TS'
//SYSEXEC DD DISP=SHR,DSN=userid.REXX.CNTL
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
// PEND
//*---------------------------------------------------------------------
//RST00001 EXEC PGM=DSNUTILB,COND=(EVEN),PARM='DB2P,userid.RST00001'
//SYSPRINT DD SYSOUT=* for RUNSTAT messages
//SYSIN DD *
RUNSTATS TABLESPACE BMCCM71E.BMCAL TABLE ALL INDEX(ALL KEYCARD...)
//TER00001 EXEC TERMUT,COND=((4,GT,RST00001),EVEN),
// UTID=userid.RST00001,DB=BMCCM71E,TS=BMCAL

In this case, the TERMUT REXX will get called if the RST00001 step abends
or ends with an RC>=4. Because all subsequent steps have EVEN coded as
well, the job will continue to execute. The TERMUT does cleanup for the
failed step and sends the email. This step normally gets bypassed. If it
gets called because the RUNSTATS encountered an error or warning, I want
it to step-abend so that the job output is kept for inspection.

Alternatively/additionally, is there an easy way of getting the SYSPRINT
output from the RST00001 step into a stem variable within the REXX
(without using e.g. a temp dataset for the SYSPRINT)?

Dr. Michael Ebert
DB2 Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

Arthur T.

unread,

Oct 15, 2003, 9:19:46 AM10/15/03

to

At 02:58 PM 2003-10-15 +0200, you wrote:
>I use MSGCLASS=Y which was set up by the MVS
>team to disappear unless there is an abend. However, I
>often want to
>retain a job output if a step ends with RC=4 or RC=8 as well.

If you also want to end the job as soon as the RC=4
or RC=8, you can code COND= on the job statement. This
will, in addition to stopping the job at the bad return
code, keep the MSGCLASS=Y output just as if an ABEND had
occurred. See JCL manual for confirmation and further
information.

--
Arthur T. - ar23hur "at" speakeasy "dot" net

Robert Lawrence

unread,

Oct 15, 2003, 10:15:37 AM10/15/03

to

Hi Michael,
I presume TERMUT is a proc that has a step calling the TMP program possibly IKJEFT01? If
it is then exec IKJEFT1B. This will direct the TMP to pass the completion code and user
return code back to the executing job stream. Be sure your REXX program ends on a RETURN n
where n is the return code you desire.
If you are executing a routine which has ISPF services then set VISPFRC(?SP) = your user
return code and then VPUT it.

HTH

Bob Lawrence
DBA
Boscov's Dept Stores LLc

Michael Ebert

unread,

Oct 15, 2003, 10:49:10 AM10/15/03

to

Hi all,

to comment on the responses so far:
1. I can't use a JOB COND as terminating the job is exactly what I don't
want. I want to continue processing.
2. I don't want to add another step to the two I currently have (per
task). I might have thousands; if I need three where I now need two, it
would increase the number of jobs by 50%.
3. The TERMUT is an instream proc (see example) which calls a REXX that's
also called TERMUT.
4. Setting an RC is not enough. I need an abend.
The solution which I had found before I decided to ask here was to have an
additional step at the end of the job doing the same sort of COND testing
as the TERnnnnn steps, but without specifying a step, so it would get
executed if the condition was fulfilled anywhere (I've checked that the
Job output will also be retained if the job fails before with a JCL ERROR,
e.g. because a dataset can't be allocated). I could then either call a
non-existing program (easy but messy) or a tiny SAS program that did
nothing but an ABORT ABEND 666 (clean but somewhat more difficult to set
up and maintain).

However, I would prefer to change the single TERMUT REXX, instead of all
the generator programs.

MfG, ME.

Hi Michael,
I presume TERMUT is a proc that has a step calling the TMP program
possibly IKJEFT01? If
it is then exec IKJEFT1B. This will direct the TMP to pass the completion
code and user
return code back to the executing job stream. Be sure your REXX program
ends on a RETURN n
where n is the return code you desire.
If you are executing a routine which has ISPF services then set
VISPFRC(?SP) = your user
return code and then VPUT it.

HTH

Bob Lawrence
DBA
Boscov's Dept Stores LLc

> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU]On Behalf
> Of Michael Ebert
> Sent: Wednesday, October 15, 2003 8:58 AM
> To: TSO-...@VM.MARIST.EDU
> Subject: How to end a REXX step with an abend?
>
>
> Hi List,
>

> How can I have a REXX step in a job abend (e.g. with S000 U1000)? There
> should be no further side effects, e.g. I don't want a symptom dump in
> JESMGSLG.

> ...

Ryerse, Robin

unread,

Oct 15, 2003, 11:55:51 AM10/15/03

to

I would expand upon the 'final step' concept but make it subject to a (JCL)
IF RC = 666. Herein the RC operand is not qualified by a procstep and/or
stepname. The TERMUT exec would set the RC to 666 provided PGM=IJKEFT1B (or
PGM=IRXJCL) is used.

Note that the unqualified RC on the JCL IF statement refers to the highest
return code for all the preceding steps.

Michael Ebert

unread,

Oct 15, 2003, 12:20:02 PM10/15/03

to

This has the advantage that if I decide to change the conditions for the
TERMUT call later, I don't have to change the conditions on the ABEND step
in a similar manner (e.g. currently I report MODIFY RCs of 8 or more, but
later I might want to report RC=4 as well)... good idea; I'll change my
current solution appropriately. An RC of 666 also makes the step RC in the
JESMSGLG stand out more.
Note that the original technique can be used in jobs where you generate
SQL using e.g. DSNTIAUL and then immediately execute it, i.e. it is
independent of the TERMUT REXX.

MfG, ME.

Hi all,

MfG, ME.

Robert Zenuk

unread,

Oct 15, 2003, 1:01:20 PM10/15/03

to

When I want a jobstream to stop in a specific step with REXX involved (and
standard condition code processing can't easily handle the situation) I force a
CANCEL in the REXX EXEC that should terminate the jobstream. Here is the
technique:

/*********************************************************************/
/* Get the current jobname */
/*********************************************************************/
jobname = mvsvar('SYMDEF',JOBNAME)
/*********************************************************************/
/* Chase down the current job number */
/*********************************************************************/
tcb = storage(21c,4)
jscb = storage(d2x(c2d(tcb)+180),4)
ssib = storage(d2x(c2d(jscb)+316),4)
jobnum = storage(d2x(c2d(ssib)+12),8)
/*********************************************************************/
/* Put out a message then CANCEL it */
/*********************************************************************/
say jobname jobnum 'canceled itself at' time() 'on' date()
"CANCEL" jobname"("jobnum")"

This results in a S222 abend and no other steps will run regardless of
condition code processing.

Good condition code processing is always preferable. Personally, I prefer
the newer JCL IF statement since it is much more intuitive and easy to determine
what should and will happen. It also provides better control of what will
happen with nesting, AND/OR support, conventional parentheses support and
setting up specific conditions for unique abend values as well as condition code
values.

<pet peeve>
Another comment regarding terminating REXX EXEC's, if you always finish your
code with EXIT(nnnn) you will always pass a valid RC to the OS regardless of
whether you use IKJEFT01 or IKJEFT1B. IKJEFT1B accounts for some poor
programming practices when imbedded TSO commands end with a nonzero RC. If you always
capture the RC in the EXEC and end with an EXIT(nnnn) statement your code
will always complete with the appropriate RC. This is the same issue as ignoring
the RETURN-CODE special register in COBOL and ending every program with a
zero return code regardless of the results (another reason why everyone tends to
forces abends in COBOL applications). In the case of EXEC's using the ISPF
ISPSTART command, ZISPFRC should be VPUT to accomplish the same results.
</pet peeve>

My two cents,

Rob

Saunders, William C

unread,

Oct 15, 2003, 2:01:28 PM10/15/03

to

1. To blow up, I use a separate step in my procs that executes COBOL's
abend routine, ILBOABN0. I built a customized proc for each utility, so
it's only a one line proc change to get it into our jobs:

//BLOWUP EXEC PGM=ILBOABN0,COND=(8,GT,IMAGCOPY)

That's really the way to go with the utilities, if only because of the
DD statements required. I even have a separate REORGR proc for
restarting a REORG, so I only have to add one letter to restart the job
in the middle of the night.

2. To get the abending command and the messages into my emails took a
bit of work. My REXX exec calls SDSF with a command file that displays
from the last DSNU050I message of the running job's last SYSPRINT and
strips this out of the screen print file. I also put a utility display
into the email. (The procs also have conditional steps to display
running jobs in SDSF and DB2 threads, which are helpful when trying to
figure out which jobs were butting heads in the wee hours.)