(Originally posted 2012-07-07.)
It’s said that imitation is the sincerest form of flattery. In this Social Media age I’d say indirection comes a pretty close second. Indeed there’s a nice term for it: "link love".
Standard advice is not to just post links to the content of others. In reality the word "just" should probably be inserted: Don’t just post links to the content of others.
In that vein I want to point you to Page 9 of Xephon’s MVS Update 199 (April 2003). But I want to give you a little perspective – as my small slice of "value add".
(Before I do I would draw your attention to Xephon’s Copyright notice at the bottom of Page 2. And indeed I intend to stick to it myself.)
Many people alight at this blog after a search for something DFSORT-related: The Referer (sic) URLs tell me that. So I’m going to assume it’s enough to state that DFSORT Symbols allow a record’s structure to be mapped as named fields. You specify these in the SYMNAMES DD with lines like:
XYZZY,27,4,CH A hollow voice says "Plugh".
This line has five parts:
- Symbol name – XYZZY
- Position – 27
- Length – 4
- Type – CH
- Comment – A hollow voice says "Plugh".
There are other formats but this post doesn’t require me to describe them.
Contrast that with a DSECT line with similar properties:
XYZZY DS CL8 A hollow voice says "Plugh".
One thing that’s missing is the Position (27). It’s implicit from previous statements in the DSECT.
Last week I went through an exercise of converting a DSECT (in fact DFHMNPDA) to DFSORT Symbols – in support of what I described in Another Way Of Looking At CICS Monitor Trace Data. It was a tedious exercise. I did it mostly through mass edits in ISPF. I thought "there has to be a better way", as one does under such circumstances.
My first take was it could be done by having REXX drive HLASM and parsing the output listing. There’s one thing I’ve neglected to mention. It is rather stating the obvious:
HLASM syntax is far more sophisticated than DFSORT Symbols syntax.
So you couldn’t, in general, parse an Assembler deck (in this case a DSECT) and hope to make a good conversion to a DFSORT Symbols deck. A while ago I embarked on this route – after a previous bout of frustration at creating Symbols from a DSECT. It’s the wrong approach.
But getting the Assembler to do the hard work is the right approach.
But friends convinced me – via Facebook 🙂 – that parsing the HLASM output listing is the wrong approach. The information is there but parsing listings with code is just plain miserable – as experiences go. The correct approach is to parse ADATA from HLASM – as it has structured data. Parsing it is a more robust thing to do.
Fortunately, before I had a chance to embark on this (admittedly hobby) project I noticed the Xephon link at the beginning of this post.
I will admit I haven’t even nosed through the listing, yet alone tried the program. I’d assume it’s good – else it wouldn’t’ve been published.
And the reason I’ve not looked at the code is because I may one day want to do something like this and wouldn’t want the copyright issues. Further, I already guess I would want my code to do more. Here’s a for instance:
In the DFHMNPDA DSECT there are numerous XL12 fields. These are STCKE-based fields. As I mentioned in the previous blog post they were widened from 8 bytes to 12 in CICS TS 3.2. My way of processing them is to take bytes 4 to 7 and multiply by 16 to get microseconds. So the DFSORT Symbols that map these 12 bytes will be something like:
SKIP,4 PDRCPUT,4,BI CPU Time SKIP,4
I doubt the referenced code would generate that – as it’s pretty specific. If I wrote some code it might well have an option to do that. And there are a number of things I could imagine doing that add value to the basic conversion process – such as generating some diagramming.
Anyhow, give the referenced code a try. I’d like to know how you get on. And if anyone could tell me who wrote the code I’d be glad to acknowledge them here.
Mainframe, Performance, Topics 