Appologies if anyone got this twice, it didn't seem to come through first
time.

Guys,
     At the time that real 3390s were replaced by RVA/ICEBERG DASD we threw
away all our DASD allocation guidelines on blocksizes and space allocation
as RVA compressed the track anyway before storing only the used data on
physical DISK. We started to use blocksizes that suited the data rather
than the 3390 geometry. E.g. We typically blocked sequential files as large
as we could as it didn't matter if we wasted 1/3 of a track, we just
defined more virtual 3390s. We also made datasets too big to avoid SB37s,
again if the space wasn't used it wasn't on 'real' disk.

I've just discovered, a bit late I know, that ESS/Shark DASD does not
compress the tracks and so there is now, again, a direct relationship
between virtual 3390 tracks and physical disk usage. To save ESS disk we
should use half track blocks & allocate only as much as we need, etc etc.
Also ESS may sometimes read blocks of data, not full tracks, so small
blocks may be advantagous in some cases.

Having read some of the ESS doc I'm still trying to get my head round the
implications of this. Do all the old 3390 best practices now come back into
effect or are there some wrinkles for ESS? I understand about PAV, Multiple
Allegiances, Logical volumes etc, I'm looking for the end user dataset
allocation type information. Things like what block sizes to use and the
impact of inter-record gaps, assuming they still exist?

I've searched IBM-MAIN and the IBM hardware manuals without much
enlightenment. Perhaps I got my search wrong, or perhaps as ESS DASD has
been around for such a long time the discussion may have fallen off the
edge of the internet!

Is there a good document/discussion anywhere of best end user DASD
practices with ESS/shark?

Regards, Ron.

----------------------------------------------------------------------
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

Reply via email to