The intent of the question was NOT "I have this neat idea that I could 'improve' SMF records in the exit ..." Not at all. Here is the problem. Associates have an issue with a corrupted SMF record whose source was an IEFU8x exit. We see three possibilities:
- They stepped on it themselves somehow. This would seem to be the most likely possibility, but an inspection of the code comes up with nothing. - The IBM product cut a bad SMF record. Certainly a possibility, but seems very unlikely. - The thought emerged "what if an exit earlier in the IEFU8x chain stepped on it? Is that even possible?" FWIW my associates were guessing that each exit received a private copy of the record. (Not an outlandish idea IMHO. Many products do work that way.) My divining of the manual was that there was only one copy. I volunteered to ask here. I did give some thought to "would it ever make sense for an exit to modify an SMF record?" and the best I could come up with was "shops have done some amazing things over the years, and after a while they become set in concrete." The MVS doc indicates that a valid use for an IEFU83 exit would be to suppress certain SMF records, and suppressing a record is in a sense the ultimate modification. It does not seem to me to be big leap from, for example, "I will suppress this record" to "I will keep this record, but get rid of one triplet section." I submitted an RCF asking for a clarification. As always @Peter, thanks for your help. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, June 13, 2019 5:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What happens if an SMF exit modifies the SMF record? <snip> > due to security and integrity of the SMF records themselves, IBM is not talking much about it. Security by obscurity? </snip> No. These are updates by authorized programs. Neither security nor integrity is a factor. One ought to be asking for what reason an exit routine would update an SMF record. Can it? Sure. Should it? Usually not. Most programming interfaces (far from all, of course) are intended to be for read-only but only rarely is that explicitly stated. For example, without having done an exhaustive analysis, I'd guess that all the PI fields in the CVT other than CVTUSER are intended to be read-only. Probably one ought to go with "if it's not obvious that a field is intended to be written into, then don't write into it (or ask for the documentation to make it clear one way or another)" Long ago I had hoped to gain traction for indicating that a PI field was read-only vs read/write (such as placing that information within the external classification section of the macro prolog which in turn is used within the data areas books). Obviously that hope did not come to fruition. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
