LE has been kept up to date, as have things like the binder to support functions like MPROUTE which were also ported from z/OS. This makes acquiring and maintaining things like this so much easier.
I'm a long time CMS fan. In an earlier life we had a lot of complex apps centered on SQL/DS including an online credit union system. Our MIS that supported our VSE-based homegrown OLTP was written using SQL/DS, Rexx, a 3270 Rexx interface (that could also drive the CMS GUI), and PL/I. We had a homegrown Dirmaint also built using SQL/DS and Rexx. When PL/I stopped being enhanced around 1996 we knew the writing was on the wall. I'm particularly proud of our Rexx fullscreen tool that allowed you to drive the 3270 (either your CMS console, a dialed device or CMS GUI) using Rexx variables (e.g. If you had a field on the screen called Surname then to change its color the simply say colour_surname = 'RED' or its protection attribute the prot_surname='Y'). It supported multiple windows and so on. The syntax was straightforward unlike DMS and it had a very small footprint. It also allowed me to learn a lot about LE, PIPI and enclaves. However, I know building apps based around logging on to a 3270 and the need to integrate with things like XML parsers like xerces mean that as an app hosting environment CMS's best day are behind it and that other than for nostalgic reasons (and the discipline to extract maximum function from a minimum if resources) I'm okay with it. All those systems are gone now as, after a takeover, TPTB decided the Alpha and Itanium were the way of the future and 30+ years of collaboration with IBM and 25+ years of VM ceased to be. Another couple of years later I think Linux would have complemented if nit supplanted our VSE systems, but it was not to be. I'm glad I left when the systems were in their prime and I didn't have to decommission our A$GREY, B$BLUE, C$BROWN and D$GREEN VM systems (they had those names for years and before they were LPARs, IBM used to supply the processors in those colours. It must be Friday and I must be getting old to indulge in such nostalgia. Time for a drink or ten. On Dec 10, 2010, at 18:41, "George Henke/NYLIC" <[email protected]<mailto:[email protected]>> wrote: z/VM has LE ported over from z/OS. So things cannot be all that bad in the world of CMS compilers. "I have heard people rant and rave and bellow That we're done and we might as well be dead But I'm only a cockeyed optimist And I can't get it into my head" Oscar Hammerstein David Boyes <[email protected]<mailto:[email protected]>> Sent by: The IBM z/VM Operating System <[email protected]<mailto:[email protected]>> 12/10/2010 05:34 PM Please respond to The IBM z/VM Operating System <[email protected]<mailto:[email protected]>> To [email protected]<mailto:[email protected]> cc Subject Re: Mandatory ESMs? > GCC for CMS [snip] Building a non-trivial program that involves existing libraries or code that must access things like CSL services is pretty hard to do with the CMS GCC port. It's a good tool for writing apps totally from scratch, but it's not something yet that I would rely on for really large mission-critical applications. The generated code is still very conservative in the instructions it uses and what machine functions it can/does exploit, to it's detriment. I'm concerned that there's no Enterprise COBOL, no more development on FORTRAN, no up to date PL/1… etc, etc. The IBM C/C++ compiler is still maintained and current, but only because it's necessary for CP development. You can't order CMS VSAM any longer, so there's no direct access file capability from the old compilers without directly interfacing to assembler yourself. Nothing's been touched in SQL/DS for VM for ages now. TSM is gone. 2/3 of the function of DFSMS/VM is pretty much gutted in terms of usability or functionality. ISPF/VM is ancient, and pretty much no longer maintained in any real sense (a lot has happened in ISPF since 3.2). No Java since 1.3 (although that's no real loss, IMHO). APL2 is frozen in time. Pascal is frozen in time (and only still exists to service the bits of the VM TCP stack that aren't in C or assembler). Ditto RXSQL. Ditto Kerberos (the shipped K4 is nothing you'd want to build new apps on). Interactive Debugger? DMS/CMS? All pretty much in a zombie state. OpenVM? Not much to see there either — although we finally have some reason for BFS to exist with the new SSL server (not that it's all that much fun to use). You're pretty much left with assembler, C, C++, XEDIT, REXX and CMS Pipelines as the supported application development languages on CMS. That's a pretty powerful set of tooling by itself, but if you're trying to preflight applications and do development in the CMS world that is intended for other places and other uses, that's not much. 3 out of 6 aren't widely portable outside VM at all, and the other 3 are restricted to a small number of interfaces with a tiny subset of their function on other platforms. The writing is pretty much on the wall. I know the reason why, but it's still sad. -- db
