>>//NONSMS DD DISP=(OLD,DELETE),DSN=SFG.REX.NONSMS <<<non-sms dataset That did not include the VOL=SER= on the DD statement, so the catalog was updated.
On Tue, Apr 18, 2017 at 7:01 PM, Clark Morris <[email protected]> wrote: > [Default] On 18 Apr 2017 14:32:25 -0700, in bit.listserv.ibm-main > [email protected] (Pommier, Rex) 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 >> > It would have to be true if you are to be able to delete an > uncataloged SYS1.LINKLIB and leave the one in the catalog untouched > and still in the catalog. > > Clark Morris >> >>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 > > ---------------------------------------------------------------------- > 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
