I've been running on 2.1 for quite a while. Looked for a recent job that had some kind of 'space error'. Found one with actual x37 abends (but not directory block shortage.). The CAUSER report has a slightly different format according to whether the failure was in IEBCOPY, data transform, or binder. In each case there is a pointer to the relevant sysprint: 'THE SEQUENCE NUMBER WAS nnnnnn'. What you actually search for in the job output is
'SEQ # nnnnnn' I recommend focusing on the CAUSER report from the get-go because an SMPE run can show many x37 abends in the job log, but only unresolved failures after compress are reported in CAUSER. Those are the ones you really care about. . . 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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Gibney, Dave Sent: Saturday, September 24, 2016 10:26 AM To: [email protected] Subject: (External):Re: Binder: What happened to nice simple x37 abend Maybe my memory is of an IEC217I or other message. My real whine (and that's all it really is :) ) is that I think the info I am used to looking for was suppressed in favor of different (possibly more useful) info in a different place. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Gibney, Dave > Sent: Saturday, September 24, 2016 10:12 AM > To: [email protected] > Subject: Re: Binder: What happened to nice simple x37 abend > > 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- > [email protected]] > > On Behalf Of Jesse 1 Robinson > > Sent: Saturday, September 24, 2016 9:25 AM > > To: [email protected] > > 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 > > [email protected] > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM- > [email protected]] > > On Behalf Of Paul Gilmartin > > Sent: Friday, September 23, 2016 9:17 PM > > To: [email protected] > > 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 [email protected] with the message: INFO IBM-MAIN
