Re: COND CODE 3592

[Chris Mason]

I have been obliged to examine a response I made to this thread in
excruciating detail prompted by some private correspondence. In the course
of picking over the issue I may have managed to discover a fundamental
misunderstanding which has caused much "heat". So perhaps explaining it to
all and sundry may shed some "light" on the matter.

It concerns Phil Payne's post of Mon 6 Nov 2006 18:32:



> Maybe the program was converted from VSE which, in the days when it was
DOS anyhow, used an SVC macro to "end the job".

So, effectively, does z/OS.  ISTR that R14 in a jobstep programme points
directly at an SVC 3 instruction.   You used to be able to tell if you were
the jobstep programme by looking at that.



Many contributors pointed out that the test mentioned at the end of this
post does not really work since finding register 14 pointing to CVTEXIT (an
SVC 3 instruction) applies to any code entered using "supervisor assisted
linkage". Tony Harminc (Mon 6 Nov 2006 19:16) seems to suspect Phil's point
may apply to code entered using "programmer linkage", that is, the use of
the register 1, 13, 14 and 15 conventions when "calling" routines and "being
called by" routines. It is only Pat O'Keefe (Tues 7 Nov 2006 01:18) who
seems to have made the "programmer linkage" assumption - which I thought was
a misunderstanding until I realised
everyone else had jumped to possibly the wrong conclusion, namely, that that
Phil had "tasks" - and possibly other "supervisor assisted linkage" cases -
in mind rather than nested routines using "programmer linkage".

Chris Mason

--
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

Re: COND CODE 3592

[Chris Mason]

f understanding the word "effectively" in
this context. Is there perhaps a semantic gap here so that those close to
English soil use "effectively" one way while those who cast the soil off
their boots long ago assume a different meaning? I'm at quite a loss to
imagine what the alternative meaning might be.

Let's try a lighter ending:

By chance checking for another thread in another list/group I found a
reference to an IBM-MAIN post and, following up, I found it was mine but as
part of a thread where the absent object of this discussion was caught in a
lighter mood - last February. I had playfully suggested I was not going to
insist that points should be deducted because he had forgotten that
something supported by VSE was also supported by VM. His playful response
was that he accepted the guilt and the loss of points and observed that
memory was the second thing that suffered from age plus "I forget the
first".

This sort-of reminds me of an exchange in a TV police series set in Oxford
[2] where the inspector wants to have a word with a professor. The inspector
finds the professor in a lecture hall at the end of his lecture. The last
comment of the lecture is "I'm told there's a plaque on a house in Germany
which says 'Werner Heisenberg may have slept here.'." At the end of their
conversation, the inspector adds the question "That joke about Heisenberg, a
reference to the 'uncertainty principle', right?" The professor, rushing
off, says "I'm not sure."

[1] For any still interested readers, the missing sentence is 'Maybe the
program was converted from VSE which, in the days when it was DOS anyhow,
used an SVC macro to "end the job".'

[2] Lewis by himself, not Morse

Chris Mason

- Original Message - 
From: "Tom Marchant" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Friday, 10 November, 2006 2:50 PM
Subject: Re: COND CODE 3592


> On Fri, 10 Nov 2006 04:18:02 +0100, Chris Mason <[EMAIL PROTECTED]>
> wrote:
>
> >Shmuel
> >
> >Assuming my posts are being read sequentially, a good example.
> >
>
> A good example of what?
>
> Inadequate quoting?  He quoted Phil's entire post.
> Too terse reply?  He responded to each portion, the total post was
> most certainly a complete response.
>
> Yours, in contrast, did neither.  It wouldn't have been worth a
> response except for your complaints about the way others post.
>
> >
> >- Original Message -
> >From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]>>
> >> In <[EMAIL PROTECTED]>, on 11/06/2006
> >>at 04:14 PM, Phil Payne <[EMAIL PROTECTED]> said:
> >>
> >> >So, effectively, does z/OS.
> >>
> >> No.
> >
>
> --
> 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

Re: COND CODE 3592

[Tom Marchant]

On Fri, 10 Nov 2006 04:18:02 +0100, Chris Mason <[EMAIL PROTECTED]> 
wrote:

>Shmuel
>
>Assuming my posts are being read sequentially, a good example.
>

A good example of what?

Inadequate quoting?  He quoted Phil's entire post.
Too terse reply?  He responded to each portion, the total post was
most certainly a complete response.

Yours, in contrast, did neither.  It wouldn't have been worth a
response except for your complaints about the way others post.

>
>- Original Message -
>From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]>>
>> In <[EMAIL PROTECTED]>, on 11/06/2006
>>at 04:14 PM, Phil Payne <[EMAIL PROTECTED]> said:
>>
>> >So, effectively, does z/OS.
>>
>> No.
>

