On Nov 3, 2006, at 10:41 PM, Chris Mason wrote:
Peter
John McKown and Matthew Stitt have almost certainly provided the
explanation
of what has happened.
It's always worth taking a good close look at the explanation of
the message
which is puzzling you before panicking.
Since this is a "user" program it's almost certain that the user
was unaware
of the requirement to put something sensible in register 15 before
exiting
back to MVS. The bottom 12 bits of the binary number that just
happens to be
sitting in register 15 when the program branches on register 14
back to MVS
gets presented as a return code in the IEF142I message.
This is the explanation of the condition code field of message
IEF142I:
<quote>
cde
The condition code from the contents of general purpose register 15
at the
end of the step. If the last task of the step did not set a
completion code
in register 15, the cde in the message is meaningless. In the event of
multiple failures in the same job step, the contents of register 15
refer
only to the last failure.
</quote>
----SNIP---------------
Agreed, I found a VS1 program (supplied by an OEM vendor) did not
bother to clear out reg 15 before exiting. It was writtern up by ops
as *MY* error. Took all of 15 seconds to find the code and to change
it. Luckily they had supplied the source. The ops jerks wanted to
back out the MVS conversion because of this. It took me all of 5
minutes to recompile and relink and an LLA refresh and we were back
up and running. The politics of a shop has a lot to do with stuff
like this. I think they were upset as MVS did not use the select next
for tape drive usage and they had to work harder at mounting tapes,
myself. The lower address tapes in VS1 were shot because of the tape
selection in the OS.
Ed
----------------------------------------------------------------------
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
