Re: How to diagnose 2F3

2013-08-14 Thread Jim Mulder
> In developing a new TCP/IP application I am causing our z/OS system to 
crash
> and I don't know how to determine the cause.  The only clue I can find 
is in
> the output for the job that was running, which shows an S2F3 abend code.
> After re-IPLing, the JES console shows typical application messages and 
then
> the beginning of the IPL sequence.
> 
> Using application debugging to a file (opening and closing for each 
write) I
> have determined that the program, a client TCP/IP application, has 
issued a
> write() of roughly 16K bytes, a shutdown(), and issued a read().  The 
read()
> request is successful, but as I wait on the ECB for the read to 
complete,
> the crash occurs.
> 
> Hint: The crash only occurs if the read() request times out.  Forcing a
> delay in the server's response such that the read() times out reliably
> causes the crash.  When no delay is introduced, the read() is successful 
and
> everything runs normally.  The length of the delay  has no impact as 
long as
> it times out (e.g. 10 second delay with an 8 second timeout or a 120 
second
> delay with a 115 second timeout).
> 
> This is a zPDT system running z/OS 1.10, however, I get identical 
results on
> our zPDT 1.13 system (load module transfer - no re-assembly).

*
>From MVS System Codes:

   2F3
Explanation: One of the following has occurred to a job which was 
journaled
  or was otherwise eligible for restart (checkpoint/restart, step restart,
  or job restart): 

The job was running when a system failure occurred, and a system restart 
(IPL and JES2 WARM start) was performed. 

The initiator the job was running in terminated at End Of Memory (EOM). 

A system job queue entry for the job existed at the time of the failure, 
but the specific step to be restarted at was not eligible for restart. 
**

  This means that the 2F3 is merely a symptom of your system crash,
not the cause.  To determine the cause, you would want to start 
by taking a standalone dump. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


How to diagnose 2F3

2013-08-14 Thread Patrick Roehl
In developing a new TCP/IP application I am causing our z/OS system to crash
and I don't know how to determine the cause.  The only clue I can find is in
the output for the job that was running, which shows an S2F3 abend code.
After re-IPLing, the JES console shows typical application messages and then
the beginning of the IPL sequence.

Using application debugging to a file (opening and closing for each write) I
have determined that the program, a client TCP/IP application, has issued a
write() of roughly 16K bytes, a shutdown(), and issued a read().  The read()
request is successful, but as I wait on the ECB for the read to complete,
the crash occurs.

Hint: The crash only occurs if the read() request times out.  Forcing a
delay in the server's response such that the read() times out reliably
causes the crash.  When no delay is introduced, the read() is successful and
everything runs normally.  The length of the delay  has no impact as long as
it times out (e.g. 10 second delay with an 8 second timeout or a 120 second
delay with a 115 second timeout).

This is a zPDT system running z/OS 1.10, however, I get identical results on
our zPDT 1.13 system (load module transfer - no re-assembly).

Where can I look for clues?

Thanks for any insight you can share.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN