Might have been a decade ago. But putting in the VOLSER stops the update to the catalog.
On Tue, Apr 18, 2017 at 4:33 PM, Pommier, Rex <[email protected]> wrote: > Mike, > > Are you sure? Running 2.2 right now, but I'm pretty sure my 1.13 system > functioned the same: > > //RRPDELTE JOB CLASS=A,MSGCLASS=X, > // MSGLEVEL=(1,1),NOTIFY=&SYSUID > IEFC653I SUBSTITUTION JCL - CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=RRP > //STEP001 EXEC PGM=IEFBR14 > //NONSMS DD DISP=(OLD,DELETE),DSN=SFG.REX.NONSMS <<<non-sms dataset > //SMS DD DISP=(OLD,DELETE),DSN=RRP.REX.SMS <<<SMS dataset > > ICH70001I RRP LAST ACCESS AT 14:36:43 ON TUESDAY, APRIL 18, 2017 > IEF236I ALLOC. FOR RRPDELTE STEP001 > IEF237I 1007 ALLOCATED TO NONSMS > IGD103I SMS ALLOCATED TO DDNAME SMS > IEF142I RRPDELTE STEP001 - STEP WAS EXECUTED - COND CODE 0000 > IEF285I SFG.REX.NONSMS UNCATALOGED > IEF285I VOL SER NOS= Z1SW02. > IEF285I SFG.REX.NONSMS DELETED > IEF285I VOL SER NOS= Z1SW02. > IGD105I RRP.REX.SMS DELETED, DDNAME=SMS > > > Rex > > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Mike Schwab > Sent: Tuesday, April 18, 2017 3:38 PM > To: [email protected] > Subject: Re: unCATALOG after a RENAME (rename a non-VSAM file.) > > 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 > > > 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
