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> I bet that "last task of the step did not set a completion code in register 15" and so "the cde in the message is meaningless". Maybe the program was converted from VSE which, in the days when it was DOS anyhow, used an SVC macro to "end the job". A "user program" is most unlikely to have a complicated return code value like 3592 - or - if it did, the programmer would surely have made sure there was an explanation of such complexity available. Contrary to what Tom says, it is also almost certain that the program ran perfectly correctly - according to its own lights - and you have nothing to worry about. You can, of course, adjust the neck size of the programmer down one size while explaining that he (if it's "she" you might adopt a more subtle approach) should pay attention to his (her) register 15s on exit - or make sure "operations" has an explanation of his (her) exotic return codes. I appreciate you assumed there was some general convention on return codes which even got you Googling. Indeed there is a convention for such numbers but there's every likelihood any one programmer will invent his/her own standards. The convention is as follows: 0 is everything is perfect 4 there's something not quite right but, in principle, the program functioned successfully; for example, there was no data to process 8 the program will need to be re-run once the problem or problems, one hopes separately identified, has/have been sorted out In other words 0 is good, 4 is "warning" and 8 or higher spells disaster. If the return code number follows the convention of increasing (by 4 conventionally) with severity, I hate to think what Armageddon 3592 is describing. Chris Mason ----- Original Message ----- From: "Peter Ten Eyck" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Friday, 03 November, 2006 10:32 PM Subject: COND CODE 3592 > I have a job on z/OS 1.4 which uses tape (3490). The step runs a user > program which appears to run to competition OK, but the job steps ends as > follows: > > IEF142I USTXISOP USTXISOP ISOATEDG - STEP WAS EXECUTED - COND CODE 3592 > > > I am having difficulty finding what this condition codes means. It does not > help matters that 3592 also happens to be a tape drive model number. A > search through all message books on the z/OS 1.4 site does not yield a > meaningful answer. Google is not to helpful either. What is a 3592? ----- Original Message ----- From: "McKown, John" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Friday, 03 November, 2006 10:40 PM Subject: Re: COND CODE 3592 > > What program is it running? Each program is free to issue any return > code from 0 to 4095 that it wants to. > > However, it is likely that somebody simply forgot to zero register 15 > before returning back to z/OS. I've seen this happen with COBOL that > calls assembler. The assembler program does not set the return code, so > register 15 contains the address of the assembler program upon return to > COBOL. COBOL then copies this into RETURN-CODE and the programmer never > does a MOVE ZERO TO RETURN-CODE to reset it because "I never modified > RETURN-CODE, so that can't be the problem!". Well, it was modified, > implicitly, by calling the assembler subroutine. > > -- > John McKown > Senior Systems Programmer > HealthMarkets > Keeping the Promise of Affordable Coverage > Administrative Services Group > Information Technology > ----- Original Message ----- From: "Matthew Stitt" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Friday, 03 November, 2006 10:57 PM Subject: Re: COND CODE 3592 > Is it possible the program is not clearing register 15 to zero before > returning to the operating system? ----- Original Message ----- From: "Tom Marchant" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Saturday, 04 November, 2006 2:49 AM Subject: Re: COND CODE 3592 > A program can set any condition code. The only place where you can > find it is in the documentation for the user program. Or perhaps > you can figure it out from the source. > > I assume that you have no documentation for the program. If it's an > in-house written program, you could ask the programmer. > > The program was obviously not adequately tested. I would conclude > from that that it did not run correclty. > > Tom Marchant ---------------------------------------------------------------------- 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
