Date: Fri, 11 May 2007 15:22:48 -0700
Reply-To: Jack Hamilton <jfh@STANFORDALUMNI.ORG>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Jack Hamilton <jfh@STANFORDALUMNI.ORG>
Subject: Re: OT: z/OS SMS compressed datasets
In-Reply-To: <200705112134.l4BJZEeH015970@malibu.cc.uga.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I think the run-time issue would be that I/O is slowest thing a program
does - so even if there's more CPU usage, the program will still run
faster because of decreased I/O.
I recall hearing of cases where using compression decreased BOTH i/o and
CPU usage, because the increased CPU needed to do the compression and
decompression was outweighed by the decrease in CPU needed by the i/o
engine.
charles.harbour@PEARSON.COM wrote:
> Storage is cheap!
>
> Even for shops that don't do chargeback, this is a truism, from both an
> engine purchasing point of view, as well as software licensing point of
> view (based on MIPS or MSUs).
>
> There are also real-time considerations, in that more cpu time nearly
> always translates to longer elapsed times--if you have a short down-time
> window to get your daily run completed before the next business day opens
> (esp if you have world-wide operations), the trade-off is pretty much a no-
> brainer.
>
> I would think this would apply largely to the huge shops and not smaller
> operations, but storage really is cheaper than cpu at pretty much any level.
>
> I do have a question back to the list--does having compression turned on
> affect whether or not you can run parallel processing? I would think an
> index would be hard to reference quickly if it's compressed, but I don't
> know that for a fact. Anybody done any testing around this?
>
> CH
>
>
> On Fri, 11 May 2007 20:37:01 +0000, toby dunn <tobydunn@HOTMAIL.COM> wrote:
>
>> The only thing I know of and others will chime in with hopefully something
>> important if one exists is alot of companies get charged by the CPU time
>> used. Thus if you have to use more CPU time it could end up costing your
>> company more than if they had just bought more DASD disk packs.
>>
>>
>>
>> Toby Dunn
>>
>> On the other hand, you have different fingers. ~ LCG
>>
>> The early bird may get the worm, but the second mouse gets the cheese in
> the
>> trap. ~ LCG
>>
>> What happens if you get scared half to death, twice? ~ LCG
>>
>>
>>
>>
>>
>> From: "Jeff J. Voeller" <SAS-Programmer@WYWH.COM>
>> Reply-To: SAS-Programmer@wywh.com
>> To: SAS-L@LISTSERV.UGA.EDU
>> Subject: OT: z/OS SMS compressed datasets
>> Date: Fri, 11 May 2007 13:25:15 -0700
>>
>> This isn't specifically SAS-related, though I imagine it's something
>> others out there have looked into.
>>
>> It's possible to designate mainframe datasets as compressed, usually
>> (always?) via a DATACLAS. I've been doing this for a while and have had
>> no issues, but I recently searched our production libraries and have come
>> to the conclusion that literally no one else in a rather large company is
>> taking advantage of this capability, at least not in the production
>> environment.
>>
>> I'm curious why this would be the case. All I see when I use compressed
>> datasets is lower--sometimes dramatically lower--DASD usage. There's also
>> presumably higher CPU usage, though I have not found this to be a problem.
>> SAS libraries can't be in SMS compressed datasets, but that's no trouble
>> either. Since *my* production jobs are taking advantage of compressed
>> datasets, it's also clearly not some kind of arbitrary production
>> standard.
>>
>> Is there some insidious catch that I'm missing which will some day bite me
>> in an uncomfortable place? I've searched around a bit, but haven't found
>> much beyond variations on "Oh yeah, you can use compression."
>>
>> _________________________________________________________________
>> Now you can see trouble?before he arrives
>> http://newlivehotmail.com/?
> ocid=TXT_TAGHM_migration_HM_viral_protection_0507
| 
