IBM Mainframe Forum

Hello,

z/OS: 2.2
DFSMS: 2.2

We have a dedicated storage group for temporary/'work' datasets. The maximum usage observed over a period of ~4 years was of 40% overall during batch run (i.e. free= ~60%).
Though very recently a %usage of 63% was observed during the batch run, this was there for a period of approximately 15 minutes post which the storage was released and the usage patterns were back to normal.
Have checked all the batch jobs that were executing within +/- 30 minutes time-window of this fluctuation. Verified the JESYSMSG for the usage of the volumes in questions, haven't been able to spot an abnormality there. Have verified the user activity, again by verifying the user-ids JESYSMSG, nothing fishy there as well.

Wanted to know if there is a way to extract the below information for that day's activity (SMF maybe?? Types 72/74?!? unsure):
a. The datasets that were allocated to the storage group in question for the time-interval in question
b. Source of these datasets, job or user
c. Storage used by the individual datasets

Thank you.

SMF 19 records, if collected, might provide you data. The type 72 / 74 records are typically associated with the WLM service class and not the storage group. I'd look at the type 30 records (assuming your site collects all 6 subtypes) for the interval in question.

Thank you Mr. Sample that helps; I'll work on this. IIRC 19 is not getting logged; will check again.

Hello,

You could also look at Type 14, 15 during that interval. It would give information about the list of datasets, size, storage group etc.. that were allocated during the problematic interval.
Along with Type 61 and Type 65.

It would be tricky to find the spike in storage group usage from type 14,15, 61 and 65. But they would provide dataset level information and the jobnames that created the datasets which would be vital.

Hypothetically I would take 10 minutes of type 14,15,61,65 then add all the allocated space, and subtract all the deleted space for datasets with STORAGEGROUP = "XXXXX". This would not be accurate, but we can identify the job/s which contribute to the sudden spike in storage group.

P.S - we are not considering renamed dataset SMF records.

Thank you Vasanthz, that helps. The naming convention of the work storage DS has the exact date/time stamp of creation within itself, so even if I get the list of DS (with allocation) on the storage group during the said time-frame, will be able to pull-out enough information to build an analogy for storage utilization. DS source name makes my life simpler. Will salvage the SMF logs.

Hello,

Before I jump into the thick of things, apologies, even though I have some experience with formatted-SMF-records, I am a beginner of beginners in raw-SMF-data processing.

I wrote a few quick-crude DFSORT steps to extract the various data types and format them.

Type-61:


Unless I haven't messed up the extraction/formatting, I didn't find a temporary dataset in this list.

Post this I browsed the unformatted SMF data in the MAN dataset, I could see that type 14/15/42 had entries for temporary datasets (x'0E', X'0F' and X'2A' at column-2 with HEX ON).

Second job run on type-14, which by the description looked closer to my current requirement:


Output for this appears as below:


The point where I am now stuck is:
a. How do I add the sub-types to this extraction? If I've understood it right, I'll have to add the length of each type to reach the starting position of the type I am looking for. And from that point onwards, add the offset of the field I am looking for to extract the exact data. For example, to extract the UCB section data, I'll have to add the lengths of all the preceding sections and then add the offset of the field I am looking for.
b. SMF14RIN which is reflecting as 8196 here, I am unsure if my data conversion was correct; though DFSORT has basically done what I asked it to do- convert binary to displayable data, but I am sure the code is messed up.

Any guidance is much appreciated, this is one opportunity for me to really get in and finally learn basics of SMF data processing.

PS: Other record types were also extracted in a similar manner, with similar challenges.

SMF record type 61 is ICF defines -- a temporary data set is not cataloged so it wouldn't show up here, normally.

SMF record type 14 and 15 have identical layouts and usually should be treated together (14 is input, 15 is output data sets).

a. SORT doesn't really handle SMF data very well -- you may wind up needing to use some other utility or write a program (if SAS is installed there, it works really well with SMF records). The TIOT and JFCB are fixed-length, and you get the DCB/DEB section length from offset 44 (SMF14SDC is the field name). Offsets 45 and 46 give you the number of UCB sections and the size of each. Once you calculate the offset to the first UCB section, merely add the size to get the starting offset for the next UCB section; continue for the number of UCB sections. And a terminology note: the 14 and 15 record types don't really have subtypes; they have sections. Record type 42 has subtypes and you'll see at offset 22 field SMF42STY which is a 2-byte binary subtype indicator for the record. Starting at offset 36, the number of triplets depends upon the subtype.
b. 8196 is correct -- SMF14RIN is a 2-byte set of bit flags - you will probably want to keep the SMF manual open while working with the record types as there's a lot of bit-level data in them. 8196 is B'0001 0000 0000 0000' which indicates that the data set is a temporary data set. It is possible for some of the other bits to be set as well (but not likely for just a temporary data set).

Thank you for the pointers and the correction Mr. Sample.
Sadly, we do not have SAS or a SMF data processing tool as MXG; the only options that I have- all revolve around building a logic with a programming language as COBOL/REXX or a tool as DFSORT.

Aside, please correct me if I have again misunderstood the data format; 8196 (DEC) to binary comes as: 0010 0000 0000 0100, so from the SMF manual, bit 3 tells me that DS is a temporary dataset, and the 14th bit tells me that 'Task termination closed the DCB'.

You'll have quite a time with the data, then -- especially if you need any of the records with subtypes.

Yes, you interpreted the bits correctly -- I forgot to add back the other bit when I was explaining earlier.