Re: identify sas usage by component
On Feb 1, 2008, at 12:44 PM, Gary Green wrote: Okay... That makes perfect sense. Sorry, but I missed the "number of tapes issue". Was that because of the quantity of SMF data from the vendors products or just keeping their data separate from all the rest? SNIP-- It was just the shear number of tapes period. We were just running out of tapes and place to keep them. We also needed to be able read the tapes on a few minutes notices (going back at least a year) because of auditors needs. Its a complicated story as to why and I will explain if needed. Our DC spanned two floors and we had nowhere to expand except to offsite. We managed to clear some space but that was swallowed up by another CPU that was scheduled to come in within a few months. We also had cable restrictions (lengths) etc to worry about for the tape drives, Looking back we should not given out the floor above but it was impossible to get it back as the people who had it put their own mini data center into it. We were busting at the seams. The floor below (the tape library) was HVAC (for the DC and the entire building) and that was untouchable. Its a complicated story but it was a no win situation. We needed todays technology back then. 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
Re: identify sas usage by component
Okay... That makes perfect sense. Sorry, but I missed the "number of tapes issue". Was that because of the quantity of SMF data from the vendors products or just keeping their data separate from all the rest? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Friday, February 01, 2008 1:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: identify sas usage by component On Feb 1, 2008, at 7:39 AM, Gary Green wrote: > 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? > -Yes/no The auditors were vocal about any change to raw smf data. We looked into doing a transformation ourselves and presented it to the auditors and they said "NO" well... if we did we had to maintain unedited copy and we were back to square one with the number of tapes issue. 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
Re: identify sas usage by component
On Feb 1, 2008, at 7:39 AM, Gary Green wrote: 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? -Yes/no The auditors were vocal about any change to raw smf data. We looked into doing a transformation ourselves and presented it to the auditors and they said "NO" well... if we did we had to maintain unedited copy and we were back to square one with the number of tapes issue. 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
Re: identify sas usage by component
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: IBM-MAIN@BAMA.UA.EDU 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
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
Re: identify sas usage by component
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 u
