Yes, ALLOCxx is what I could not find. Just wondering if that setting could account for different behavior at various shops.
And yes, ISPF 3.4 from a volume list does make additional checks for catalog consistency. In our case, the user attempted to use the delete *command* (rather than 'd') on a volume list for an uncataloged dataset. Of course not successful. . . 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 Pommier, Rex Sent: Tuesday, April 18, 2017 10:52 AM To: [email protected] Subject: (External):Re: unCATALOG after a RENAME (rename a non-VSAM file.) 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
