------------------------------------<snip>-------------------------------------
This "idea" was inspired by the recent posts about the IEFU8n SMF exits. Writing and debugging this
type of exit can require a good level of knowledge and skill. So what occurred to me is a new facility for
receiving SMF records at/near generation time. It could not be used to modify the records or to say "no,
don't write it". It would be simply for "I need to look at the SMF data in near real time in order
to do something else."
I apologize for the following being so vague and poorly written.
What this would consist of is a way to register a need for a copy of the SMF
data. This request would result in a local data space being created for the
address space doing the request. Control blocks would be created in this data
space. A copy of the SMF record would be made in this data space and chained
into the control blocks. The simpliest form of the API would simply copy all
SMF records into this data space as they are generated. If the data space fills
up, then records are lost. A more advanced form of the request would have a way
to specify a type of filter. This filter would only copy SMF records which had
specific values in specific fields. I don't know all the filters, but was
thinking of filters on fields in the SMF header such as SMFRTY, SMFSID, SMFSSI,
and SMFSTY. Of course, their needs to be a way to process this data. So, some
variations could be: POST an ECB; schedule an IRB on the TCB which is using the
API, passing a pointer to the record; schedule a loc!
a!
l SRB into the address space with a pointer to the record; ??? . In the POST an
ECB case, there would be an API to dequeue the next record. An RC would
indicate no more records so the dequeue could be in a loop. When no more
records, the code could do whatever and eventually the ECB would be posted
again. For a SYNCHRONOUS request, the API could be set up so that a WAIT is
automatically done until another record is available.
Would such an API be generally useful to the community? Or am I off in the
parking lot again?
---------------------------------------<unsnip>-------------------------------------
You're parked in the right lot, John. I did something like this once.
IEFU83/4/5 exits were constructed to invoke other exits, with a name
form of BOTCCnnn, where nnn was the record type. The vast majority of
the BOTCCnnn exits were simple IEFBR14's, linked directly to the IEFUxx
exits, but a select few had additional functionality, such as a display
in SYSLOG each time a FTP was completed, showing sender, receiver, bytes
transferred, etc. Another one was a display, tailored as needed, for
each time the RACF database was updated via RACF command. (Auditors
LOVED that one!) And another, again suitably tailored, for each time a
LINKLIST dataset was altered.
At that time, management required that we IPL all systems weekly, so
updates were relatively easy to install, although the exit code got to
be rather large until management decided they were "micromanaging" and
reduced their requirements. In retrospect, I probably could have
slightly reduced the "overhead" by just checking for an unresolved
AD-CON for the supplementary code and bypassed the call. There's that
20-20 hindsight again, biting me right where the "sun don't shine".
I still think the basic idea was good, but the implementation might have
been better. :-) Who was it that said "A little education can be a
dangerous thing?"
Rick
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
