Back in my banking days, we Sysprogs worked with OPs and APPs to create several Jobstreams to create a group of critical/typical transactions to exercise various applications (such as Loan Origination, ATM, Retail, and Financial, along with File Transfer, Statement Printing, etc.). These were used for any major changes, like Processor changes, Microcode, DASD changes, Channel changes, Printer mods (we had 3900 Duplex printers), OS changes, Middleware changes, and Application changes. These were used as a vehicle to exercise major components, and were a good indicator that a change appeared successful. If you've ever been through an Operational Audit, you know that the "process" must be in place for changes, and you must routinely exercise them. While all changes might not be subjected to this process, a robust Change Management process will determine the need, and will satisfy most auditors. Satisfying auditors is not really a SysProg daily job, but it is something often required. If your shop does not need such time consumers, consider yourself lucky. AFAIK, many industries still require these today.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Friday, October 14, 2016 9:31 AM To: [email protected] Subject: Re: ABO Automatic Binary Optimizer On Fri, 14 Oct 2016 11:29:46 -0400, Farley, Peter x23353 wrote: >Timothy, > >You missed two crucial issues: > >1. Auditors don't believe in "verification" and management requires audits to >pass. IT does not control auditors (quite the reverse in fact). And we lowly >programmers have no input to auditors at all. >2. There is no existing independent verification tool for a company to use on >ABO's output. And if someone creates one, it has to be from a company OTHER >than IBM so that IBM's ABO results are independently verifiable. > >"Smart" testing is of course a valid and desirable goal, but lacking an >existing *independent* verification tool there is no option but full >regression testing. Manual verification is not reasonable or cost effective, >especially for very large programs and program suites. > >And again, I am not trashing ABO, which on its face is an amazing tool BUT it >changes object code. Lacking independent automated verification, in any sane >definition of a program life cycle system that is a change that requires full >regression testing. > Do the above apply likewise to moving to a different processor model, or even to a microcode upgrade? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
