"Happy families are all alike; every unhappy family is unhappy in its own way."
While Wikipedia calls it the Anna Karenina Principle, it's not quite enough to
substantiate the Russian claim that Tolstoy invented great literature. It's
still a vital lesson.
I would venture that there so many ways to screw up a COBOL program that no
software mechanism could possible catch all of them, let alone correct them.
Like a medieval cathedral that took generations to build, a 'classic' COBOL
program has evolved through many cosmetic surgeries performed by many different
hands with many different attitudes. Some scars are superficial. Some are
systemic. The best news is that not all programs need to be converted at once.
Go for the low hanging fruit; the biggest, sweetest ones that will feed the
most mouths. Leave the rest for gleaners. There is no need to wait for a grand
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bill Woodger
Sent: Tuesday, October 18, 2016 2:20 AM
Subject: (External):Re: ABO Automatic Binary Optimizer
We continue to add things to the bubbling pot that is a discussion started
through the misunderstanding of some IBM sales staff.
Tom Ross ventured close, dipped a spoon in the pot, and confirmed that there is
no "source conversion" process for migration to V5/V6. Mmmm... he's either
writing something very substantial, or he ain't coming back to this pot any
Sure, delivery needs to be addressed.
But. COBOL isn't Java.
While a COBOL program is able to overwrite itself, or another program (there
are limits, it can't trash storage it has no access to), you can't compare
testing processes for COBOL to Java.
The generous levels of programmer-hand-holding in Java (and other "more modern"
languages) don't exist beyond a bit of a shadow, or mist, or the intellectual
satisfaction of "hah! Xyz! So that proves you wrong!".
I'm prepared to bet, and it is an entirely case to measure, or resolve, so even
betting is useless, that around the world in, say, for every 10,000 Mainframe
sites that there are at least 20,000 times a day, unique occasions, not the
same storage, that storage is overwritten in Production COBOL systems. It
happens "so often" because most often when it happens "it doesn't matter".
By "doesn't matter" I mean that the program completes normally, and all the
test cases are passed, and all Production data is correctly processed.
Actually, can't be definitive about that latter, wihch is the most important
thing. If nothing else, the unintntional partial destruction of a program is at
least a "symptom" of "something".
OK, arriving at the Door to Production (I've never known of it referred to as
that, but what the heck?). You have one of these systems, and it has passed all
the tests. You change a compile option which affects the generation of code,
which means that what was being overwritten with impunity previuously is now
safe, but something which actually matters after the overwiring has occured has
now been... altered. Uunthinkingly, you toss it into Production.
The 10am presentation in the Board Room is arranged, you have people from the
US and Asia who flying in, and out again, specially.
You know what is going to happen.
So what do you do in that situation? It's been through all the tests, and then
it gets vommited out on its introduction to Production. Explain that away. As
soon as you get to "and we did this...", whatever "this" is, anyone but the
village idiot is going to ask "why did you do that" (referring to the "this",
of course). Oh, and it much, much, worse if, instead of vomitting, there is
mild nausea which goes undiscovered for a period of time.
So you don't just change compiler options, or the order of INCLUDEs in a
linkedit deck (indeed, as Peter pointed out earlier, many sites push
executables up the line, rather than recreating them at each stage).
20,000 only seems a lot in isolation (and it is an entirely invented figure,
just to have a figure), it is tiny amongst the total, and the times that
something turns from an innocuous to a vicious situation are tiny in comparison
to 20,000. But it happens.
If you do just up and change a compile option, you have invalidated your
testing. If you are going to go with it anyway (it wasn't my hypotherical
scenario) then the risk in terms of possibility is very small, but in terms of
potential impact may be immense. So, as well as going forward, you do what you
can to be as sure as possible that the health of the system will be unimpeded.
Do you feel happy yourself? No, you want to find out how you were strung up in
that situation, and do what you can to make sure it can't, ever, happen again.
On the other side of the hill, an expression I use because I like it, not
because of its confrontational connotations, there are "edge cases". An
edge-case is something that's unlikely to happen, so you don't have to bother
about it until it does happen. There are also "corner cases". A corner-case is
a situation which is unlikely to happen, and even if it does you are not going
to bother about it.
You don't bother so much about getting the technical details right, because
usually (or at least in expectation) the language will do something to assist
you. "Line 3491 array out of bounds". Which is nices, but which underlying code
operates 24 hours a day, 365 days a year (plus leap seconds, days) whilst
99.999999% of the time it is unnecessary to have it checked automatically.
In passing, I hope no-one replies to this, else the topice gets even more
convoluted, wide-ranging and unresolved.
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN