On 8 October 2013 20:35, Charles Mills <charl...@mcn.org> wrote: > OTOH, I have not, and probably will not take the time to, run an experiment > to see if the assertion of most of the posters here is > correct: that a specified or implied permission in SMFPRMxx is a necessary > condition for writing SMF records of a particular type > number. > > I guess a well-behaved and "efficient" program would check SMFRTEST at > startup to avoid the overhead of constructing > unwanted SMF records, but if it did not, I now suspect it would be prevented > from writing them, and would in fact receive a > 36 (24) from SMF(E)WTM.
I dug out the customer complaint (from 2003) that provoked us to make code changes in one of our products: === Through SMF parm (SMFPRM00) we specifically code the system not to record SMF type nnn with subtype of "224 & 226". This is the result from <product>: <msgid> SMF WRITE FAILURE The Question is why should <product> care whether through system installation we suppressed certain smf subtypes or not? We believe this is a bug because it is clearly stated in "SMFEWTM or SMFWTM" macro that if the record was not written because the record type specified is not currently being recorded, the return code is 36. === We agreed with the customer. We had been treating any non-zero RC from SMFWTM as an error (with a not very informative generic message), so we changed our code to treat only some RCs as errors, and merely report in summary on others at product shutdown, e.g. "nnn SMF records were suppressed by SMF configuration", "nnn SMF records were suppressed by SMF installation exit", etc. But certainly back in 2003 this configuration caused RC 36 from SMFWTM. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
