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. Thinking that larger CI Size would
always minimize the number of I/O operations, I and others lobbied for
the option to increase the CI Size to half track, and finally in MVS/ESA
the restriction was removed. Now, however, I realize that a larger CI
size, coupled with the frequent occurrence of records larger than the
half track CI size, can significantly waste space, as this example with
a CI Size of 26624 (half-track on 3390 device) will show:
New variable-length records are put into the current CI as long as
the new record fits. If there is not enough room for the new record
in the current CI, the new record is normally NOT spanned; instead,
the new record is written into the start of the next CI. Record
spanning only occurs if the new record's LRECL is greater than the CI
size of the VSAM data set. In that case, the new record starts in
the next CI and fills as many CIs as are needed to write the long
record, but then any space remaining in the final CI for the long
record is never used. Consider this example with records of 1000,
32760, 1000, and 32760 bytes using a 26624 CI size:
|------track 1------|------track 2------|------track 3------|
CI=1 CI=2 CI=3 CI=4 CI=5 CI=6
|AA-------|BBBBBBBBB|BBB------|CC-------|DDDDDDDDD|DD-------|
Data: 1000 26624 6136 1000 26624 6136
Wasted: 25624 0 20488 25624 0 20488
Thus 67,520 bytes were written, but the 6 CIs (159,744 bytes) used
three full tracks for the four SMF records.
In contrast, with a CI size of 8192, these same 4 records are written
in 10 CIs (81,920 bytes) on only two tracks (actually, less than 2
tracks, since the last 2 CIs on the second track can be used for
additional SMF records):
|--------------------------track 1--------------------------|
CI=1 CI=2 CI=3 CI=4 CI=5 CI=6
|AA-------|BBBBBBBBB|BBBBBBBBB|BBBBBBBBB|BBBBBBBB-|CC-------|
Data: 1000 8192 8192 8192 8184 1000
Wasted: 7192 0 0 0 8 7192
|--------------------------track 2--------------------------|
CI=7 CI=8 CI=9 CI=10
|DDDDDDDDD|DDDDDDDDD|DDDDDDDDD|DDDDDDDD-|---------|---------|
Data: 8192 8192 8192 8184 available available
Wasted: 0 0 0 8
Note that if there are no records greater than 26624 bytes, the
wastage is less (only space at the end of the current CI is wasted),
and thus the serious wastage only occurs in practice if you have many
CICS type 110 SMF records, as they are the only high-volume long SMF
records in today's environment. Prior to CICS/ESA, you could
actually alleviate this problem, because you could specify the size
of the buffer in CICS and thereby restrict the type 110 record to be
less than the SMF CI size to minimize wastage, but in CICS/ESA, the
CICS performance record buffer is fixed at 32760.
Barry Merrill
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Shmuel Metz (Seymour J.)
Sent: Saturday, February 14, 2015 7:01 PM
To: [email protected]
Subject: Re: FB to VB PDS
In <[email protected]>, on
02/14/2015
at 02:34 PM, Paul Gilmartin
<[email protected]> said:
>We're in unusual agreement here. Needs:
>o VB(S) capability.
For VB I agree. I don't see the point of VBS except for special cases like SMF
and FORTRAAN I/O.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
