We have a LNKPDSE0 member we execute in IEACMD00 that adds a new linklist name, adds the PDSE libraries to the linklist and activates the new name. All other tasks key through automation off of the success of that linklist name before starting additional tasks.
(There are some IBM required PDSE libraries we leave in the IPL linklist - but we don't try to do dynamic maintenance on those and build new IPL volumes for those. Choice is IPL linklist or dynamic refreshes - can't do both). Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 623 869 5523 Corporate Tieline - 85523 If you feel in control you just aren't going fast enough. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Wednesday, June 21, 2017 2:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL: Re: PDSE dataset rename issue I must have snoozed through this thread in 2005 because I have no recollection. I trust that no linklist PDSE is desperately required before the first 'add' command can be executed. Where do you put them and what do they look like? . . 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 Jerry Whitteridge Sent: Wednesday, June 21, 2017 12:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: EXTERNAL: Re: PDSE dataset rename issue This reminded me of why we do NOT allow PDSE in the IPL Linklist and add them dynamically after IPL Please look at https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/zY1MefkB9po Where you will see mentioned: Until yesterday I didn't realize a PDSE LNKLST'd at IPL could not be deleted, not even if removed from active LNKLST. IBM pointed me to APARs OW40072/OW57609/OW57671 which describe the inability to delete as a 'permanent restriction'. These APARs are noted in PDSE usage Redbook, but haven't found any applicable info in MVS Init and Tuning. When a LNKLST'd PDSE delete attempt, error recieved is: IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (043D57D3) Chasing the '57D3' in DFP diagnosis shows: Unable to delete the data set because it's currently connected on this system. It appears DFSMS does a 'global connect' for LNKLST'd PDSEs, but there is no 'global disconnect' resource. Peter Relson of IBM eluded to the issue on this list (June 2005), "A reason I did not mention PDSEs is that you cannot delete a PDSE that was in the IPL-time LNKLST regardless of whether it is no longer in any active LNKLST set.". I suspect this is the OP's actual problem. Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 623 869 5523 Corporate Tieline - 85523 If you feel in control you just aren't going fast enough. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Tuesday, June 20, 2017 2:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL: Re: PDSE dataset rename issue Ok, time for me to jump in and out, since it seemed nothing is happening... To Venkat Kulkarni : >... to add new SYS1.SIEKLNKE dataset into system. Are you sure of the spelling? >But this dataset was allocated to LLA and XCF. So, we unallocated to linklist >and stop LLA. It is not enough. But see below my comments. >After this, we tried renaming this dataset using ispf 3.4 to .old but system >didnt allowed and received below error. If there is an enqueue, did you press PF01 to see who all is using it? >IEC614I rename failed rc 08 diagnostic information 040B0426, 914 Is this the full message? if not, please post it fully from start to end and all lines. Also post any message(s) on the SYSLOG too. You have gotten many replies and you also posted your answers, but I have more questions. 1. Did you looked EVERY WHERE that dataset is used / allocated? This includes your own TSO session. 2. Did you checked EVERY LPAR(s) in the SysPlex for usage by all XCFAS and LLA? 3. Do you have ALTER authority to the OLD and NEW names? 4. Do you have UPDATE access to the relevant Catalog where that entry is sitting? 5. There is a possibility that the dataset is cataloged, but the catalog is not in your system from where you tried to do the rename action. (In other words, catalog is connected, but the catalog is managed in another system, meaning you could have your catalogs not setup properly across your sysplex.) To highlight this, in my own two SysPlexes, we have a User Catalog which is shared between the two SysPlexes. RACF is setup so that ALTER is granted to one SysPlex on these catalog entries, but at most Update at other Sysplex to those same entries. So you do the rename on the system where you have ALTER access and there is NO enqueue at all. >... it says about required authentication issue. but I feel, i have all >required authority to alter this dataset. Really? See my comments above. >Is it something to do with using 3.4 option and system check this dataset in >other system master catalog and doesnt allow us to rename or some other reason. Probably, see my comments above. Did you tried out Lizette Koehler's suggestion? 1) Is the SYS1.SIEKLNKE currently in the LINKLST? If so, are you just refreshing the library? 2) If SYS1.SIEKLNKE does not current exist, you could build a new LINKLST and add it to the new list. >now, I thought of creating new dataset in different volume as current one and >then uncatalog the current dataset and then rename the new dataset to current >one. I hope this should work. No, you said it is in another system Master Cataolg. Better check all your Catalog entries in all systems before proceeding. Ask your Storage Admin Team for assistance. >But I am still surprised that why after un allocating the linklist and then P >LLA command, system is not allowing me to rename current dataset. I am not surprised. Did you check all LPARs and all SysPlexes where that dataset is used/allocated? As Giliad Wilf said, this is a "pinned' dataset, you will have trouble renaming that dataset. You're better off to setup new PROGxx members with NEW names and IPL all and every LPARs. In this way you can then get rid of the old name. Thus, make a NEW copy, change your PROGxx and IPL everywhere. Then you can then delete/rename the old dataset. I would advise you to really properly listen to Jim Mulder's caution. He is one of those IMBer you simply can't argue with... If you are still not successfully, please tell us EVERY step you tried and EVERY message(s) you received. Also, I would repeat Tom Marchant question: Why are you trying to do this? Perhaps there is an alternative. Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ________________________________ Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. ________________________________ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
