IBM Mainframe Forum

Honestly I don't know the point of this, because I suppose there are many other things that can do the job on the mainframe...but they say they can't do it (or at least, for all the Record types they want - but if there is anything that put any kind of records in an human-readable format, please let me know!!!).

So I asked for a type80 example to start pratice on this, as I really don't have the needed expertise on IBM stuff, as you could notice on all of my posts over here.

But now I understand everything...If any of you can, gently, answer my 2 last questions on previous posts about reading that example, I swear I will never back again with these stupid questions!

Regards,

Looks like when you dump an SMF file you get the 02 as a "header" for that, even if selecting one record type.

Robert's print is not showing the RDW, so take four bytes off all field positions. You read left-to-right. If you note the 0111359F. Robert, today, created a file of the 80s from yesterday. So the 02 has today's date, 0111360F, and the 80s yesterday's date.

Oh, ok. Now it makes sense. I wasn't aware of the lack of the RDW on that example too. Thank you very much.

So, even if this is a silly and stupid task for me, I have to talk with the mainframe admin regarding two problems: The missing RDW and to give me a file with only one record type. From then on, I can ignore that first header and process all the records. Just another simple question: Does that header have a fixed size?



@ enrico-sorichetti

Thanks for the advice! I can't work on the mainframe but maybe the admin will find that tool very effective. But is that tool capable of generate reports regarding all the records type or just 80's?

Not so simple, as the 80s are variable-length.

Usually a site will have a variety of "canned" reports to process the SMF data that they are interested in. It is usually a "techie" thing, and may be done by a variety of different groups (or centrally) depending on the site. There are some packages which do this, or with locally-developed stuff in whatever language/utility they like.

If all the data you require do not have existing reports, then Robert's example shows another way. If they do a "hex dump" of the file to a report, as Robert did, they can download that dataset to you. All the data will be in character format, and will already be showing the data for the lengths of each individual record. You would then need to "parse" the data, but that should not be too onerous.

The header record will be useful to you, as it will show you the (system) date of the extraction. You could validate the dates on individual records against the reporting period. The extraction date would always have to be at least one day ahead of the reporting period, else you'll have to get fancy with the times so as not to loose any data.

BillyBoyo,

I think they've tried to do a SMFDUMP (I guess) but I heard they only can do it with Type 80. Maybe that is the "hex dump" you are talking about, no?

Or that hex dump is another thing that can "textualize" any record from any type, and they aren't aware of the existence of it?

Just looked back at Robert's example

It is possible to produce a hex dump with the character representation as well, which would help you out a lot. For character fields, you'd get the correct ASCII values without having to get fancy. For non-character fields, you'd have the EBCDIC representation in hexadecimal pairs for each byte, which you could interpret correctly and produce the output from your program in ASCII, ie the date field (unsigned packed-decimal) and the time field (eight-bit unsigned binary representation of hundredths of second since midnight). You will also have binary fields telling you how many sections of repeating data particular records have, bit-mask values etc. You won't need to interpret everything I assume.

The 102 might be more of a nightmare, but there you go.

I now see another response "crossing in the post", so:

They should be able to "dump" any types of SMF records from the huge SMF dataset as far as I'm aware.

Having got the selected data out, there would be a number of ways to produce a "hex dump" of a particular dataset, including such character-representations that match the byte values (like the MVS1 in your example). You'd also get characters, by chance, in non-display fields, just because they happen to match a character value, so don't get confused by that.

If reports already exist, that would be a better way to go. If they don't exist but can be written, that would be a better way to go. If "none of the above" you could still work from a "print" of the dataset showing character and hex values. The disadvantage would be extra work for you, accurately, interpreting the data which is in mainframe formats. The advantage would be if there is no other way to get all the pre-formatted data for your task.

I think you (via your boss) need to bounce it to someone on the mainframe to establish if reports are available, with everything you need, and if not whether they can be produced. You have a fallback position. The bosses have to decide about the various efforts involved in doing this.

Yes, I have to escalate this problem to someone on the mainframe.

So, if I've got it right, there are mechanisms at the mainframe capable of producing reports that "translate" the records from the mainframe format to a more "friendly" format. This format can easily be parsed with some regular expressions or something. And this is valid for every record type. If there is no reports, someone can write them, again, for every record type.

If, for any reason, this is a "no-go", then I have to develop a huge pre-processor to translate and parse all of that binary stuff.

Is that it?