Re: using SMS compression - how to manage
How is a FILTLIST substantially different/harder to maintain than a list of dataset names and patterns? I don't remember DVC being part of MAXSIZE when I did this. I also found that setting DVC to a more reasonable number like 4 or 8 works just as well as 59 without the serious impacts 59 can have elsewhere. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Wednesday, April 27, 2011 11:14 AM To: IBM-MAIN@bama.ua.edu Subject: using SMS compression - how to manage We are replacing BMC's Data Accelerator compression with SMS compression. I have a DATACLAS (named DCEXTC) created which implements this. The DATACLAS works. At present, Data Accelerator works by having a list of dataset names and patterns which are used to determine if (and how) a dataset is to be compressed. The only way that I have found to duplicate this is by using a FILTLIST (actually a number of them) to list the DSNs and patterns to be assigned the DCEXTC DATACLAS. I consider this to be very clumsy and difficult to maintain. Is there an easier way which does not require that the individual DEFINE desks specify the DCEXTC data class? I cannot depend on the programmers to do this correctly. And they would rise up in arms if I tried, anyway. Also, trying to use the MAXSIZE is likely to be a failure due to the way that our previous storage person set up SMS. Every dataclas has a DVC count of 59. And the storage admin, under pressure from the programming management, just gave the programmers some vague sizing guidelines. Basically, the DVC count is used the way that StopX37 was used in the past. To make sizing datasets unnecessary. After all, they don't need to size their files on Windows or UNIX, so why do they need to on z/OS? Just more proof that z/OS is obsolete. OOPS, I'm whining again. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: using SMS compression - how to manage
Well, I guess it is not more difficult than maintaining the list. Except that there is a limit to the number of entries in a single FILTLIST. To duplicate the current list requires 3 FILTLISTs and a statement like: WHEN (DSN EQ F1 OR DSN EQ F2 OR DSN EQ F3) SET DATACLAS='DCEXTC' If F3 FILTLIST gets to long, I'll need to create F4 and update the WHEN. I just don't like it. I would like something better. If, as you say, DVC does not influence MAXSIZE, then I might end up not assigning DCEXTC when I really should. I would really like to eliminate all compression. But we actually do have one VSAM KSDS which, uncompressed, might get very close to the limit of 59 volumes (of 3390-3 space). We do not have any RDMS on z/OS and won't get one. Management is doing their best to find a justification to eliminate z/OS and convert to a 100% Windows shop (they want to convert all Linux, AIX, and Solaris servers to Windows too.) They won't do __anything__ to make z/OS better, unless is also reduces the cost to run z/OS. Wish I could find a new vocation. Like professional Tiddley-Winkes player (except that I have arthritis) or mattress tester. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Wednesday, April 27, 2011 1:39 PM To: IBM-MAIN@bama.ua.edu Subject: Re: using SMS compression - how to manage How is a FILTLIST substantially different/harder to maintain than a list of dataset names and patterns? I don't remember DVC being part of MAXSIZE when I did this. I also found that setting DVC to a more reasonable number like 4 or 8 works just as well as 59 without the serious impacts 59 can have elsewhere. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Wednesday, April 27, 2011 11:14 AM To: IBM-MAIN@bama.ua.edu Subject: using SMS compression - how to manage We are replacing BMC's Data Accelerator compression with SMS compression. I have a DATACLAS (named DCEXTC) created which implements this. The DATACLAS works. At present, Data Accelerator works by having a list of dataset names and patterns which are used to determine if (and how) a dataset is to be compressed. The only way that I have found to duplicate this is by using a FILTLIST (actually a number of them) to list the DSNs and patterns to be assigned the DCEXTC DATACLAS. I consider this to be very clumsy and difficult to maintain. Is there an easier way which does not require that the individual DEFINE desks specify the DCEXTC data class? I cannot depend on the programmers to do this correctly. And they would rise up in arms if I tried, anyway. Also, trying to use the MAXSIZE is likely to be a failure due to the way that our previous storage person set up SMS. Every dataclas has a DVC count of 59. And the storage admin, under pressure from the programming management, just gave the programmers some vague sizing guidelines. Basically, the DVC count is used the way that StopX37 was used in the past. To make sizing datasets unnecessary. After all, they don't need to size their files on Windows or UNIX, so why do they need to on z/OS? Just more proof that z/OS is obsolete. OOPS, I'm whining again. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Re: using SMS compression - how to manage
Tell them to stop spending zCycles on compression. :) Simplify the FILTLIST to just the one VSAM file. Or, do as I did. Extended, stripped, compressed is the default. With a DATACLAS=NOEXTEND for the few cases that can't handle it. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Wednesday, April 27, 2011 11:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: using SMS compression - how to manage Well, I guess it is not more difficult than maintaining the list. Except that there is a limit to the number of entries in a single FILTLIST. To duplicate the current list requires 3 FILTLISTs and a statement like: WHEN (DSN EQ F1 OR DSN EQ F2 OR DSN EQ F3) SET DATACLAS='DCEXTC' If F3 FILTLIST gets to long, I'll need to create F4 and update the WHEN. I just don't like it. I would like something better. If, as you say, DVC does not influence MAXSIZE, then I might end up not assigning DCEXTC when I really should. I would really like to eliminate all compression. But we actually do have one VSAM KSDS which, uncompressed, might get very close to the limit of 59 volumes (of 3390-3 space). We do not have any RDMS on z/OS and won't get one. Management is doing their best to find a justification to eliminate z/OS and convert to a 100% Windows shop (they want to convert all Linux, AIX, and Solaris servers to Windows too.) They won't do __anything__ to make z/OS better, unless is also reduces the cost to run z/OS. Wish I could find a new vocation. Like professional Tiddley-Winkes player (except that I have arthritis) or mattress tester. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Wednesday, April 27, 2011 1:39 PM To: IBM-MAIN@bama.ua.edu Subject: Re: using SMS compression - how to manage How is a FILTLIST substantially different/harder to maintain than a list of dataset names and patterns? I don't remember DVC being part of MAXSIZE when I did this. I also found that setting DVC to a more reasonable number like 4 or 8 works just as well as 59 without the serious impacts 59 can have elsewhere. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Wednesday, April 27, 2011 11:14 AM To: IBM-MAIN@bama.ua.edu Subject: using SMS compression - how to manage We are replacing BMC's Data Accelerator compression with SMS compression. I have a DATACLAS (named DCEXTC) created which implements this. The DATACLAS works. At present, Data Accelerator works by having a list of dataset names and patterns which are used to determine if (and how) a dataset is to be compressed. The only way that I have found to duplicate this is by using a FILTLIST (actually a number of them) to list the DSNs and patterns to be assigned the DCEXTC DATACLAS. I consider this to be very clumsy and difficult to maintain. Is there an easier way which does not require that the individual DEFINE desks specify the DCEXTC data class? I cannot depend on the programmers to do this correctly. And they would rise up in arms if I tried, anyway. Also, trying to use the MAXSIZE is likely to be a failure due to the way that our previous storage person set up SMS. Every dataclas has a DVC count of 59. And the storage admin, under pressure from the programming management, just gave the programmers some vague sizing guidelines. Basically, the DVC count is used the way that StopX37 was used in the past. To make sizing datasets unnecessary. After all, they don't need to size their files on Windows or UNIX, so why do they need to on z/OS? Just more proof that z/OS is obsolete. OOPS, I'm whining again. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck
Re: using SMS compression - how to manage
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Wednesday, April 27, 2011 1:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: using SMS compression - how to manage Tell them to stop spending zCycles on compression. :) Simplify the FILTLIST to just the one VSAM file. Or, do as I did. Extended, stripped, compressed is the default. With a DATACLAS=NOEXTEND for the few cases that can't handle it. Dave Gibney Extended is the default for all non-ESDS VSAM files. I can't remember what it was, but we had some problem with ESDS files with Extended Addressing (perhaps in CICS). I may try to reduce the number of files in the FILTLIST. I was trying to duplicate the current compression environment, but that is likely overkill. Of course, if a file expands for no reason, people will complain. And the DASD allocation report will show a sudden spike. Which will cause weeping and wailing and gnashing of teeth in management. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: using SMS compression - how to manage
From z/OS V1R9.0 DFSMS Storage Administration Reference: For a VSAM data set definition, the SIZE and MAXSIZE read-only variables reflect the space value specified in the CLUSTER component. If one is not specified in the CLUSTER component, then the space value specified in the DATA component is used. If a space value also is specified for the INDEX component and it is of the same type of space unit; for example, both are in tracks, cylinders, KB or MB, it is added to what was specified for the DATA component. DVC doesn't seem to enter into it. (unless it's changed since 1.9) You're right about CICS not supporting extended format ESDS, at least at one time - a newer release may have lifted that restriction. Greg Shirey Ben E. Keith Co. -Original Message- From: IBM Mainframe Discussion List On Behalf Of McKown, John Sent: Wednesday, April 27, 2011 2:06 PM Extended is the default for all non-ESDS VSAM files. I can't remember what it was, but we had some problem with ESDS files with Extended Addressing (perhaps in CICS). I may try to reduce the number of files in the FILTLIST. I was trying to duplicate the current compression environment, but that is likely overkill. Of course, if a file expands for no reason, people will complain. And the DASD allocation report will show a sudden spike. Which will cause weeping and wailing and gnashing of teeth in management. -- 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: using SMS compression - how to manage
Well, it might be as much work to manage, and so might not be what you want, but you could make use of the RACF DFP segments that everyone seems to ignore, which were designed originally to eliminate the need for programming ACS exit routines and things like FILTLISTs. The DFP segment for the generic profile that will protect a new data set specifies a RESOWNER, which may be a user or group. Or, in the absence of a DFP segment, the high-level qualifier of the data set profile provides the RESOWNER value. The RESOWNER (a user or group) also has a DFP segment, which specifies the default management class, storage class, and data class for all new data sets created on behalf of that RESOWNER. The defaults can be overridden by JCL or IDCAMS constructs, or the ACS routines if you have them, but they could easily assign appropriate default values without the need to keep updating ACS routines or FILTLISTs if you have a data set naming convention that is amenable to this use. You might need to assign a few dummy user IDs or group names to hold DFP information, but then you can simply set the DFP segment for an appropriate DATASET profile to the proper RESOWNER, and get defaults for anything new protected by that profile, and you're using RACF's generics rather than coding FILTLISTs. (For some reason, it always seemed that the first (and possibly later) generations of DFSMS educators seemed to be more RACF-phobic than the DFSMS designers were, and so they seemed to actively discourage usage of these functions, instead preferring that storage management folks become programmers. Of course, it may be that they simply didn't want to have to understand RACF, and felt that storage administrators shouldn't have to, either. Thus my comment above that everyone seems to ignore these functions. But especially if you're in a shop where you do both RACF and storage functions, or if you're in a shop where you actually talk to your colleagues and have good working relationships with them, the use of DFP segments might help you.) -- Walt Farrell IBM STSM, z/OS Security Design -- 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
