Re: Resizing MCDS
Great discussion here. For those who are interested, here is a link to charts/recordings for a DFSMShsm education series. One of the sessions is specifically on the DFSMShsm control data sets that discusses RLS, CA Reclaim, Reorgs, etc. Feel free to contact me with any questions. https://ibm.ent.box.com/v/DFSMS-Academ-DFSMShsm2021 Glenn Wilcock DFSMS Chief Product Owner -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resizing MCDS
I also try to keep it simple and these are the steps I perform for re-sizing the HSM cluster. Beside the shutdown and start up commands, all else is within a single batch job. 1) Shut down HSM. 2) Run a listcat of the HSM cluster. 3) Back up the HSM cluster to tape. 4) Export the file via IDCAMS to a PS file. 5) Delete the KSDS. 6) Redefine the KSDS with more space as needed, it move it to another volume - whatever needs to be done. 7) Import the IDCAMS export back into the new HSM cluster. 8) Run a listcat to make sure the record count looks right. 9) Start up HSM and test a file recall and a file migrate process. That will usually take care of it and it all can be done within 5 minutes or less. Hope that helps somewhat as it works fine for our shop. Claude -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resizing MCDS
Classification: Confidential In additon, if you haven't already, implement ca-reclaim for the HSD CDS's. I would do it everywhere for all ksds'S -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Watkins Sent: Tuesday, February 22, 2022 11:07 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.] I heartily agree that SMS-management and RLS is the preferred way to define all DFSMShsm CDSs. I made the rash assumption that Peter simply need to resize the MCDS in the near future instead of making a project out of it by defining the required coupling facility structures and making the DFSMShsm CDSs SMS-managed. Can the MCDS exceed the 4 GB limit without SMS-management? From the following discussion, it appears it can be: See: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.zmainframes.com%2Fviewtopic.php%3Ft%3D2009data=04%7C01%7Callan.staller%40HCL.COM%7C7302361e8afe422606f708d9f625d146%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637811465305104587%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2FjDJV33U5jV5FNM5DuM%2BYJ%2F5fHGGn2hFVMrxrORBXlE%3Dreserved=0 'Over coming the 4 GB limit of VSAM.', Mon Feb 22, 2016 6:29 pm, Robert Sample: If you read the manual on DEFINE CLUSTER, you will discover that the manual EXPLICITLY states that DATACLASS can be used for SMS or non-SMS managed storage. Yes, it is part of SMS but it can also be used outside SMS. Sat Feb 27, 2016 6:00 pm, Angel: I have suggested to use the Extended Format (VSAM EF) files. As I read about them, they allow to add an extra 32 control bytes to each data block. But they need to be DFSMS managed. It seems to solve the problem. So even if a DATACLASS is also given the restriction of 4GB anyways remains, right? Sat Feb 27, 2016 7:42 pm, Robert Sample: This is another reason you REALLY need to talk to your site support group. If the DATACLASS given does not support VSAM extended format (a DATACLASS can be used for different reasons), then yes the 4 GB limit still applies. Only someone working at your site can provide you with the site-specific information you need on how to get your VSAM data set to go past 4 GB; we can only say that yes it can be done. Wed May 04, 2016 4:42 pm, Angel: We ended up using 4 GB limit, as going beyond that was not recommended by the policies. Thu May 05, 2016 1:22 am, Robert Sample: Policies often wind up being in effect long after they should have been changed. I've used a number of VSAM linear and KSDS data sets as large as 60 GB with no problems; a policy against them makes less and less sense as time passes. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Nigel Morton Sent: Tuesday, February 22, 2022 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Resizing MCDS 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 < 032966e74d0f-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, After renaming the MCDS, 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 I
Re: Resizing MCDS
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 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 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 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
Re: Resizing MCDS
I heartily agree that SMS-management and RLS is the preferred way to define all DFSMShsm CDSs. I made the rash assumption that Peter simply need to resize the MCDS in the near future instead of making a project out of it by defining the required coupling facility structures and making the DFSMShsm CDSs SMS-managed. Can the MCDS exceed the 4 GB limit without SMS-management? From the following discussion, it appears it can be: See: https://www.zmainframes.com/viewtopic.php?t=2009 'Over coming the 4 GB limit of VSAM.', Mon Feb 22, 2016 6:29 pm, Robert Sample: If you read the manual on DEFINE CLUSTER, you will discover that the manual EXPLICITLY states that DATACLASS can be used for SMS or non-SMS managed storage. Yes, it is part of SMS but it can also be used outside SMS. Sat Feb 27, 2016 6:00 pm, Angel: I have suggested to use the Extended Format (VSAM EF) files. As I read about them, they allow to add an extra 32 control bytes to each data block. But they need to be DFSMS managed. It seems to solve the problem. So even if a DATACLASS is also given the restriction of 4GB anyways remains, right? Sat Feb 27, 2016 7:42 pm, Robert Sample: This is another reason you REALLY need to talk to your site support group. If the DATACLASS given does not support VSAM extended format (a DATACLASS can be used for different reasons), then yes the 4 GB limit still applies. Only someone working at your site can provide you with the site-specific information you need on how to get your VSAM data set to go past 4 GB; we can only say that yes it can be done. Wed May 04, 2016 4:42 pm, Angel: We ended up using 4 GB limit, as going beyond that was not recommended by the policies. Thu May 05, 2016 1:22 am, Robert Sample: Policies often wind up being in effect long after they should have been changed. I've used a number of VSAM linear and KSDS data sets as large as 60 GB with no problems; a policy against them makes less and less sense as time passes. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Nigel Morton Sent: Tuesday, February 22, 2022 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Resizing MCDS 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 < 032966e74d0f-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, After renaming the MCDS, 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 On > Behalf Of Allan Staller > Sent: Tuesday, February 22, 2022 7:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Resizing MCDS > 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, > >
Re: Resizing MCDS
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 < 032966e74d0f-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 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 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 mess
Re: Resizing MCDS
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 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 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
Re: Resizing MCDS
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 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
Re: Resizing MCDS
Peter, hsm also includes tools to analyze and split an MCDS as well. You have to decide how many. In our case, I have three, and I use your method to do reorgs plus try to repro evenly across all three. David -Original Message- From: Gadi Ben-Avi To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tue, Feb 22, 2022 5:22 am Subject: Re: Resizing MCDS That's what I've been doing. I use sort to copy, and do the rename after the copy, but it general it's the same process. Gadi -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Tuesday, February 22, 2022 11:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Resizing MCDS 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 Email secured by Check Point -- 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: Resizing MCDS
Hello Peter, Your approch to the matter applies to resizing any VSAM KSDS data set. Just make it simple, do not over think. Your method is probably the best even though it has been used for ages. I wish there was some new method to do the same as with this method you must shut down HSM. Dejan Stamatovic CROZ DOO -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resizing MCDS
That's what I've been doing. I use sort to copy, and do the rename after the copy, but it general it's the same process. Gadi -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Tuesday, February 22, 2022 11:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Resizing MCDS 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 Email secured by Check Point -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Resizing MCDS
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
