Classification: Confidential Depending on the current size if the CDS's I recommends converting to SMS Mgmt of the CDSs. If they are anywhere close to the 5200 cyl size, it will save a lot of effort (perhaps when things are broken). If they are tiny (FSVO tiny). Then don’t bother
Pay me now or pay me later, HTH -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Michael Watkins Sent: Tuesday, February 22, 2022 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Resizing MCDS [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Yes, all DFSMShsm ASIDs in the HSMplex must be down. (All DFSMShsm ASIDs that share control datasets and a journal are in the same HSMplex.) I would rename the existing MCDS by appending the current date [either '.#22feb22' or '.#22053' (Julian date) for today, for example] to the index and data component names as well as to the cluster name. By including the date last used in the new dataset name, there will be less question of what the cluster is when you don't delete it and someone else is looking at it next year and wondering if they can reclaim the space. First, I would then define the new (presumably larger) MCDS with the old name by using the MODEL parameter and changing only the CYLS for both the data and index components to (x 0). By using the same MCDS name, no JCL will have to be changed. No secondary should be allocated to any of the DFSMShsm control datasets when they are shared by DFSMShsm ASIDs on different LPARs, unless the DFSMShsm CDSs are managed with RLS (Record Level Sharing). Second, REPRO the old '.#yyddd' MCDS into the new MCDS. Third, restart DFSMShsm on all LPARs, one at a time. Done. Let's assume your MCDS's characteristics are: KEYLEN: 44 AVGLRECL: 435 BUFSPACE: 530432 CISIZE: 12288 RKP: 0 MAXLRECL: 2040 EXCPEXIT: (NULL) CI/CA: 60 SHROPTNS(3,3) SPEED UNIQUE NOERASE INDEXED NOWRITECHK UNORDERED NOREUSE NONSPANNED If your MCDS is not SMS-managed, then I would suggest allocating the maximum CYLS(5825 0) for the MCDS data component, which will allow the MCDS to reach as close to the VSAM 4 GB limit as possible while still allocating in CYLS instead of TRKS. Something close to 'CYLS(30 0)' should be sufficient for the MCDS index component. I would also suggest devoting an entire MOD-9 to the MCDS to avoid contention for the volume. -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Allan Staller Sent: Tuesday, February 22, 2022 7:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Resizing MCDS CAUTION: This email originated from outside of the Texas Comptroller's email system. DO NOT click links or open attachments unless you expect them from the sender and know the content is safe. Classification: Confidential Essentially yes. HSM must be down for the duration. I would also rename the original to .old and the new to the original name. A lot of JCL would need to be changed otherwise. Of course take backups. HTH, -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Peter Sent: Tuesday, February 22, 2022 3:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Resizing MCDS [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Hello Apologize for basic question Whats your approach on resizing HSM MCDS ? is it just defining MCDS, Rename, repro old to new and start HSM task ? Peter ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
