(Originally posted 2013-10-12.)
In What I’m Looking Forward To In z/OS 2.1 I mentioned processing VBS (Variable Blocked Spanned) data with REXX. This post describes what I learnt when I used it on our residency z/OS 2.1 system.
The most widely-known VBS data is SMF, though the Tivoli Workload Scheduler (TWS) Audit Log is also in this format.
A lot of different types of data are stored as Variable Blocked (VB) data, but this has the restriction that no record can be longer than the block size. Variable Blocked Spanned (VBS) data can, in contrast, contain records longer than the block size. SMF data often contains records which indeed are longer than the block size.
Prior to z/OS Version 2 Release 1 it was possible to process some SMF data by copying it to a VB data set. But this is risky as actually spanning records would be broken this way. (A typical example is SMF Type 30 Address Space records.)
Reading SMF
For my first experiment I extracted SMF 70 Subtype 1 records and printed the SMF ID (from the record header) and the Hardware and Software Model from the CPU Control Section.
To read the records you typically use EXECIO. My very first experiment used
"EXECIO * DISKR RMFIN (STEM RMFIN. FINIS"
but this caused the job to run out of memory. That’s because there was a lot of data – and the “*” means “read all the records”. I could’ve used
"EXECIO 1 DISKR RMFIN (STEM RMFIN."
(note no “FINIS”.) But I prefer to read, say, 100 records at a time.
When you read VB or VBS data REXX returns records without the 4-byte Record Descriptor Word (RDW). But SMF data contains offsets relative to the start of the record (including the RDW). The solution to this is to add three hexadecimal zero bytes to the front of the record. It’s three rather than four to take into account the fact REXX uses 1-based positions rather than 0-based offsets.
Writing SMF
Reading’s fine and allows you to experiment with the data. But writing is pretty useful, and I have a real use case in mind.
For my experiment I took the very same SMF 70–1 records and wrote them out. Again, no problem. (I did remember to take the three byte prefix off that I’d added when reading.)
Both SMF Dump and, more pickily, ERBSCAN and ERBSHOW were happy with the data.
The use case I have in mind is with different data: We’ll be running a fair number of batch jobs and there’ll be a naming convention that covers them. We’re only interested in these “test case” jobs and not e.g. compile jobs.
So I’ll write a REXX EXEC to read in the entire set of SMF 30 data and write out only the records that pertain to these jobs. Then my analysis code will run much faster (and so will getting the data to my home system be).
Certainly I can (and probably will) extend this to extracting the related SMF 101 (DB2 Accounting Trace) records and maybe the data set ones. But the 30’s will tell us how well our cloning efforts are doing.
I’m not recommending you replace more efficient SMF-processing tools (such as Tivoli Decision Support or SAS / MXG) with REXX for Production. But VBS support in REXX makes it easy to prototype analysis and to check data in a quick-to-write way. Which is exactly what I’d thought it would do.
And, to show we’re not all work and no play 🙂 the team is off to the Walkway Over The Hudson. It’s a nice day for it. 🙂
Mainframe, Performance, Topics 