On 11/25/2010 07:37 PM, Shmuel Metz (Seymour J.) wrote:
In<listserv%[email protected]>, on 11/22/2010
at 10:11 AM, Paul Gilmartin<[email protected]> said:
o Place JCL error messages inline, as HLASM does, so the programmer
would be spared the need to swap between JESYSMSGS and JESJCL.
They used to, back in OS/360 and OS/VS2 R1 (SVS). Making it harder to
find errors was one of the enhancements in MVS.
Actually this touches a minor raw nerve because we stumbled on a bizarre
case recently where an inline JCL error message (without a msgid) buried
among 100's of lines of JCL was the ONLY indication of a JCL error
visible in the output from a production job submission. At the end of
the job output was the only easily visible error message which indicated
the job had been cancelled by JES or by the operator, with no
explanation of "JCL-Error" as the cause or the usual line pointer to the
statement in error. Supposedly in this case a "JCL error" message is
sent to the TSO userid associated with the job, but this is useless for
a production job that runs under a non-TSO userid. As a result of the
unseen, buried error message, the Operators misinterpreted the nature of
the error and took some incorrect actions that eventually resulted in
loss of production data from a previous run.
What we discovered was that a spurious "/*" JES2 statement in the middle
of JCL - probably originally a typo where "//*" was intended - causes no
undesirable effects, UNLESS it immediately follows a JCL statement on
which a bogus continuation comma is left. A "trivial" JCL modification
created such a condition, and JES2's response was to fail the job during
input processing (before JESJCL and JESYSMSGS are created). As a result
the job never made it to converter processing, at which point a more
normal-appearing JCL error message could have been produced. I suspect
any JES2 statements starting with "/*" preceded by a JCL statement with
trailing comma will get similar results, but in our shop "/*" is the
only JES2 statement we would ever find in the middle of a large JCL deck.
IBM's explanation is that input processing has always worked that way as
a consequence of backward scanning from the point of JES2 statements,
but it makes no sense to us why input processing dealing with JES2
control statements should be sensitive to any syntax errors in non-JES2
JCL statements that are unrelated to in-stream data, or for that matter
why backward scanning rather than forward scanning would be used. I
never have liked WAD or longevity as a excuse for a design flaw, but if
it took us 25 years to have this case be an issue and since there are
easy circumventions (e.g, don't misuse "/*", use JCL checking for
"trivial" changes), there are probably better things for IBM to fix.
In any event, while having both in-stream and out-of-stream error
messages would be nice (which HLASM does support), if we had to choose
between only one or the other for JCL, having a clearly visible and
correct out-of-stream error message is much preferable to having only a
buried in-stream message.
--
Joel C. Ewing, Fort Smith, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