--
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

Re: COND CODE 3592

[Chris Mason]

Shmuel

Assuming my posts are being read sequentially, a good example.

Chris Mason

- Original Message - 
From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Thursday, 09 November, 2006 5:47 PM
Subject: Re: COND CODE 3592


> In <[EMAIL PROTECTED]>, on 11/06/2006
>at 04:14 PM, Phil Payne <[EMAIL PROTECTED]> said:
> 
> >So, effectively, does z/OS.
> 
> No.

--
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

Re: COND CODE 3592

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 11/06/2006
   at 04:14 PM, Phil Payne <[EMAIL PROTECTED]> said:

>So, effectively, does z/OS.

No.

>ISTR that R14 in a jobstep programme points directly at an SVC 3 
>instruction.

So does R14 after an ATTACH, LINK, XCTL, SVC (types 2-4) or scheduling
of an IRB. I don't guaranty that the list is complete.

>You used to be able to tell if you were
>the jobstep programme by looking at that.

Maybe in Release 1. Certainly not by Release 14.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: COND CODE 3592

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 11/06/2006
   at 07:52 PM, Binyamin Dissen <[EMAIL PROTECTED]> said:

>AFAIR R14 always pointed to SVC3 when supervisor assisted linkage,
>i.e. either LINK or ATTACH, was used.

You recall correctly. Specifically, it was the SVC 3 at CVTEXIT.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: Fw: COND CODE 3592

[Tom Marchant]

On Mon, 6 Nov 2006 18:02:59 -0600, Bill Klein <[EMAIL PROTECTED]> wrote:

>
>Now, I will admit that I could be mistaken, but I think that "not clearing"
>the registers impacts the system RETURN CODE (RC) and NOT the CONDITION CODE
>(COND CODE).

Same thing.  See for example the description if IEF142I and the COND
parameter in the JCL Reference.  When a job step ends normally, the return
code register 15 becomes the condition code.

-- 
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

Re: COND CODE 3592

[Gerhard Postpischil]

Patrick O'Keefe wrote:

How about for all those recursively invoked routines that could also be
executed as a main task.  You could know when to stop unwinding when R14
pointed at the SVC.  (Ok.  No such program was ever written.  But it
coulda.)


Are you sure? I once wrote a very small program:

SVC  12
END

after somebody told me that an unprivileged program couldn't 
crash the system. Under SVS and later systems this has been 
fixed.


Gerhard Postpischil
Bradford, VT

--
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

Re: COND CODE 3592

