What we are looking for is a solution to the following requirement from
IFASMFDL (taken from the SMF Manual Chapter 3, Using the SMF Dump
Programs):
For an ARCHIVE request, you must write each record in the log stream up
until the end date and time to at least one OUTDD. Ensure that all the
types
and subtypes and all SIDs are being written to a data set or are
specified on
the OUTDD parameters. If any record fails to match any specified OUTDD,
the request fails.
For IFASMFDL to have this requirement as a stand-alone program makes
sense, since it will be deleting the records from the logstreams once
they are written out successfully. But, in our case, IFASMFDL is being
used as a sub-program, being called from SMFDLS with three user exits
that control its operation and manage the records outside of the
auspices of IFASMFDL. Effectively, we are using IFASMFDL to gain access
to the records and that is all we need for it to do.
In CA's SMF Director, they write to the SMFDOUT DD (the DD we define in
our generated control statements to run IFASMFDL) if the customer
allocates a real file to the DD, or set a return code of 4 if the file
is allocated with DUMMY (so we skip writing the record). When ARCHIVE
is being used, the return code of 4 from User Exit 2 is honored, but
the dump completes prematurely since the records were not written. I
suspect they allow a return code of 4 coming from the User Exit since
it is possible that a record could be selected by multiple OUTDD
statements in the run. As long as it ends up going into one of the
OUTDDs, it will be ok. IBM has not accounted for the exits managing the
records on their own and allowing a customer to skip writing the record
out.
What we would like from IBM is any of the following solutions:
1) An additional return code for User Exit 2 that indicates to
IFASMFDL that the record should not be written because processing in
the User Exits will manage the records, therefore there is no need to
terminate the run because the record was not written to an OUTDD file.
2) An option in the control statements that would tell IFASMFDL
that when we are using ARCHIVE, that the check to ensure records are
being written can be skipped
3) A check in IFASMFDL to allow for records to be skipped if and
only if IFASMFDL is not the primary program being run in the job step
(meaning that if PGM=IFASMFDL is named in the JCL, the record writing
requirement will be enforced, but if another program is the primary
program and IFASMFDL is a subprogram, that the record writing
requirement can be skipped.
My personal choice would be option 1, a new return code, but that one
will probably be more work for IBM. If they do make a change, I would
suspect they may do option 2, or a combination of options 2 and 3 (in
that they will allow the new control statement, but only if IFASMFDL is
a subprogram.)
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - zSeries Software
Product - z/OS
Component - BCP_General
Operating system - IBM z/OS
For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - zSeries Software
Product - z/OS
Component - General
Operating system - IBM z/OS
Creating a new RFE based on Community RFE #55665 in product z/OS.