And another fairly obvious alternative (but with possible political
issues) is to provide on-line documentation for every production job
which Operators are required to consult before reporting a problem,
which could tell them that RC=0002 on that step is acceptable (something
simple like text members in a PDS for each production job can be used
here). That rule would solve the problem even without a job scheduler.
And you could migrate to that mode of operation easily by defining
default rules for Operations to follow if there is nothing explicit for
a job and then providing explicit documentation for those jobs that
require different rules for success as bogus calls by Operations point
out which jobs need different rules documented.
If you have a production job scheduler (OPCS, CA-7, ZEKE, etc.), as
Peter has already mentioned you can have Operations define for an
individual job what maxcc constitutes successful execution, and
Operators should be trained to only call if the scheduler says the job
is "unsuccessful".
It is a semi-standard of IBM utilities that conditions that are most
likely fatal have cc>=8, and that having cc>=4 is required to indicate
some condition that might be a problem. It would not be unreasonable
then to define an installation standard that cc<4 from a step is OK, and
if there were any cases from applications programs that violated that
convention, one could require a following conditional step that forced a
more obviously-fatal error if one of those exceptional steps had a "bad"
cc < 4.
If the job failing is not a production job but a test job, then
reporting failures should not even be the responsibility of Operations.
Test jobs should be monitored by the submitter.
JC Ewing
On 11/28/2011 04:47 PM, Farley, Peter x23353 wrote:
One alternative is to use your scheduling software to permit RC=0002 or less from that
job to be marked "successful". OPCS can do this, we use that facility quite
regularly. Certain jobs are OK if any step returns RC=0004 or less, but 0008 or higher
is flagged as an error in the OPS lists. Only jobs flagged as errors in the scheduling
system need to be investigated.
I'm reasonably certain that other commercial-grade scheduling software has
similar capabilities.
HTH
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of John Dawes
Sent: Monday, November 28, 2011 1:16 PM
To: IBM-MAIN@bama.ua.edu
Subject: SETTING CONDITION CODE
G'Day,
Can I override a condition code so as to force it to a 0000? For example
the job-step executes successfully and puts out a COND CODE=0002. The job
continues on to the next step which is what we want. The reason I need a
0000 instead of a 0002 is because I get paged because the operator sees a
0002.
I tried the following by using IDCAMS:
//STEPCOND EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
IF MAXCC=0002 -
THEN -
DO -
SET MAXCC=0 -
END
//*
However this did not force a 0000 on the previous step. Is there a way I
can add the IDCAMS IF-THEN-DO logic in the step which is giving me the
headache? Or is there a way of forcing a 0000 on that step. Here is what
the (headache) step is doing:
//PRINTDS EXEC PGM=PRTDS,
// PARM=('DDNAME(INPDS)',
// 'SEA(.) REP(X''40'')',
// 'SYSOUT(X)')
//INPDS DD DSN=SYS2..INFO.CONFIG,DISP=SHR
//SYSPRINT DD SYSOUT=*
//*
--
...
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
