Not the problem. The problem appears to be a "permanent" data set allocation with a name like: SYS13036.Thhmmss.RA0.userid.COBLST. The ACS routines say that this allocation is not DSTYPE='TEMP'. So that test does not match. Eventually the STORCLAS falls down to the OTHERWISE which fails the allocation due to NON-STANDARD DATA SET NAME. Strangely, my boss has gotten around it by changing the DISP=(MOD,PASS) to DISP=(OLD,PASS) in the SCL for the Endevor processor.
On Tue, Feb 5, 2013 at 12:02 PM, John Eells <ee...@us.ibm.com> wrote: > Mike Wawiorko wrote: > >> SYS13036.T095110.RA0.TSH012.**COBLST >> >> At a quick glance this looks like a temporary dataset. Could you have two >> similarly named trying to be allocated within the same second 09:51:10? >> >> <snip> > > If so...it's worth a look at the ALLOCxx parmlib support we added in z/OS > V1.12, which should vastly reduce the probability of that sort of problem > occurring for temporary data sets. > > The keyword is SYSTEM TEMPDSFORMAT(UNIQUE|**INCLUDELABEL), and > INCLUDELABEL (the way the system used to act) is the default. > > -- > John Eells > z/OS Technical Marketing > IBM Poughkeepsie > ee...@us.ibm.com > > ------------------------------**------------------------------**---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
