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... -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Thursday, January 31, 2008 1:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: identify sas uage by component Bruce, Excellent point but what we found out that two many OEM programs had to be altered to do this. The only way we could do it was to split all the user SMF records off to another file (deleting them from the cumulative file. Then we ran into auditing issues and were reluctant to buck heads with the auditors. We asked the three vendors how to handle the situation they all came back with different opinions. One was to time consuming to implement as each time we got programs from them (about 3 times a year) we had to insert logic to essentially delete the smf records in question. The logic entailed changing 30 COBOL programs. In one case the other vendors were a little cleaner and they were somewhat happy to have the records deleted before it got to them but they both produced error messages that type XX were missing and the accounting people weren't happy . Another vendor's code was set to abend if they didn't get the records they were expecting. We could not win. I suppose if its a home based system it might be easier but again depending on what you are doing with them. All but one of the OEM vendor products supplied source so yes we could change it *BUT* the vendors would *NOT* support it. We thought we had tried different options and none of them made everybody happy we were in a catch 22. We tried for an exemption and they would not hear of it. The one vendor want to have the record layouts of every vendor that cut SMF records. That was sort of OK but the lead time was at least 1 year. It got so bad between the vendors and internal politics and legal (auditors) we thought of creating two master tapes but that was a nightmare as the number of tapes was depleting our tape library with just one set if we had asked for more we would have been told no in no uncertain terms (we did approach the manager of the Library and he told us *NO* he was way over budget as it was). I don't remember the number of tapes but at the time we were growing by leaps and bounds and the library was threatening to have to acquire more space to accommodate them and we did NOT have more space (we had the entire building or at least the office space we had a restaurant in the basement and a small bank as well. The only option was to go into offsite storage and that would have set the budget skyrocketing. It was not fun but the place to work for was really good with their employees and we did try and make everyone happy but were unsuccessful and we were looked down on because we weren't a "team player", SIGH. 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
