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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, October 14, 2016 9:31 AM
Subject: Re: ABO Automatic Binary Optimizer

On Fri, 14 Oct 2016 11:29:46 -0400, Farley, Peter x23353 wrote:

>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 with the message: INFO IBM-MAIN

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to with the message: INFO IBM-MAIN

Reply via email to