There is a parmlib option to abend NOT CATLG 2. I recommend using it. IMO, SMS should be set up for all allocations and the fallback pathway to storage volumes blocked. Back in the "old days", we did experience the scenario you describe. After the same dataset name appeared on all available volumes, then the abend would occur.
I am also a strong believer in the philosophy "If it ain't cataloged, it doesn't exist". I feel free to whack any such I find in the application storage pools. They have always (so far) been the result of an error. Dave Gibney Information Technology Services Washington State University > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Tom Marchant > Sent: Thursday, May 31, 2012 2:38 PM > To: [email protected] > Subject: Re: Allocation mystery > > On Thu, 31 May 2012 15:25:04 -0600, Steve Comstock wrote: > > >I run a job that creates a new data set using > >this DD statement: > > > >//NEWMAST DD DISP=(NEW,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA, > >// LIKE=STNT329.TRAIN.ZINPUTA > > > >Job runs fine and creates the new file. > > Is the data set SMS managed? > > >Now I run it again; I expect it to fail with 'DUPLICATE > >DATA SET NAME' - but it doesn't. Instead, it goes ahead > >and allocates the file on a storage volume and gives me > >a zero completion code; just doesn't catalog the data > >set. > > Storage volume suggests that it is allocated to a non-managed > volume. This is not unusual. Did you receive a NOT CATLGD 2 > message? > > -- > Tom Marchant > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
