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 *
[email protected] * 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:[email protected]] On Behalf Of Gibney, Dave
> Sent: Wednesday, April 27, 2011 1:39 PM
> To: [email protected]
> 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:[email protected]] On
> > Behalf Of McKown, John
> > Sent: Wednesday, April 27, 2011 11:14 AM
> > To: [email protected]
> > 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 *
> > [email protected] * 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 [email protected] 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 [email protected] 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 [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
