Date:         Thu, 12 Oct 2000 03:02:36 -0400
Reply-To:     Gerhard Hellriegel <ghellrieg@T-ONLINE.DE>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Gerhard Hellriegel <ghellrieg@T-ONLINE.DE>
Subject:      Re: FS Records

On Wed, 11 Oct 2000 18:09:17 -0400, Dianne Rhodes <RHODESD1@WESTAT.COM>
wrote:

>Jack Hamilton wrote:
>
>>>  The record format FS is a fixed spanned record, it means that you may
>span
>>>a record over more than one block.
>
>>In the case of FS, S stands for Standard, not for Spanned.  See
>
>>><http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/IEA1B640/12%
2e48
>%2e3?SHELF=>
>
>
>I dunno Jack, maybe you can't depend on every thing you read on the web.
>According to Gary DeWard Brown's book :
>
>S       Spanned records.  For V format records- logical records are spanned
>over more than one block.  For VS or VBS the BLKSIZE is independent of the
>LRECL.
>For F format records - no truncated blocks or unfilled tracks within the
>data set.  S Cannot be coded with U, T, or D.
>
>Or maybe they "changed it"!
>
>Dianne Louise Rhodes
>Sr. Systems Analyst
>Westat
>(xxxx) 315-5977 work
>(xxxx) 315-5934 fax


Hi Dianne,
think you are right!
Also another point is to be corrected at the SAS environment: it's not easy
to say, which LRECL/BLKSIZE is optimal for ... You have always to say:
optimal for what and optimal where! It depends on:
1. what you want to optimize: space in memory (if you have constraints and
memory problems, choose a smaller LRECL, e.g. 6144, if you have not, use a
bigger one, e.g. half-track - 27648 on 3390)
To get the best performance choose half-track.
2. where (on what device) you are optimizing and what kind of data you
store in WORK!
For big SAS datasets half-track, for temporary SAS-catalogs (GRAPHs,
FORMATS, MACROS, ...) or other things, like VIEWs, small SAS datasets 6144
seems to be better.

I think the rule is: if you have big datasets with long records in WORK,
try to use half-track, if you have small datasets (or other things) with
short records, use 6144 to optimize the overhead for buffer-handling.
If you want to optimize something: why do it with WORK? You can seperate
your data handling in 2 parts: one for the big datasets, one for the
smaller things. Allocate a special TEMP-lib with a half-track LRECL for the
big datasets and change your application logic accordingly. The other way
is: you can use HIPERSPACE for SAS-WORK. That has a very big impact on
performance!

All is changed, if you have a big hiperspace in expanded memory (not on
DASD) and you can allocate your WORK there. I don't know what's optimal
there. Maybe you should try it out, depending on your application. I
assume, that there it's not useful to use big LRECLs, because the whole
management (to let it work like a DASD) is emulated with 4 K blocks. You
could try 4k as LRECL or a multiple of that. Maybe the handling of the
buffers is the bigger part there, not the IOs.

By the way: if I write "performance", what do I mean? The impact on the
pure CPU time (TCB/SRB) is small. The elapsed time is it, what you can
optimize. The task is not waiting so long for the IO-subsystem to complete
the IOs.
For that you can also use another trick: try the SAS option COMPRESS=YES.
The CPU time for handling the compression is more, but the IOs are shorter,
because less data is to be transported. Most DATA-steps and PROCs can
handle compressed data.