John McKown wrote: >But the problem could well be the fact that getting the >new COBOL is an immediate, definite, increase in the budget >numbers....
And how would *that* happen? If that happens, I don't think it's due to IBM. If you're thinking of per MSU charge variations between versions, they're gone.(*) IBM abolished those several years ago. What's IBM-MAIN's statute of limitations on IBM's past practices? :-) (**) >whereas the projected_(not assured) savings from a decrease >in MSU charges is a_future savings which may OR MAY NOT >occur. Or projected additional workload volumes supported within the same capacity, if you prefer. You can "spend" greater efficiencies however you and your employer wish. >Also, there is the expense of testing that the newly compiled >programs still work correctly. Yes, but: (a) One always tests, especially (but not only, hopefully) when there's a change; (b) Thus one perfectly reasonable approach -- the approach we often recommend -- is to recompile only programs that change during the normal course of business driven code changes and to test through those ordinary development cycles per normal. (Does *anybody* recompile *every* program after they upgrade a compiler? It's uncommon, at least.) Of course one could always try arguing in favor of absolute inertia, but your organization isn't choosing inertia, is it? I don't recommend arguing in favor of inertia particularly when the business isn't willing to stand still. (Not blaming you, John.) >I'm not trying to argue against upgrading. After presenting only a simulation of an argument? :-) :-) Look, I'm all in favor of discussing and debating well considered arguments based on current facts, figuring out ways IBM might do even better. That's not yet happening in this thread. I continue to share John Gilmore's frustration. :-( We're rehashing resolved, debunked, and/or imagined problems. This really isn't productive. What would be at least more productive is evaluating the new compiler and upgrading your compiler as reasonably quickly as you can. (*) It can be even better than that. Enterprise COBOL Version 5 *automatically* generates SMF Type 89 records for sub-capacity license reporting. Previous COBOL compiler versions didn't, and you had to perform a manual configuration step to make sure your sub-capacity reports correctly reflected your compiler usage. If you skipped that step, IBM probably billed your COBOL compiler at full capacity. My sincere thanks to you if IBM did so. When you upgrade, the new compiler protects against your making that particular error of omission. (**) Answering my own question, often at least decades. But be careful what you wish for! You might encourage IBM not to respond favorably to customer concerns, even well justified concerns. If you think IBM still hasn't fixed something it has already well fixed, even many years ago, then why should IBM ever fix anything? :-) -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
