The error in the CAUSER report was that the Linkage return was > 4 and it did 
not point to the SISFLOAD. It did point to the SMPnnnnn report, which was quite 
long in the first run.
Before 2.1, I believe I would have seen an also seen an error in the job log 
which would have quickly told me to expand the SISFLOAD directory. 

This is my first APPLY running under 2.1. I don't have a 1.13 left and am not 
inclined to play at recreating my problem anyway.

Yes, it was not really hard to find in my second pass and I probably could have 
looked harder at the first. The newer message is fine, but suppressing the old 
is questionable.

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
> Sent: Saturday, September 24, 2016 9:25 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Binder: What happened to nice simple x37 abend
> 
> I'm with those who are surprised that a directory-full condition would result
> in x37, which I associate with the management of data set extents. In any
> case I would certainly expect the error to show up in the CAUSER report,
> which lists all (well, mostly all) unresolved errors during sysmod
> APPLY/ACCEPT. I would hope that the CAUSER message would clearly state
> the exact problem. If not, it should direct you to the specific SYSOUT (SEQ
> #nnnnn) that shows the error in detail. When I look at an APPLY/ACCEPT job,
> CAUSER is my first destination.
> 
> If this error was not reported in CAUSER, then I think an SR would be in
> order.
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Friday, September 23, 2016 9:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Binder: What happened to nice simple x37 abend
> 
> On Fri, 23 Sep 2016 16:55:54 -0700, Tom Brennan wrote:
> 
> >I don't get it.  A PO directory size is fixed, so why would we ever get
> >into x37 extent processing from STOW?  Maybe I just don't understand.
> >
> But the message said nothing about extent processing:
> 
> >>>>IEW2736S DA10 THERE IS NO SPACE LEFT IN THE DIRECTORY FOR
> DDNAME
> >>>>SISFLOAD.  STOW OF THE DIRECTORY ENTRY MEMBER NAME
> >>>>        HSFKYWDU FAILED.
> 
> Actually, a DSNTYPE=PDS directory size is fixed which caused the problem.
> DSNTYPE=LIBRARY directories are expandable and the problem would not
> have occurred (unless expanding the directory got the x37).
> 
> I don't know that x37 ever occurred.  The IEW2736S was probably explaining
> the RC from STOW.
> 
> The wording in the IEW2736S message shown is actually slightly clearer than
> the M&C.  I doubt that it merits a RCF.
> 
> -- gil
> 
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Reply via email to