Yes and no, George. Yes, CMS has LE ported over to CMS, but other than for C/C++ IBM has made the decision not to port the modern z/OS compilers (PL/I and COBOL). I was told several years ago by one of the PL/I developers that they actually had the compiler running under CMS, butt hey had no business case to release it to customers. They could not justify the time and expense of testing, documentation, support, etc.
So it's not a technical question, it's building a business case. DJ On 12/10/2010 05:41 PM, George Henke/NYLIC 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]> > Sent by: The IBM z/VM Operating System <[email protected]> > 12/10/2010 05:34 PM > Please respond to > The IBM z/VM Operating System <[email protected]> > > > To > [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 > > -- Dave Jones V/Soft Software www.vsoft-software.com Houston, TX 281.578.7544
