On 02/15/2015 05:59 PM, Barry Merrill wrote:
Except that SMF does not write normal VBS data.
This is from Chapter 3 in my 1984 Book, member ACHAP03 in MXG Software:
SMF has always used a RECFM=VBS, i.e., Variable, Blocked, Spanned record
format. This is because the original OS/360 implementation would only
give 1000 bytes (of its 88K nucleus!) for SMF data, and the only way you
can write long logical records with a small physical block size records
is to use VBS!
However, the SMF Writer does not use normal VBS; in normal VBS, all data
records are spanned, so that all blocks are full, but that is not what
the SMF writer does in its "pseudo-VBS" architecture. Instead of
spanning all records, SMF records are only spanned when the LRECL of the
record to be written is larger than the BLKSIZE of the dataset. Why
does SMF not span all records? It all goes back to the original BSAM
architecture introduced in OS/360 in 1969. The SMF dump program could
not read broken VBS records (the dump failed with an ABEND 002). If all
records were spanned, any system crash would always cause the SMF dump
program to ABEND (because the last block written to DASD would always
indicate spanning, but the next block written found would be the new
un-spanned IPL record that had been written after the crash). So as to
minimize the probability of the 002 abend, the SMF writer normally wrote
mostly-VB records, with an occasional long record written as VBS.
In 1978 the SMF Writer was redesigned and a VSAM data set is now used.
The "pseudo-VBS" algorithm was carried forward, and the initial maximum
CI size permitted was 4096 bytes.
<SNIPPAGE>
Thank you. Brings back memories of SMFMERGE ABENDs and GDGs from
when I was working in a JES3 shop in the late '70s.
Boy am I glad those days are behind me.
Later,
Steve Thompson
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
