David Crayford wrote:
>Good point well made.

Thanks, David.

For the record, Amazon.com (the commerce site and associated commerce
services) reportedly consists of a *mix* of programming languages: Java, C,
C++, Perl, Ruby (on Rails), and Javascript. All of these programming
languages are available for IBM z Systems, by the way. Is COBOL "different"
from a testing and deployment lifecycle point of view? No, absolutely not
-- I again strongly disagree. If anything, C (for example) is much more
difficult to test well. Javascript isn't even compiled.

I hope nobody is testing the Employee Cafeteria Menu application and the
Billion Dollar Payments application using the same testing effort and
procedures, even if both applications happen to be written in COBOL and run
on the same machine. That testing equivalence would be nuts.

Adapt or die, folks. Yes, I know some of you occasionally face irrationally
rigid people who celebrate process for process sake, with little or no
awareness of real world outcomes and actual business risks. Some of them
are auditors. That doesn't mean we should agree with such irrational

Back to ABO. ABO and Enterprise COBOL Version 6 have clear benefits. They
can help you reduce your peak monthly utilization, shorten CPU-bound batch
execution times, and improve the performance of latency sensitive
transactions. Those benefits translate directly into financial and other
valuable business benefits. Exactly how much benefit you can get is
situational, but you can figure that out pretty easily (and without your
purchasing department having to do anything). You and your employer have a
choice, and so do your competitors. You can postpone adopting these
technologies until 2038 because you've got a "one size all" testing
program, that's your process (gosh darn it), and any "new" (not new!)
thinking is intolerable. That's one option, an expensive one. Or you can
apply some rationality, discuss appropriate testing scope and methodologies
with IBM, verify that these technologies work and work well starting with
your low risk programs, and enjoy the benefits much sooner. I vote for this
second approach. It's reasonable, rational, logical, informed, and based on
sound risk mitigation and outcome-oriented principles.

Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to