That's actually not crazy, and matches what Tripwire and friends do IIRC. As opposed to a long-ago QA person who would compare each file from each release and demand explanations for each new or changed file. Since this was VM and the products included source code, the conversation would go like this:
"What about this one?" "That's a source change. Just like the next 27 files." "OK, then what about this one?" "That's the AUX file that lists those changes." "OK, then what about this one?" "That's the executable that was built from the source code we just discussed." After spending an hour on this once, I explained to my VP that I wasn't going to do it again, as it wasn't adding any value. I had an automated system that notified me of files changed/added in the release, and would examine those myself to be sure nothing was obviously borked. Fortunately for all involved, he agreed with me. On Sat, Dec 8, 2018 at 8:58 PM Jeremy Nicoll <jn.ls.mfrm...@letterboxes.org> wrote: > On Sat, 8 Dec 2018, at 19:28, Paul Gilmartin wrote: > > > "ZAP" is a key word. How does one guarantee that any program in any > language > > hasn't been ZAPped after passing audit? > > Twenty years or so ago the bank I worked at ran an audit tool which stored > a hash or checksum of every loadmodule, and each time the tool was run > someone had to sign-off each such detected change. > > > > https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf > > Sneaky! > > > -- > Jeremy Nicoll - my opinions are my own. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- zMan -- "I've got a mainframe and I'm not afraid to use it" ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
