Re: SMS and System Temporary Datasets
We managed them first just like to manual recommends. Routed most small ones to vio. Dave Gibney Information Technology Services Washington State Univsersity -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Greg Shirey Sent: Wednesday, January 21, 2009 11:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS and System Temporary Datasets From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman Sent: Wednesday, January 21, 2009 11:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS and System Temporary Datasets >> >> Am I on the right track? Do most of y'all make System Temporary dsns >>SMS-managed? >> >> >--- --- >We left them unmanaged and let them go to our few PUBLIC volumes >ick We did this as well for a long time until we realized that temporary data sets could also take advantage of the SMS space constraint settings. Then we couldn't think of a reason not to do it. Greg Shirey Ben E. Keith Co. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman Sent: Wednesday, January 21, 2009 11:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS and System Temporary Datasets >> >> Am I on the right track? Do most of y'all make System Temporary dsns >>SMS-managed? >> >> >--- --- >We left them unmanaged and let them go to our few PUBLIC volumes >ick We did this as well for a long time until we realized that temporary data sets could also take advantage of the SMS space constraint settings. Then we couldn't think of a reason not to do it. Greg Shirey Ben E. Keith Co. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
-- Hi Folks, I've got a product (CA-Allocate) that allows dynamic increasing of the allocation of System Temporary datasets. This current state. As I move to SMS, I see that only a STORCLAS is assigned for these. If I understand correctly, this means that the space coded in the JCL is what you get. My options seem to be: 1) plow thru all System Temporary allocations being increased by CA-Allocate and update the JCL, or 2) Leave System Temporary datasets non-SMS. Am I on the right track? Do most of y'all make System Temporary dsns SMS-managed? -- We left them unmanaged and let them go to our few PUBLIC volumes -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
On Wed, 21 Jan 2009 06:35:09 -0600, Spencer, Mike wrote: >Bob, >Using Dynamic Volume Count in the DFSMS Dataclas is terribly >inefficient. The Dynamic Volume Count is used to determine the size of >the TIOT, TCTTIOT, and JFCB control blocks when allocating a data set. >What this means is that with a DVC of 58, every data set using this data >class is using 2052 bytes of unused storage (57 x 36 bytes) regardless >of the actual number of logical volumes used. This may not be an issue >depending on your processor hardware, but it does add up as this storage >is never released until the data set is deleted from the system. The >StopX37 product does not use allocate storage in the same fashion as >DFSMS, so the process is more efficient from a storage standpoint. >If cost is an issue, I would consider looking at other ISV options. > > It's still much better than "the old way" (volume count) that stored the number of entries in the catalog! :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
Bob, Using Dynamic Volume Count in the DFSMS Dataclas is terribly inefficient. The Dynamic Volume Count is used to determine the size of the TIOT, TCTTIOT, and JFCB control blocks when allocating a data set. What this means is that with a DVC of 58, every data set using this data class is using 2052 bytes of unused storage (57 x 36 bytes) regardless of the actual number of logical volumes used. This may not be an issue depending on your processor hardware, but it does add up as this storage is never released until the data set is deleted from the system. The StopX37 product does not use allocate storage in the same fashion as DFSMS, so the process is more efficient from a storage standpoint. If cost is an issue, I would consider looking at other ISV options. Michael Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lester, Bob Sent: Tuesday, January 20, 2009 6:10 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS and System Temporary Datasets > -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave > Sent: Tuesday, January 20, 2009 2:41 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: SMS and System Temporary Datasets > > > Are you assuming SMS will manage the 'extent problem', and > you can get > rid of the product? You can't. > > Maybe not totally, but space constraint relief, extended format and > multi-volume can go a long way. > Hi Dave, This is exactly what I intend. We use Extended as default in (most of) our data classes with an initial volume count of 1 and a dynamic volume count of up to 58. Thanks! BobL -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
Bob, IMO going back and updating JCL seems like a lot of work. As Ted says, the ISV products are designed to work with SMS and non-SMS data sets. These X37 and allocation ISV products were around long before DFSMS and are pretty good at what they do. As I stated already, many of the recovery actions that these products perform are actually more efficient than DFSMS. What happens in the future after you have removed VAM when the application grows and your JCL changes are no longer adequate enough; BAM! JCL, X37 abend. This condition would be true for other permanent data sets as well. I've been using the StopX37/EasyPOOL product since I got into IT back in 1989 and could not do without it (I installed DFSMS in 1991). I let DFSMS do it's thing where appropriate, and StopX37/II where appropriate. Plus StopX37/II does work that DFSMS does not perform. Michael Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lester, Bob Sent: Tuesday, January 20, 2009 5:22 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS and System Temporary Datasets Hi Ted, I do have other SMS-managed data. I'm just doing the conversion a bit backwards. ;-) I can see that the issue, in my current environment, is that I tell VAM (CA-Allocate) to bail out of it's ASR (EXIT CODE(0)) if it sees a non-null Storage Class. We are hoping to be able to eliminate VAM from the mix. My intent with the "extent problem" is to identify which dsns are being twiddled by VAM and (for System Temporary dsns) update the space allocation in the JCL. For permanent dsns being change by VAM, I can either change the JCL to specify data class, or let SMS just add additional volumes. Thanks for the reply! Sounds like SMS-managed System Temporary files is a good thing. BobL > -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL > Sent: Tuesday, January 20, 2009 2:15 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: SMS and System Temporary Datasets > > >My options seem to be: > >1) plow thru all System Temporary allocations being increased by > >CA-Allocate and update the JCL, or > >2) Leave System Temporary datasets non-SMS. > > At the risk of repeating myself, what makes you think these are > mutually exclusive? > Are you assuming that you can't do both in an SMS environment? You > can. > Are you assuming SMS will manage the 'extent problem', and you can get > rid of the product? You can't. > > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the > message: GET IBM-MAIN INFO Search the archives at > http://bama.ua.edu/archives/ibm-main.html > > -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave > Sent: Tuesday, January 20, 2009 2:41 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: SMS and System Temporary Datasets > > > Are you assuming SMS will manage the 'extent problem', and > you can get > rid of the product? You can't. > > Maybe not totally, but space constraint relief, extended > format and multi-volume can go a long way. > Hi Dave, This is exactly what I intend. We use Extended as default in (most of) our data classes with an initial volume count of 1 and a dynamic volume count of up to 58. Thanks! BobL -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
> I can see that the issue, in my current environment, is that I tell VAM > (CA-Allocate) to bail out of it's ASR (EXIT CODE(0)) if it sees a non-null Storage Class. Why? Use it! VAM/BrightStore/SAMS-Allocate works with SMS and non-SMS data. >We are hoping to be able to eliminate VAM from the mix. Is this a cost issue? SMS will not solve the problem, by itself. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
Hi Ted, I do have other SMS-managed data. I'm just doing the conversion a bit backwards. ;-) I can see that the issue, in my current environment, is that I tell VAM (CA-Allocate) to bail out of it's ASR (EXIT CODE(0)) if it sees a non-null Storage Class. We are hoping to be able to eliminate VAM from the mix. My intent with the "extent problem" is to identify which dsns are being twiddled by VAM and (for System Temporary dsns) update the space allocation in the JCL. For permanent dsns being change by VAM, I can either change the JCL to specify data class, or let SMS just add additional volumes. Thanks for the reply! Sounds like SMS-managed System Temporary files is a good thing. BobL > -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL > Sent: Tuesday, January 20, 2009 2:15 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: SMS and System Temporary Datasets > > >My options seem to be: > >1) plow thru all System Temporary allocations being increased by > >CA-Allocate and update the JCL, or > >2) Leave System Temporary datasets non-SMS. > > At the risk of repeating myself, what makes you think these > are mutually exclusive? > Are you assuming that you can't do both in an SMS > environment? You can. > Are you assuming SMS will manage the 'extent problem', and > you can get rid of the product? You can't. > > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access > instructions, send email to lists...@bama.ua.edu with the > message: GET IBM-MAIN INFO Search the archives at > http://bama.ua.edu/archives/ibm-main.html > > -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
>> Are you assuming SMS will manage the 'extent problem', and you can get rid >> of the product? You can't. >Maybe not totally, but space constraint relief, extended format and >multi-volume can go a long way. Yes! But! The OP appeared to assume that: 1. You can't use CA-Allocate with SMS. 2. SMS will replace the functionality. >We never had any ISV product for this and x37 abends did occur. Not frequently >and we've always been small. That said, there hasn't been a x37 abend since >SMS came in that wasn't the result of a grossly low SPACE parameter. Yes! But! That's what these products are for. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
> Are you assuming SMS will manage the 'extent problem', and you can get rid of the product? You can't. Maybe not totally, but space constraint relief, extended format and multi-volume can go a long way. We never had any ISV product for this and x37 abends did occur. Not frequently and we've always been small. That said, there hasn't been a x37 abend since SMS came in that wasn't the result of a grossly low SPACE parameter. Dave Gibney Information Technology Services Washington State Univsersity -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Tuesday, January 20, 2009 1:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS and System Temporary Datasets >My options seem to be: >1) plow thru all System Temporary allocations being increased by CA-Allocate and update the JCL, or >2) Leave System Temporary datasets non-SMS. At the risk of repeating myself, what makes you think these are mutually exclusive? Are you assuming that you can't do both in an SMS environment? You can. Are you assuming SMS will manage the 'extent problem', and you can get rid of the product? You can't. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
>My options seem to be: >1) plow thru all System Temporary allocations being increased by CA-Allocate >and update the JCL, or >2) Leave System Temporary datasets non-SMS. At the risk of repeating myself, what makes you think these are mutually exclusive? Are you assuming that you can't do both in an SMS environment? You can. Are you assuming SMS will manage the 'extent problem', and you can get rid of the product? You can't. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
Bob, > >I've got a product (CA-Allocate) that allows dynamic increasing of > the allocation of System Temporary datasets. This current state. > >As I move to SMS, I see that only a STORCLAS is assigned for these. > If I understand correctly, this means that the space coded in the JCL is > what you get. > CA-Allocate can override the space amounts in alloc environment, no difference. Same applies to secondary space increase/reduction in extend environment. You would want to exclude sortwork datasets since *sort does its own thing. >My options seem to be: 1) plow thru all System Temporary allocations > being increased by CA-Allocate and update the JCL, or 2) Leave System > Temporary datasets non-SMS. > >Am I on the right track? Do most of y'all make System Temporary dsns > SMS-managed? > Temporary datasets were the first datasets I put under sms in the early 90's. Regards, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
>In every instance I've configured DFSMS, DFSMS has always managed System Temporary Data Sets. 1. This is a good thing. >ISV products that provide dynamic enhancements to the DFSMS structure >(CA-Alloc and MAINVIEW SRM Allocation/StopX37/II are two such products) 2. These products are independent of SMS. They will work with non-SMS data, as well. 3. As I've said, why restrict them to temporary datasets. The last shop I worked at had them for temp, perm, prod & test. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
In every instance I've configured DFSMS, DFSMS has always managed System Temporary Data Sets. ISV products that provide dynamic enhancements to the DFSMS structure (CA-Alloc and MAINVIEW SRM Allocation/StopX37/II are two such products) will continue to dynamically increase these and any other type of data set. The space coded in the JCL is always going to take precedence during initial allocation; unless your ISV product is coded to alter the primary and secondary amounts during allocation, but the ISV code can continue to add volumes, extend the data set if needed, reduce the secondary if needed, or whatever is required based on your install setups. In some cases the ISV product is more efficient in its methods of recovery than DFSMS. Michael Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lester, Bob Sent: Tuesday, January 20, 2009 3:35 PM To: IBM-MAIN@bama.ua.edu Subject: SMS and System Temporary Datasets Hi Folks, I've got a product (CA-Allocate) that allows dynamic increasing of the allocation of System Temporary datasets. This current state. As I move to SMS, I see that only a STORCLAS is assigned for these. If I understand correctly, this means that the space coded in the JCL is what you get. My options seem to be: 1) plow thru all System Temporary allocations being increased by CA-Allocate and update the JCL, or 2) Leave System Temporary datasets non-SMS. Am I on the right track? Do most of y'all make System Temporary dsns SMS-managed? Thanks! BobL -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS and System Temporary Datasets
>I've got a product (CA-Allocate) that allows dynamic increasing of the >allocation of System Temporary datasets. This current state. >As I move to SMS, I see that only a STORCLAS is assigned for these. If I >understand correctly, this means that the space coded in the JCL is what you >get. I haven't used it since it was called BrightStor, but it (and STOPx37), would still manage the extent processing, SMS managed or not. SMS will not do it for you. You still need the product. PS: Why are you using it for only temporary datasets? It works for permanent, as well. And, in some production environments, it's a life-saver! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMS and System Temporary Datasets
Hi Folks, I've got a product (CA-Allocate) that allows dynamic increasing of the allocation of System Temporary datasets. This current state. As I move to SMS, I see that only a STORCLAS is assigned for these. If I understand correctly, this means that the space coded in the JCL is what you get. My options seem to be: 1) plow thru all System Temporary allocations being increased by CA-Allocate and update the JCL, or 2) Leave System Temporary datasets non-SMS. Am I on the right track? Do most of y'all make System Temporary dsns SMS-managed? Thanks! BobL -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
