Asking if to update the catalog was added about 4 years ago or so. Still does not apply to JCL. //deluncat EXEC PGM=IEFBR14 //ddname1 DD DSN=data.set.name,VOL=SER=nonsms,DISP=(OLD,UNCATLG) //ddname2 DD DSN=data.set.name,VOL=SER=nonsms,DISP=(OLD,DELETE) Both DDs are required for non-sms. Leave the volser off and you only need the delete.
On Tue, Apr 18, 2017 at 12:51 PM, Pommier, Rex <[email protected]> wrote: > Skip, > > Also you might want to check some of your ISPF settings. I just ran a bit of > a test. Built a dataset on a non-SMS volume, then used ISPF 3.4 to display > the volume and then tried to delete the dataset. I got a pop-up asking me to > confirm the delete, as well as asking me if I wanted to uncatalog it as well: > > <quote> > Confirm Delete > Command ===> > > Data Set Name . : SFG1B.REX.JUNK > Volume . . . . : Z2SW01 > Creation date . : 2017/04/18 > > Enter "/" to select option > / Uncatalog data set upon deletion > > You have specified a volume serial for the data set you want deleted. > The data set is also cataloged on that volume. In addition to deleting > the data set, indicate above if you want the data set uncataloged. > > Enter "/" to select option > Set data set delete confirmation off > > Instructions: > Press ENTER to confirm delete. > Press CANCEL or EXIT to cancel delete. > > </quote> > > > I also tried renaming my source dataset and ISPF again asked me what I wanted > to do with the catalog: > > <quote> > > You have specified a volume serial for the data set you want renamed. The > data set is also cataloged on that volume. In addition to renaming the data > set, you should select the "Catalog the new data set name" selection field > if you want the data set cataloged. If you do not, then the data set will > be renamed and the catalog entry for the old data set will be not deleted > or altered. > </quote> > > HTH > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Jesse 1 Robinson > Sent: Tuesday, April 18, 2017 12:02 PM > To: [email protected] > Subject: Re: unCATALOG after a RENAME (rename a non-VSAM file.) > > A subtle gotcha emerged here recently. If you build a dataset list in ISPF > 3.4 by DSN, actions on datasets in the list will invoke IDCAMS-like actions. > Example, 'D' will attempt to delete both catalog and VTOC entries. 'R' will > also attempt both. > > If you build a list by VOLSER, only volume-level actions will be attempted. > Hence no uncatalog; that action will fail for an SMS dataset, which by > definition must be cataloged. Another failing action is for a dataset that is > defined as multivolume even if the entire allocation actually resides on just > this volume. > > This can be confusing because the displayed list looks pretty much the same > whether it was built from catalog or VTOC. OTOH results should be consistent > every time. Also, although I can't find it now, isn't there something in > PARMLIB that specifies the response to catalog 'anomalies' like trying to > catalog a dataset that's already cataloged? Before this knob, failure to > (re)catalog resulted in nothing more than an info message in joblog instead > of JCL error. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > [email protected] > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Mike Schwab > Sent: Tuesday, April 18, 2017 8:56 AM > To: [email protected] > Subject: (External):Re: unCATALOG after a RENAME (rename a non-VSAM file.) > > If you specify the volser for a non-sms dataset, the catalog is not accessed, > and the rename does not update the catalog, and you need to manually update > the catalog. > > On Tue, Apr 18, 2017 at 10:18 AM, Thomas David Rivers <[email protected]> > wrote: >> retired mainframer wrote: >> >>> Run some test cases, at least one for an SMS volume, at least one for >>> a non-SMS volume: >>> List the catalog entry for the old DSN >>> List the catalog entry for the new DSN (expect failure) >>> List the VTOC for the old DSN >>> List the VTOC for the new DSN (expect failure) >>> Rename the dataset >>> List the catalog entry for the old DSN (expect failure for an SMS >>> dataset) >>> List the catalog entry for the new DSN (expect failure for a >>> non-SMS >>> dataset) >>> List the VTOC for the old DSN (expect failure) >>> List the VTOC for the new DSN >>> Uncatalog the old DSN (expect failure for SMS dataset) >>> List the catalog entries for both old and new DSNs >>> Catalog the new DSN (expect failure for SMS dataset) >>> List the catalog entries for both old and new DSNs Draw >>> conclusions about who does what to whom. >>> >>> Are any of the datasets VSAM in disguise, such as PDSE or ZFS? >>> >>> >>> >> Hi! >> >> That's not a bad idea - except that in-house, I get no errors; this is >> at a customer site (and the errors are strange - return-code=8 and >> reason-code=8 >> from the unCATALOG; that reason-code is undocumented for that >> return-code.) >> >> The data sets are not VSAM - just a "flat" sequential file. >> >> It's interesting that I can't seem to arrive at a _definitive_ "This >> is the proper way to rename a non-VSAM file" statement. I can't find >> anything in the doc, etc... >> and while an act-of-discovery will probably get me something that >> "mostly works", one is not assured it would be guaranteed to work into >> the future, etc... >> >> I find this situation strange of such a venerable operating system, >> and it makes me think that I must not be understanding something >> fundamental... because surely such an operation as renaming a file >> must be well defined and well understood and easy to communicate. >> >> But - no answer has been forthcoming here, and my scouring of DFSMS >> documentation hasn't yielded anything fruitful; so... looks like >> experimentation is what is left... >> >> Unless, another pair of eyes has seen some kind of documentation or >> example of "this is the proper way to rename a non-VSAM file." >> >> - Dave R. - >> >> -- >> [email protected] Work: (919) 676-0847 >> Get your mainframe programming tools at http://www.dignus.com > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to this message and destroy the material in its entirety, whether in > electronic or hard copy format. Thank you. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
