"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 

J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office

-----Original Message-----
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 
time soon.

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

Reply via email to