Timothy, I see your point. But the problem could well be the fact that getting the new COBOL is an immediate, definite, increase in the budget numbers whereas the _projected_ (not assured) savings from a decrease in MSU charges is a _future_ savings which may OR MAY NOT occur. Also, there is the expense of testing that the newly compiled programs still work correctly. And the cost of fixing possible "problems". This last latter happened to us. A "clever" programmer found a bug in the COBOL compiler (VS COBOL II) and took advantage of it. I put on a PTF which fixed this bug. But, in the interim, that "clever hack" had made its way into about 10 programs. The next time they were compiled, the compiler complained. I got a number of complaints about "but it always worked before". Regardless of who was "right" or "wrong", the fact remained that the change in the compiler increased the programmers' work load to "fix" this "clever hack". So applying the PTF cost the company money.
I'm not trying to argue against upgrading. Honestly, to me, it doesn't matter because the z is going away mid-2016 as scheduled, and me along with it. But many shops, especially smaller ones, are very sensitive to the slightest change in budgets. And, again going with how it was here, spending $1 today to save $5 next month was generally a hard sell. Especially if you phrase it honestly as "may save up to $5 next month". The costs are immediate and definite. The savings are future and not guaranteed. Your last sentence is our solution: "Or outsource, ..." On Wed, Oct 21, 2015 at 1:58 AM, Timothy Sipples <[email protected]> wrote: > Greg, thank you for acknowledging that IBM apparently neatly addressed your > concern with Option #1: IBM Program Number 5655-TRY. ("Operators are > standing by....") However, I think you misunderstood or didn't appreciate > the "So what!" point I made. I'll spend a few more words elaborating on > what I think is an irrational "fear of the SVC." > > "So what!" if your monthly charge for your COBOL compiler (only) increases > (*) when the highly likely outcome is.... > > ....Your monthly z/OS charge decreases; > ....Your monthly CICS TS charge decreases; > ....Your monthly DB2 charge decreases; > ....Your monthly MQ charge decreases; > ....Your monthly IMS charge decreases; > ....Your monthly (whatever else) charge decreases; > ....You defer the charges associated with your next capacity upgrade; > ....And you enjoy the new compiler's new functions. > > Factors in computing or in economics should not be considered in isolation, > or otherwise you've completely lost the plot.(**) > > (*) There's yet another option if you somehow get past the three > reasonable, viable options I outlined previously. Let's suppose you're > getting near the end of your SVC period, you've recompiled some of your > COBOL programs but not all of them, and you've picked up some nice > performance benefits with the new compiler across the programs you've > recompiled, hopefully including at least the "heavy hitters" that most > greatly influence your peak utilization. You could then decide to cancel > your Enterprise COBOL Version 5 license (and delete the product), switching > back solely to your Enterprise COBOL Version 4 license. I'm NOT > recommending that, but that's one choice. The programs you already > recompiled with Enterprise COBOL Version 5 continue to yield their > performance benefits indefinitely unless and until you recompile them again > with the older compiler. You are certainly not required to recompile them > unless and until there is a code change. > > (**) It is bureaucratically possible for "Department A" to have > responsibility for your COBOL compiler's licensing budget and "Department > Z" to have responsibility for, say, your z/OS licensing budget. (And maybe > "Department C" for CICS, "Department D" for DB2....) But if your > organization can't figure out how to exploit this sort of compiler value > when it arrives on your doorstep.... Well, I'm hard pressed to think of > anything *IBM* can do to fix your employer's dysfunction that IBM hasn't > done already. You'll simply have to fix yourselves if I've just described > your organization's (mis)behavior. Or perish. Or outsource, a common > corporate reaction when this sort of bureaucratic insanity festers. > > > -------------------------------------------------------------------------------------------------------- > 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 > -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
