Historically, SMF records were created as VBS in the original OS/360
implementation in 1964, because the OS developers only gave the SMF
component 1000 bytes of the nucleus for buffer space,
(the PCP nucleus was only 89K total!)
which the SMF team broke into two 500 byte buffers, and then used VBS,
as that was the only architecture that allowed you to write a logical
data record that contained 32756 bytes, when you only had 500 bytes
of real storage for your buffer. The original DCB attributes
were RECFM=VBS,LRECL=32760,BLKSIZE=500!
See my SHARE paper "The History of SMF", written in honor of the
Twentieth Anniversary of SMF in Newsletter FIFTEEN at
http://www.mxg.com/Newsletters
While the "officially documented" LRECL/RDW in SMFxLEN in the
SMF header has has always been documented as 32756 bytes,
which is a maximum data length of only 32752, RDW=LRECL=32756.
many SMF record creators have read that as a data length of 32756,
and have created VBS records with LRECL=32760, and there have been
at least two instances in the past (SMF 79 subtype 1, TSO/MON)
in which the actual data-length was 32760, which caused two physical
records to be created for that one logical record, one with the
first 32756 bytes of data, and a second spanned record with the
remaining 4 bytes of the data in a second VBS record.
Both of those records were corrected by their vendors when they
were discovered.
Even recently, some new SMF records have been created with an
LRECL greater than 32760, and then corrected, otably
APAR PQ72222 corrects SMF type 119 (TCP/IP V3) records that had an
invalid BLKSIZE and LRECL of 32768. The APAR text reconfirms the
SMF limit of 32756 bytes of data, i.e., LRECL=32760,BLKSIZE=32760.
Since QSAM has a hard limit of 32760 for both LRECL and BLKSIZE,
the only absolutely safe DCB attributes to read an SMF VBS file
has always been RECFM=VBS,LRECL=32760,BLKSIZE=32760, which covers
records with either 32752, 35756, or 35760 bytes of real data.
But you cannot convert an SMF VBS file to VB, if it should contain
a record with RDW=LRECL=32760, i.e., with the full 32756 bytes of
data, because, unlike VBS, a VB file is required to have its RDW
value 4 bytes less than the BDW, and thus a VB file can only contain
a record with 32752 bytes of data, RDW=32756, and BLKSIZE=32760.
If you copy an LRECL=32760 VBS record to LRECL=32756 VB record,
you will loose the last four bytes of data.
Also, on DASD, VB with BLKSIZE=32760 will waste tremendous
space for those large blocks, while VBS can use BLKSIZE=0
(for half-track blocksize) to minimize space requirements.
Those half-track blocks will contain spanned records when
the LRECL exceeds the half-track blocksize.
Okay, what about that LRECL=32767 instead of LRECL=32760 for VBS?
The (stupid, IMO) default of IFASMFDP is LRECL=32767, although
the records written to the VSAM file cannot exceed 32760?
Yes, MVS currently does allow you to create a VBS file with 32767
LRECL, but many other software products fail with 32767.
I have sent numerous requests for IBM to change the illegitmate
32767 back to the correct 32760, but the requests are unanswered.
The z/OS 1.6 SMF manual for the dump program at least does state
If you specify DCB parameters you must specify RECFM=VBS.
You can specify LRECL=32760 instead of 32767.
A final note: I always recommend the use of
DCB=VBS,LRECL=32760,BLKSIZE=32760
to read any V, VB, or VBS file, since V and VB
are subsets of the VBS architecture when those
attributes are specified.
In summary, you might well find that none of your SMF records from IBM
and other vendors exceed the data-length of 32752, LRECL of 32756, but
history suggests you'd place yourself at risk if you use those values.
Barry
P.S. SAS has always been able to handle broken VBS segments;
in fact, after my August, 1974 presentation of how State
Farm was using SAS to process SMF and that it would recover
broken SMF data, a number of attendees purchased what was
then the Statistical Analysis System, from the Statistics
Department at North Carolina State University (for $100!!)
solely to recover broken SMF data.
Recall that with VBS data written to disk with a small
blocksize, any record with LRECL greater than BLKSIZE is
spanned, so any system failure usually left you with a
block with spanned data at the end, and then the next SMF
block was the new IPL record after the failure, which
caused IFASMFDP to die with an 002 ABEND because it cannot
handle broken VBS segments!!
DATA _NULL_;
INFILE SMF;
FILE SMFOUT DCB=SMF;
INPUT;
PUT _INFILE_;
is all you need to recover that which is recoverable.
----------------------------------------------------------------------
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
