Great post, Jonathan. I assume you've heard that VM is doing away with CMS UPDATEs as the service methodology because of git? That makes me sad. I am 100% sure that there will be lost history when things get migrated etc. due to doing file replacement rather than updates. And that's not A Good Thing. I have base source (and update) files from the 1980s that I still use, with 1980s timestamps on the files!
-----Original Message----- From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf Of Jonathan Scott Sent: Thursday, September 4, 2025 3:46 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: HLASM and VM/CMS (was RE: Using (0) to suppress alignment checks in HLASM) During my 37 years at IBM, mainly developing CICS, MQ and HLASM, I always used VM/CMS as my editing and development environment, and sometimes even initially tested bits of product code for CICS or MQ in isolation under CMS, for example to verify algorithms. That included the AXM authorized cross-memory server run-time environment which I wrote in the 1990s (in assembler) to support the CICS coupling facility data sharing servers. When built for testing under CMS, conditional assembly logic (mostly using OPSYN) ensured that the cross-memory z/OS stuff was temporarily dummy, allowing testing of much of the infrastructure in a CMS environment. I packaged the XEDIT development environment which I created for CICS (DEVPROF PACKAGE) for the VM download library in the 1990s and I had permission to make it available externally, but then I spotted some stuff tied to local conventions that should be made more customizable, but I never found a neat solution and it would need the user to modify the code. I still have a copy of that package which I could in theory use I should ever return to VM in future. But I also used hundreds of other tools, which remain IBM internal. The 3270 keyboard can be remapped statically using PCOMM keyboard mappings or equivalent. I created my own mapping which I shared with my team. The main purpose was to use the Return key for Enter and Shift-Return for Newline. However, it also included extras, such as additional alternate mappings of the keypad for PF keys and for entering box and arrow characters from the keyboard for quick "WYSIWYG" creation of character graphics diagrams. I handed over some of my other team tools to other IBMers when I retired. One of my most recent contributions was a CMS tool to convert any BookManager book to HTML (including graphics and images, converted to GIF or BMP, and hyperlinks as in the original book) which has proved very useful for making old BookManager-only books readable without special software. It uses some code from my 1990s DOCTOPIC tool, which was an unofficial VM bookserver, and it needs BookManager READ on the converting system, plus GDDM for converting GDDM graphics to GIF. The generated HTML is a bit quick and dirty as a result of merging different tools (for example some tags are in upper case and others are in lower case) but the visual effect is good. It includes REXX code to convert PSEG3820 to bitmap (BMP or via GDDM GDF format to GIF) which was a lot simpler than I had expected once I found the right specifications. It would be good if tools like that could be made available externally, but I doubt whether my successors have sufficient interest in CMS to get round to it. Another recent tool was a command to look up URLs of older books in the IBM Publications Center. The IBM search front end web site was "sunset" unexpectedly (perhaps the owner retired) but the books are still there without any official method of finding them (including some documentation for old but still supported products which are not in IBM Docs). My PUBSLIST tool uses a local index file (based on a spreadsheet of recent contents plus lists from the old Online Library catalog) of about 8.5MB which lists 76502 books (and that's only the English language subset of the original index). After retiring I've ported the REXX tool from CMS to Object Rexx on Windows (replacing CMS Pipelines with stream I/O) so I can still use it. One of the reasons I retired from IBM (at 69) was that my HLASM team was under increasing pressure to move off VM/CMS, even though it is the ideal platform for HLASM development and we have a huge set of tools that has evolved over the decades, including extensive automated testing aids. HLASM and Toolkit programs (such as SUPERC and ASMIDF) still have to support CMS in ESA/390 mode (or the newer ESA/390 compatibility mode) for the supported lifetime of the current release 1.6, as we cannot change prerequisites within a release, and testing on that platform in ESA/390 mode ensures that we haven't accidentally used any newer instructions on any path in the common code (although we can in the interfaces to z/OS and to 64-bit Linux). Managers were worried that it would be difficult to find future developers who would be familiar with VM/CMS, but that seems irrelevant to me. Firstly, the developers would need to get familiar anyway to support HLASM, as CMS is a supported platform, and secondly I think VM/CMS is quite easy and interesting to learn (and over the years I've seen many newcomers learn to use it). It's also much more programmer-friendly environment than z/OS, providing a safe private virtual mainframe where almost anything can be automated by capturing command output. z/VM is of course a fully supported operating system which IBM has clearly said is "not going away", although some aspects are a bit behind the times, for example relating to network authorization protocols. Other aspects are way ahead of most other systems, in particular CMS Pipelines, which often made it possible for me to do things just on the command line which would have taken hours of programming otherwise, and to write little tools in a few minutes which replaced and extended old tools consisting of thousands of lines of code. I presume the main pressure to move HLASM off VM/CMS is related to US government requirements relating to secure development environments, where the approved IBM solution is GitHub. However, that's several conversions and copying processes away from the list of CMS SFS directories from which we can actually compile changed code on CMS or z/OS. Our VM/CMS development environment had always been an informal environment for quick experiments, debugging and prototyping, and all formal updates are done by copying the provisional updates into an official (but much clunkier) VM-based development and support repository as APAR changes where they are built, tested, reviewed and packaged as PTFs for shipping. So it makes sense for the official repository at least to be replaced with something more secure yet still capable of building and packaging for the four supported HLASM platforms (z/OS, z/VM, z/VSE or VSEn, and Linux), but setting that up was going to take a huge amount of work and expertise in many unfamiliar tools, especially as IBM no longer has any significant expertise in the old VM-based build environment. I'm perfectly happy to learn new stuff when it's clearly documented (such as the PSEG3820 and BMP formats), but a lot of this build stuff isn't, and the experts are of course too busy to help very much. So, I've decided to be an old dog who isn't interested in learning new tricks, and I've left that migration as a problem for my successors to solve. (I suspect it may divert resources from enhancing HLASM itself for some time to come, so things may go very quiet for a while). I did however improve code page support in HLASM to make it easier to use ASCII or UTF-8 repositories for assembler source (at least for EBCDIC SBCS source). This means for example that EBCDIC SBCS source modules for different HLASM European national language messages, currently in different code pages, could in future be all stored in a common code page (1047 in EBCDIC or 819 in ASCII), allowing them all to be viewed and edited using that EBCDIC terminal code page, and avoiding the need to use module-specific code pages when converting to or from ASCII or UTF-8. The character constants then could be converted at compile time to the original national code page using the CE option (which means building with a sufficiently recent level of HLASM to support that option). Of course, IBM policy seems to be that for any future product releases most of the national language message support will be dropped anyway, but HLASM has been on release 1.6 with a stream of new hardware support and other significant enhancements through service since 2008 and I assume that will continue for now.
