Re: IDCAMS NODISCONNECT
Tom, you were correct on the EXPORT DISCONNECT/IMPORT CONNECT to the new master (which was a usercat to the current master. I then used RCNVCAT to generate the ALIAS statements. The DEL UCAT NODISCONNECT/DEF UCAT RECONNECT was not applicable for this, but is of value for moving a usercatalog. Just had to follow your good advice and RTFM to drill down. Thanks for responding! David -Original Message- From: Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU> Sent: Mon, Feb 26, 2018 4:27 pm Subject: Re: IDCAMS NODISCONNECT On Mon, 26 Feb 2018 09:06:48 -0600, Tom Marchant wrote: >On Mon, 26 Feb 2018 08:41:18 -0600, David Purdy wrote: > >>After I created a new master, another sysprog successfully moved a UCAT to a >>different and larger volume. My goal is to correct my new master catalog >>without affecting the heavily used production UCAT and defined ALIAS. > >I would do EXPORT DISCONNECT from the new master, followed by IMPORT CONNECT. Or just IMPORT CONNECT ALIAS to preserve the alias information in the new master catalog. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS NODISCONNECT
On Mon, 26 Feb 2018 09:06:48 -0600, Tom Marchant wrote: >On Mon, 26 Feb 2018 08:41:18 -0600, David Purdy wrote: > >>After I created a new master, another sysprog successfully moved a UCAT to a >>different and larger volume. My goal is to correct my new master catalog >>without affecting the heavily used production UCAT and defined ALIAS. > >I would do EXPORT DISCONNECT from the new master, followed by IMPORT CONNECT. Or just IMPORT CONNECT ALIAS to preserve the alias information in the new master catalog. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS NODISCONNECT
On Mon, 26 Feb 2018 08:41:18 -0600, David Purdy wrote: >After I created a new master, another sysprog successfully moved a UCAT to a >different and larger volume. My goal is to correct my new master catalog >without affecting the heavily used production UCAT and defined ALIAS. I would do EXPORT DISCONNECT from the new master, followed by IMPORT CONNECT. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IDCAMS NODISCONNECT
I'm trying to understand IDCAMS NODISCONNECT to correct a UCAT entry in a new master catalog. After I created a new master, another sysprog successfully moved a UCAT to a different and larger volume. My goal is to correct my new master catalog without affecting the heavily used production UCAT and defined ALIAS. BTW the new master catalog is defined as a UCAT to the existing master catalog for z/OS HLQ ALIAS. Both DFSMS Technical Update and A Practical Guide to ICF Catalogs have the same example: DELETE UCAT.RLSTST USERCATALOG RECOVERY NODISCONNECT and DEFINE USERCATALOG - (NAME(UCAT.RLSTST ) ICFCATALOG - VOLUME(MHL1A0) TRK(5 1) - STORCLAS(SCRLS) - DATACLAS(WELCHRLS) - LOG(NONE) RECONNECT - FREESPACE(0 0) - NOIMBED NOREPLICATE) - DATA (CISZ(4096)) /* Anyone have experience with this process? Are all the DEFINE UCAT parameters required, besides VOLUME and RECONNECT? Another solution come to mind: rebuild the new master catalog with the proper UCAT volume entry. As part of that, I'm using RCNVTCAT. Thanks. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