[Patrick O'Keefe]

On Mon, 6 Nov 2006 14:56:44 -0500, Bruce Black <[EMAIL PROTECTED]> 
wrote:

>... so your test for "jobstep task" was never valid.
>...

Never?  A chalange to pedantic readers.

How about for all those recursively invoked routines that could also be
executed as a main task.  You could know when to stop unwinding when R14
pointed at the SVC.  (Ok.  No such program was ever written.  But it
coulda.)

Pat O'Keefe

--
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

Fw: COND CODE 3592

[Bill Klein]

Because there have been all sorts of notes on COBOL and setting the COND
CODE (if RETURN-CODE) hasn't been cleared, I thought I would post a
reference to:

 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg31/4.2.4.1 

Now, I will admit that I could be mistaken, but I think that "not clearing"
the registers impacts the system RETURN CODE (RC) and NOT the CONDITION CODE
(COND CODE).

For "good COBOL coding techniques" related to this, see also:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg31/3.1.1.3 

and

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg31/3.2.2.6 

--
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

Re: COND CODE 3592

[Jeffrey D. Smith]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Tony Harminc
> Sent: Monday, November 06, 2006 11:16 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: COND CODE 3592
> 
> Phil Payne wrote:
> 
> > > Maybe the program was converted from VSE which, in the days
> > when it was DOS anyhow, used an SVC macro to "end the job".
> >
> > So, effectively, does z/OS.  ISTR that R14 in a jobstep  programme
> points
> directly
> > at an SVC 3 instruction.
> 
> It points at CVTEXIT, which contains a handy SVC 3. Unless you are running
> under TSO TEST, in which case it points to an SVC 97, which has fooled
> more
> than one program that tries to decide if its task is about to end.
> 
> > You used to be able to tell if you were the jobstep programme by looking
> at that.
> 
> That I doubt; all programs initially getting control from the operating
> system have R14 pointing at CVTEXIT.
> 
> Tony H.

ISTR that an SRB program has R14 pointing elsewhere.

/J

--
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

Re: COND CODE 3592

[Craddock, Chris]

> > ISTR that R14 in a jobstep programme points
> > directly at an SVC 3 instruction.   You used to be able to tell if
you
> were
> > the jobstep programme by looking at that.
> An ATTACHed subtask also gets an R14 that points to the SVC 3 (EXIT)
in
> the CVT, so your test for "jobstep task" was never valid.

Not just any freshly attached task, but -any- new RB also gets the
address of CVTEXIT in R14. So any program entered via SYNCH, LINK or
XCTL, or any of the mechanisms for scheduling IRBs, or any type 2-4 SVC
will have that value. Put differently, the situation where
(R14->CVTEXIT) is as common as dirt and has nothing at all to do with
being a job step or not. 

If you want to know your TCB is a job step TCB, then compare its address
with the value in TCBJSTCB. If they are the same, then it's a job step
TCB. Otherwise, its not.

CC

--
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

Re: COND CODE 3592

[Bruce Black]

ISTR that R14 in a jobstep programme points
directly at an SVC 3 instruction.   You used to be able to tell if you were
the jobstep programme by looking at that.
An ATTACHed subtask also gets an R14 that points to the SVC 3 (EXIT) in 
the CVT, so your test for "jobstep task" was never valid.


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

--
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

Re: COND CODE 3592

[Tony Harminc]

Phil Payne wrote:

> > Maybe the program was converted from VSE which, in the days 
> when it was DOS anyhow, used an SVC macro to "end the job".
> 
> So, effectively, does z/OS.  ISTR that R14 in a jobstep  programme points
directly 
> at an SVC 3 instruction.

It points at CVTEXIT, which contains a handy SVC 3. Unless you are running
under TSO TEST, in which case it points to an SVC 97, which has fooled more
than one program that tries to decide if its task is about to end.

> You used to be able to tell if you were the jobstep programme by looking
at that.

That I doubt; all programs initially getting control from the operating
system have R14 pointing at CVTEXIT.

Tony H.

--
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

Re: COND CODE 3592

[Binyamin Dissen]

On Mon, 6 Nov 2006 16:14:21 - Phil Payne
<[EMAIL PROTECTED]> wrote:

:>> Maybe the program was converted from VSE which, in the days when it was
:>DOS anyhow, used an SVC macro to "end the job".

:>So, effectively, does z/OS.  ISTR that R14 in a jobstep programme points
:>directly at an SVC 3 instruction.   You used to be able to tell if you were
:>the jobstep programme by looking at that.

When?

AFAIR R14 always pointed to SVC3 when supervisor assisted linkage, i.e. either
LINK or ATTACH, was used.

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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

COND CODE 3592

[Phil Payne]

> Maybe the program was converted from VSE which, in the days when it was
DOS anyhow, used an SVC macro to "end the job".

So, effectively, does z/OS.  ISTR that R14 in a jobstep programme points
directly at an SVC 3 instruction.   You used to be able to tell if you were
the jobstep programme by looking at that.

-- 
  Phil Payne
  http://www.isham-research.co.uk
  +44 7833 654 800

--
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

Re: COND CODE 3592

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Peter Ten Eyck
> Sent: Monday, November 06, 2006 8:04 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: COND CODE 3592
> 
> 
> Thanks for your comments. I have look at the user program. It 
> is a Cobol 
> program which calls some type of assembler access program. I 
> have told the 
> programmer to track down the source if possible and review 
> the condition 
> code handling code. Thanks

Or just ask him to insert the line:

MOVE ZEROS TO RETURN-CODE

just before the GOBACK or STOP RUN verb(s).

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
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

Re: COND CODE 3592

[Peter Ten Eyck]

Thanks for your comments. I have look at the user program. It is a Cobol 
program which calls some type of assembler access program. I have told the 
programmer to track down the source if possible and review the condition 
code handling code. Thanks

--
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

Re: COND CODE 3592

[Ed Gould]

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:




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.



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

Re: COND CODE 3592

[Chris Mason]

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:



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.



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: 
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: 
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: 
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?

- Ori

Re: COND CODE 3592

[Tom Marchant]

On Fri, 3 Nov 2006 15:32:48 -0600, Peter Ten Eyck
<[EMAIL PROTECTED]> wrote:

>I have a job ... 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 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.

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

Re: COND CODE 3592

[Matthew Stitt]

Is it possible the program is not clearing register 15 to zero before
returning to the operating system?

On Fri, 3 Nov 2006 15:32:48 -0600, Peter Ten Eyck
<[EMAIL PROTECTED]> wrote:

>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?

--
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

Re: COND CODE 3592

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Peter Ten Eyck
> Sent: Friday, November 03, 2006 3:33 PM
> To: IBM-MAIN@BAMA.UA.EDU
> 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?

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

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
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

COND CODE 3592

[Peter Ten Eyck]

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?

--
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