I would suggest using extended addressability VSAM to avoid the 4GB limit as well as considering multi-cluster CDSs (for MCDS and BCDS, don't think it is supported for the OCDS). I'd also recommend using RLS as I've seen it speed up long-running HSM functions significantly.
Both extended addressability and RLS for HSM CDSs have been around for several years. On Tue, 22 Feb 2022 at 15:50, Michael Watkins < 0000032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote: > 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
