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
