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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mike Schwab
Sent: Tuesday, April 18, 2017 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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 <rpomm...@sfgmembers.com> 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:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
> Sent: Tuesday, April 18, 2017 12:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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
> robin...@sce.com
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mike Schwab
> Sent: Tuesday, April 18, 2017 8:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 <riv...@dignus.com>
> 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. -
>>
>> --
>> riv...@dignus.com 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 lists...@listserv.ua.edu 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 lists...@listserv.ua.edu 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
lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
