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
