Scanning SYSOUT was actually an IBM plan prior to SMF. From my length article "The History of SMF' on the 20th Anniversary of SMF (http://www.mxg.com/newsletters) in Newsletter FIFTEEN (1989):
IBM'S MOTIVATION FOR DESIGNING SMF: 1. User need to account time and resource usage. 2. IBM's need to know about how the system was being used, especially about which IBM Programs were used how much/often. A "SYSOUT Project" had already been started inside IBM. Originally the idea was to solicit customers to submit their SYSOUT on tape, which would then be analyzed after the fact (for compiler messages, link editor, etc.) to count program usage! Barry Merrill -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bill Fairchild Sent: Thursday, December 01, 2011 7:16 AM To: [email protected] Subject: Re: Last use date of a PDS member What constitutes "using" a PDS member? When should a PDS member's access be audit-trailed? [1] The reason for some accesses seems to be more important "uses" than others. E.g., if a PDS member contains JCL and it is read for the purpose of starting an address space, constructing a job to be submitting into a JES, expanding a cataloged procedure, etc., then this would appeal to some users as justification for writing an SMF record, or at least putting the member name in a field in an SMF record. Likewise, using a macro or copy book at compile time seems a compelling "use" of the PDS member involved. At least the Assembler documents the use of such PDS members in the cross-references produced at the end of the SYSOUT for each Assembly. If such SYSOUTs were saved, then they could be scanned for particular macro names, and thus writing SMF records in this case would be redundant (although a saved SYSOUT takes a lot more storage space than a saved SMF record). Executable programs and pieces of programs are stored in PDS members, and their "use" typically involves an e! xecuting program, which might make this usage important enough to be documented. And object modules used in linking and building new executable modules should be given the same importance as the use of macros and copy books by compilers. But what about copying a PDS? Are its members being "used"? What about compressing a PDS in place, or compressing while copying elsewhere? The members are not really being used for any productive purpose, but probably in a housekeeping operation to reclaim unusable disk storage. Each member is not really being changed when it is copied, as the copy is logically identical to the original, but the metadata describing the entire member and the metadata surrounding each piece of the member are changed when its pieces are written to new disk locations. And metadata within the member's directory entry, as in the case of a load module, may change if the load module is copied to a new disk location. If a PDS member is deleted, has that member been "used"? When a member is deleted, often a large number of other members in the same PDS must have their metadata (directory entries) changed. Are these other members being then "used" when the directory is being updated to reflec! t the removal of one entry from its middle and all entries after that point must be shifted towards the front of the directory? Or is only the directory itself being "used" when the directory is compressed, expanded, or copied? What about an ISPF 3.14 scan of a vast library for all occurrences of a character string? Is this a use of each member? Maybe a member's access in which a string is found is important enough to document but not that of the members not containing that string. Yet all the members were accessed and thus "used", FSVO "use". Then there are SMP libraries. Oy vey. Each of these many different "uses" of a PDS member would require different logic placed in different system components to effect an audit trail, which would explain why there is no simple solution for logging any "use" of a PDS member. Bill Fairchild Rocket Software, Inc. [1] I believe this is the first time I have ever verbed a noun all on my own authority. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
