Even though it violates everything about being "Managed by SMS". "IDCAMS Delete Noscratch" on a dataset that is SMS controlled will indeed leave the dataset on the volume. Found this out the hard way by the use of a restart/rerun vendor product. You can send me a note offlist and I can give you details.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Walt Farrell Sent: Thursday, March 22, 2012 9:36 AM To: IBM-MAIN@bama.ua.edu Subject: Re: UNABLE TO DELETE DUPLICTE DSN On Thu, 22 Mar 2012 06:24:01 -0700, John Dawes <jhn_da...@yahoo.com.au> wrote: > I am trying to delete a duplicate dsn via TSO. Since the cataloged version > which resides on volume MPR003 is in use, I thought that I could rename the > duplicate dsn > which resides on MPR027. However when I try to rename the dsn (via TSO) it > gave me the message "Duplicate data set name" followed by > "Data set is cataloged on a volume other than MPR027". Both volumes are > managed by SMS. Is there some other tactic I could employ? If you have appropriate authority via the RACF resource STGADMIN.DPDSRN.part-of-old-name you can rename the data set, but it must be non-SMS and non-VSAM. Search the z/OS library online for STGADMIN.DPDSRN and you'll find the 2 entries that describe this. But since you appear to have an SMS-managed data set I'm not sure what you can do. (How do you have an uncataloged SMS-managed data set?) -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
