<"The problem with CMS as an application platform isn't the compilers. As
<others have noted, that's easily and [relatively] cheaply solved. The <problem is that application developers use compilers as a means to an end, <not an end in themselves. Business application programmers want to write <web-enabled apps and services for UIs and database access. They want <WebSphere, WAS, DB2/UDB, Oracle, and WebLogic. They want to write RESTful <applications. They want to write in Java. And, of course, they don't <want just some minimal core level of function, they want the whole <enchilada." True, Alan, But every time such middleware application development goes on it directly triggers COBOL changes in the COBOL mainframe back end. I just did such COBOL mainframe application development changes for a client the first 6 months of this year. There is no reason the application developers at this client could not have used CMS instead of TSO/ISPF if COBOL had been available on it. At least, it would have saved the client, which was out-sourced to IBM Dallas, enough CPU time so that they did not have to shutdown the DEV LPARs for days at every month end to run PROD because they did not have enough CPU. Not exactly a Six Sigma process. I rode out the Wall St melt down at a large NY Investment Bank which had tons of UI's with the latest and greatest of every imaginable middleware offering available. It was all GUI, no *green screen* to be seen any where. But that was about all the middleware frontend did, GUI, no real processing. For any real processing, it all still had to go through the billions of lines of COBOL code in the back end to get to the data in the 44 CICS/DB2 applications which really ran everything, contrary to senior management's perception. Every time there was a change to the middleware software it triggered a change to the COBOL code in the back end. If this company had done its COBOL support under CMS instead of TSO/ISPF it would have saved not just millions, but billions. How much client savings does it take to justify a business case? Let's face it. COBOL is here to stay whether clients realize and want it or not. But IBM had better realize it. That the client's mainframe COBOL back end is never going away however much they delude themselves, put lipstick on the pig. So here's the business case: Optimize CPU time by moving COBOL maintenance from TSO/ISPF to CMS. Contrary to what some may say, I do not believe IBM intentionally introduces software inefficiencies to sell more hardware. But unless things change, that is exactly what is happening in the *real* world. COBOL is here to stay, like it or not, so why not optimize the process, especially when doing so is a problem "easily and [relatively] cheaply solved"? Alan Altmark <alan_altm...@us.ibm.com> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 12/13/2010 03:38 PM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Mandatory ESMs? On Monday, 12/13/2010 at 09:41 EST, George Henke/NYLIC <george_he...@newyorklife.com> wrote: > I'm just grateful z/VM is still alive and well and getting stronger and better > every day especially with the advent of the z196 and that it is only a question > of time before the compiler issue will be addressed. Not likely, George. The problem with CMS as an application platform isn't the compilers. As others have noted, that's easily and [relatively] cheaply solved. The problem is that application developers use compilers as a means to an end, not an end in themselves. Business application programmers want to write web-enabled apps and services for UIs and database access. They want WebSphere, WAS, DB2/UDB, Oracle, and WebLogic. They want to write RESTful applications. They want to write in Java. And, of course, they don't want just some minimal core level of function, they want the whole enchilada. And in case it's not evident, business cases for compilers are developed around *business* application development, not systems management. Firstly, companies don't *want* to write their own systems management software - they want to buy it. Secondly, the number of people wanting to write their own systems management software on CMS is vanishingly small. So to have a viable business, you have to have enough demand to drive significant revenue. I say "significant" because there are lots of places IBM can invest. Should it invest those resources in something that returns a small profit, or large? (Note: I'm a stockholder, so I'm biased.) Those who are in the *business* of CMS-based [systems] software development might *prefer* COBOL or PL/I, sure, but they know what languages are available to them and they have to decide whether the market conditions and the availability of "development infrastructure" are sufficient to meet their business goals. In IT, as in almost all walks of life, it is unfortunate yet true that that the wishes of the Few or the One are ignored in favor of the wishes of the many. You will see that z/VM continues to invest in its native back-end System Management APIs and in the CIM "lowware" that pushes on them in order to free the systems management software from *having* to run ON CMS. Ultimately being able to manage system configuration, virtual machine provisioning, real resource provisioning, operation, event management, accounting, security, DR and HA, all from modern front-ends UIs with their own scriptable CLIs. As you suggest, this is all part of the appeal of zEnterprise. By the way, none of the above in any way denies the acknowledged inherent coolness of CMS. It's a simple and fast operating system; it's "single userness" eliminating huge amounts of complexity. Of course, we make up for that by having invented SFS and BFS, reintroducing some of that complexity. :-) It is a two-edged sword! Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
