The call to SMFRTEST is my code. It is certainly possible I have some routine
Insectus programmaticus, but the code works elsewhere apparently correctly, and
on our test systems returns correct results for a variety (about 20) of SMF
record types. The assembler code is called from C. The assembler code
blank-pads the subsystem name, loads the record type, and issues SMFRTEST
RECTYPE=(R2),SUBSYS=(R6), returning R15 to the C code without inspection or
modification. I can trace the return code in C immediately upon return.
I do not yet have the results of the storage display suggested in the APAR.
I don't have a machine-readable SMFPRMxx from the customer, only a partial
screenshot. I see SYS(NOTYPE(14,16:19,62,63,65:69,99),... I have a D SMF,O from
the customer:
SUBSYS(STC,NOTYPE(14,16:19,62,63,65:69,99)) -- SYS
SYS(NOTYPE(14,16:19,62,63,65:69,99)) -- PARMLIB
The fact also seems to be that 17's are not being produced.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Elardus Engelbrecht
Sent: Wednesday, July 22, 2015 12:00 PM
To: [email protected]
Subject: Re: SMFRTEST return code errors
Charles Mills wrote:
>At a customer, I am apparently seeing SMFRTEST return code zero for type 17
>'SYS ' even though D SMF,O clearly shows that Type 17 is not enabled.
Sniffffff, it is smelling bad, like rotten eggs.... I'm smelling some weird
exits....
Can you see how SMFRTEST is called? With what SUBTYPE and SUBSYS parameters?
Yes, I see 'SYS ', but....
On what z/OS version do you see that anomaly?
Do you see if IEEMB838 is front-ended or not?
Please post the SMFPRMxx if you can.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
