I just glanced at this before I head off for something else, and I may not understand fully what you're saying...
Why would you need to "own the programs"? The possible solution I offered up should work without any vendor programs being touched. Basically, the SMF records are intercepted by YOUR IFASMFDP exits before they are dumped , and modified ever so slightly. The vendors programs have nothing to do with this. By the time the records are intercepted, the vendor's code has already forgotten about them. If the processing of the SMF data in question is all in-house, this should work just fine. Even if the SMF data dose go out of house, code another couple of exits for IFASMSFDP to reverse the modifications and then dump the data to, say, tape for sending the data out. Does this make sense? -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Friday, February 01, 2008 1:14 AM To: [email protected] Subject: Re: identify sas usage by component On Jan 31, 2008, at 11:02 AM, Gary Green wrote: > I have not followed this thread so forgive if this was covered > earlier... > > Speaking off the top of my head (yeah, I know, I know...) > > I need to leave aside the fact that any change to an OEM's SMF record > requires tweaking of any vendor record specific downstream processing. > If all this processing is done in-house, that's no big deal. A slight > tweak to Barry's MXG record definitions, could handle that. If the > data is sent to the vendor, that is easy as well. Just coble > something together to reverse the changes. > > ... > > How about looking into writing an SMF Dump Program exit where you > would modify the OEM SMF records on the fly and use your own > record-type/ sub-type numbering scheme. As the records pass through > your exit, you would modify the appropriate records before they are > written to the SMF dump tape/disk file. > > 1. If the vendor's SMF record uses a header with the SMFxSTY (subtype) > field, dump a few thousand of their records to see if they actually > use the STY field or is the value constant. If constant, it's > possibly ripe for you to use. For this type of record, change the > record type and subtype to your liking. XX for the record type and yy > for sub-type for vendor yy, and zz for vendor zz and so on. > > 2. If the vendor's SMF record does not use a header with the SMFxSTY > (subtype) field (most likely), you have two options. > A. You could reformat the record header to make it support subtypes. > Allocate a buffer to rebuild the record, copy the existing original > 18 byte > header and actual Vendor SMF record data to the appropriate area in > the buffer and change the record type then insert the subtype in the > SSY field to represent that specific vendor. Of course, if the > vendor's record uses triplet fields, they would need to be modified as > well. I would review the documentation from the vendor for this > information. As for the SSI field, I would ignore it since it was > never there in the first place. > > B. You could use the SMFxFLG field. I look at records all the time > and "I" > do not recall ever seeing a vendor actually using this field; of > course YMMV. That said, I dumped a million SMF records between > 128-255 they all contain the same value; 1E in my case. You could use > this field for your vendor specific sub-type value and then change the > record type. Of course, this will only provide you a 16:1 reduction > in used records types but that's better than nothing. ;) > > .. > > Now, if one were to entertain this idea, the big question is, if > multiple vendors use the same SMF record type, how does one > distinguish one vendor's > record from the others that are using the same record type. > Generally, > there is almost always some type of eye-catcher in the record that > would give it away. > > A simple branch table/array to identify the records to process. In > that table/array you could have an offset to the eye-catcher location > to interrogate and another pointer to an array of values to compare > against, any one of which would be a hit. > > JMTC... > > Sure that is possible if you *OWN* the programs in question but our issue at the time was OEM code (usually in COBOL) and you can't change the code. If you do you own it. Then there is the issue of maintaining the code with (about) 3 updates a year. Our staff was not equipped to handle that type of change. Yes we were understaffed but who isn't? At the time we had one individual handling the SMF products and he really worked his butt off doing so. Add to that we were on the bleeding edge of IBM PTF's it was all we could handle plus the installation of OEM software plus we had quite a few experimental (more like early ship) equipment (DASD & TAPE) and few other items like we were FCS on some IBM controllers that we were dying to get our hands on as we were busting our seams trying to keep the number of UCB's below the magic number and and and... in other words we had our hands full. I am sure there are ways but since we didn't own the code and the vendors were not sympathetic about us touching their code. I won't go into the vendor arm twisting that was done and it was tried just a dead end. One vendor told us that they would charge us 25K a hear and an hourly rate if we really needed it. Even if we could have gotten the same deal (unlikely) from the other 3 that would have raised the cost to probably over 100K a year. Ed ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
