Re: DFHSM BCDS Z/OS 1.13
r.skoru...@bremultibank.com.pl (R.S.) wrote: Side question: How can I switch On/Off CA reclaim? Is it some DC parameter or IDCAMS DEF CL one? At the data set level, you can use RECLAIMCA and NORECLAIMCA on ALTER and DEFINE. At the system level, you can use CA_RECLAIM in IGGCATxx to turn it off at the system level(NONE) or put it under control of what's specified in the data class (DATACLAS). -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com r.skoru...@bremultibank.com.pl (R.S.) wrote: W dniu 2014-12-11 o 21:53, John Eells pisze: mark.jac...@custserv.com (Mark Jacobs) wrote: There might be some slight performance impact, and also check for any missing maintenance. That being said, we've had it turned on since zOS 1.12 and it's never caused a problem. snip I am not a VSAM expert, and I didn't stay in a hotel of any description last night, but... - For the overwhelming majority of things I'm told we expect CA reclaim to improve performance (and keep a lid on space utilization too), sometimes significantly. - There is a rather pathological case for which you should not enable CA reclaim, which as far as I know we have only ever seen for real within IBM. If you insert enough records into a specific keyrange to split a CA (maybe more than once), and then delete them all, and then add records back into that same keyrange, rinse, and then repeat a few times, the overhead of repetitive CA reclaim/split processing won't exactly help performance. If it develops that you actually do have a data set that's processed that way, turn it off for that data set. Side question: How can I switch On/Off CA reclaim? Is it some DC parameter or IDCAMS DEF CL one? -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM BCDS Z/OS 1.13
1) master enablement in IGDSMS00 (CA_RECLAIM(DATACLAS)) 2) Application to individual dataclas via the dataclas definition (CA-RECLAIM=YES) And then recreate the dataset,,, snip Side question: How can I switch On/Off CA reclaim? Is it some DC parameter or IDCAMS DEF CL one? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM BCDS Z/OS 1.13
allan.stal...@kbmg.com (Staller, Allan) wrote: 1) master enablement in IGDSMS00 (CA_RECLAIM(DATACLAS)) 2) Application to individual dataclas via the dataclas definition (CA-RECLAIM=YES) And then recreate the dataset,,, No need to recreate the data set. Just use: ALTER entryname RECLAIMCA|NORECLAIMCA ...to change it. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM BCDS Z/OS 1.13
Thanks for the update I was not aware of that. snip And then recreate the dataset,,, No need to recreate the data set. Just use: ALTER entryname RECLAIMCA|NORECLAIMCA ...to change it. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM BCDS Z/OS 1.13
It is not mentioned in SYS1.HELP(ALTER) on my z/OS 1.13 system Is it in z/OS 2.1?? Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Friday, December 12, 2014 9:33 AM Thanks for the update I was not aware of that. snip And then recreate the dataset,,, No need to recreate the data set. Just use: ALTER entryname RECLAIMCA|NORECLAIMCA ...to change it. -- John Eells -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM BCDS Z/OS 1.13
Just looked on our 2.1 system, not there either. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Friday, December 12, 2014 3:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM BCDS Z/OS 1.13 It is not mentioned in SYS1.HELP(ALTER) on my z/OS 1.13 system Is it in z/OS 2.1?? Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Friday, December 12, 2014 9:33 AM Thanks for the update I was not aware of that. snip And then recreate the dataset,,, No need to recreate the data set. Just use: ALTER entryname RECLAIMCA|NORECLAIMCA ...to change it. -- John Eells -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM BCDS Z/OS 1.13
It is in the v2.1 dfsms using datasets manual. Sc23_6855 It does not surprise me it is not in tso help. IBM sometimes forgets to update that information. The alter command uses RECLAIMCA or NORECLAIMCA Lizette -Original Message- From: Farley, Peter x23353 peter.far...@broadridge.com Sent: Dec 12, 2014 1:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM BCDS Z/OS 1.13 Just looked on our 2.1 system, not there either. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Friday, December 12, 2014 3:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM BCDS Z/OS 1.13 It is not mentioned in SYS1.HELP(ALTER) on my z/OS 1.13 system Is it in z/OS 2.1?? Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Friday, December 12, 2014 9:33 AM Thanks for the update I was not aware of that. snip And then recreate the dataset,,, No need to recreate the data set. Just use: ALTER entryname RECLAIMCA|NORECLAIMCA ...to change it. -- John Eells -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: DFHSM BCDS Z/OS 1.13
Hi, I agree that it just sounds like your CDSes have just grown and need more space. Please note that the CA Reclaim function became available in V1R12. When CA Reclaim is enabled for the CDSes, it minimizes the need to reorganize the CDSes, especially after running EXPIREBV. When a VSAM Control Area becomes empty, CA Reclaim will automatically free up that space, which is a primary need to run a reorg. Glenn Wilcock HSM Architect -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM BCDS Z/OS 1.13
Thanks, last night, I ran my BCDS up close to the limit on a non-SMS Mod-9. I still find the change in behavior correlates well with z/OS 1.13 CA Reclaim is a new feature I had not noticed. Since it is turned off by default, I now need to ask: Is there any reason not to turn it on? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Glenn Wilcock Sent: Thursday, December 11, 2014 8:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM BCDS Z/OS 1.13 Hi, I agree that it just sounds like your CDSes have just grown and need more space. Please note that the CA Reclaim function became available in V1R12. When CA Reclaim is enabled for the CDSes, it minimizes the need to reorganize the CDSes, especially after running EXPIREBV. When a VSAM Control Area becomes empty, CA Reclaim will automatically free up that space, which is a primary need to run a reorg. Glenn Wilcock HSM Architect -- 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: DFHSM BCDS Z/OS 1.13
Yes. For the exact problem you are currently encountering! snip CA Reclaim is a new feature I had not noticed. Since it is turned off by default, I now need to ask: Is there any reason not to turn it on? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM BCDS Z/OS 1.13
I asked for reasons to NOT turn it on. As to my specific problem, there is a caveat in the documentation than indicates it isn't an immediate solution. CA's that are empty when CA Reclaim is enabled are not reclaimed. So, I would have needed to delete/reallocate my xCDS(s) anyway. The same would apply to the user catalog I have with SMTP as HLQ. It is subject to growing because of the constantly increasing names. It has already run up to 123 existing extents. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Thursday, December 11, 2014 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM BCDS Z/OS 1.13 Yes. For the exact problem you are currently encountering! snip CA Reclaim is a new feature I had not noticed. Since it is turned off by default, I now need to ask: Is there any reason not to turn it on? /snip -- 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: DFHSM BCDS Z/OS 1.13
There might be some slight performance impact, and also check for any missing maintenance. That being said, we've had it turned on since zOS 1.12 and it's never caused a problem. Mark Jacobs Gibney, Dave wrote: I asked for reasons to NOT turn it on. As to my specific problem, there is a caveat in the documentation than indicates it isn't an immediate solution. CA's that are empty when CA Reclaim is enabled are not reclaimed. So, I would have needed to delete/reallocate my xCDS(s) anyway. The same would apply to the user catalog I have with SMTP as HLQ. It is subject to growing because of the constantly increasing names. It has already run up to 123 existing extents. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Thursday, December 11, 2014 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM BCDS Z/OS 1.13 Yes. For the exact problem you are currently encountering! snip CA Reclaim is a new feature I had not noticed. Since it is turned off by default, I now need to ask: Is there any reason not to turn it on? /snip -- 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
Re: DFHSM BCDS Z/OS 1.13
mark.jac...@custserv.com (Mark Jacobs) wrote: There might be some slight performance impact, and also check for any missing maintenance. That being said, we've had it turned on since zOS 1.12 and it's never caused a problem. snip I am not a VSAM expert, and I didn't stay in a hotel of any description last night, but... - For the overwhelming majority of things I'm told we expect CA reclaim to improve performance (and keep a lid on space utilization too), sometimes significantly. - There is a rather pathological case for which you should not enable CA reclaim, which as far as I know we have only ever seen for real within IBM. If you insert enough records into a specific keyrange to split a CA (maybe more than once), and then delete them all, and then add records back into that same keyrange, rinse, and then repeat a few times, the overhead of repetitive CA reclaim/split processing won't exactly help performance. If it develops that you actually do have a data set that's processed that way, turn it off for that data set. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM BCDS Z/OS 1.13
I can think of no reason not to turn it on. I have had it turned it for *all* VSAM processing (including user catalogs) since early 2012 w/no reported issues. I would turn it on prior to rebuilding the CDS's/UCATS and then proceed with whatever is necessary. HTH, snip I asked for reasons to NOT turn it on. As to my specific problem, there is a caveat in the documentation than indicates it isn't an immediate solution. CA's that are empty when CA Reclaim is enabled are not reclaimed. So, I would have needed to delete/reallocate my xCDS(s) anyway. The same would apply to the user catalog I have with SMTP as HLQ. It is subject to growing because of the constantly increasing names. It has already run up to 123 existing extents. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM BCDS Z/OS 1.13
CA_RECLAIM() parm on IGDSMSxx check this out: https://www.google.com.br/url?sa=trct=jq=esrc=ssource=webcd=1cad=rjauact=8ved=0CB8QFjAAurl=https%3A%2F%2Fshare.confex.com%2Fshare%2F115%2Fwebprogram%2FHandout%2FSession8054%2FSHARE_8054%2520VSAM%2520CA%2520Reclaim%2520Boston.pdfei=uhyKVPKsEafGsQSu8IBIusg=AFQjCNGAs7K4w6JVW3P-EXRq85sDWTmfRgsig2=yj75EznD1MmEkm90U9oC2gbvm=bv.81828268,d.cWc --- *Lucas Rosalen* rosalen.lu...@gmail.com / *lrosa...@br.ibm.com lrosa...@br.ibm.com* +55 19 9-8146-7633 2014-12-11 19:59 GMT-02:00 R.S. r.skoru...@bremultibank.com.pl: W dniu 2014-12-11 o 21:53, John Eells pisze: mark.jac...@custserv.com (Mark Jacobs) wrote: There might be some slight performance impact, and also check for any missing maintenance. That being said, we've had it turned on since zOS 1.12 and it's never caused a problem. snip I am not a VSAM expert, and I didn't stay in a hotel of any description last night, but... - For the overwhelming majority of things I'm told we expect CA reclaim to improve performance (and keep a lid on space utilization too), sometimes significantly. - There is a rather pathological case for which you should not enable CA reclaim, which as far as I know we have only ever seen for real within IBM. If you insert enough records into a specific keyrange to split a CA (maybe more than once), and then delete them all, and then add records back into that same keyrange, rinse, and then repeat a few times, the overhead of repetitive CA reclaim/split processing won't exactly help performance. If it develops that you actually do have a data set that's processed that way, turn it off for that data set. Side question: How can I switch On/Off CA reclaim? Is it some DC parameter or IDCAMS DEF CL one? -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- 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: DFHSM BCDS Z/OS 1.13
How much data actually expires when you run EXPIREBV? AFAIK, the is no change to dfHSM that would account for this behavior. It sounds like the dataset is just getting full and needs to be expanded. Remember the 4gb limit for non-SMS VSAM. snip Since moving to z/OS 1.13, my DFHSM BCDS seems to be issuing the ARC0909E BCDS CONTROL DATA SET IS ABOUT 091% FULL Message with greater frequency. I have automation in place to reorg it when the message occurs, but it used to trigger about once a year and now seems to trigger almost monthly. I run three consecutive EXPIREBV commands weekly. My BCDS is currently using an entire Mod-3 non-SMS disk. I don't like to put HSM xCDS in SMS pools. Ancient burns. I do have bigger volumes, and will likely move it. But, will still want to avoid the need for any SMS Extended stuff for now. I was wondering if there is a known change to DFHSM that would explain this change of behavior? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM BCDS Z/OS 1.13
21,776 Dataset last Sunday? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Wednesday, December 10, 2014 12:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM BCDS Z/OS 1.13 How much data actually expires when you run EXPIREBV? AFAIK, the is no change to dfHSM that would account for this behavior. It sounds like the dataset is just getting full and needs to be expanded. Remember the 4gb limit for non-SMS VSAM. snip Since moving to z/OS 1.13, my DFHSM BCDS seems to be issuing the ARC0909E BCDS CONTROL DATA SET IS ABOUT 091% FULL Message with greater frequency. I have automation in place to reorg it when the message occurs, but it used to trigger about once a year and now seems to trigger almost monthly. I run three consecutive EXPIREBV commands weekly. My BCDS is currently using an entire Mod-3 non-SMS disk. I don't like to put HSM xCDS in SMS pools. Ancient burns. I do have bigger volumes, and will likely move it. But, will still want to avoid the need for any SMS Extended stuff for now. I was wondering if there is a known change to DFHSM that would explain this change of behavior? /snip -- 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
