[Topic changed as this is more related to that new thread] There is of course a significant influence from what one is familiar with, but I also have plenty of experience of z/OS and ISPF. I started using TSO as a pre-university student at IBM in 1974 in the PL/I Optimiser team. The only conditional command provided with the CLIST language at the time was WHEN to test the return code, with no way of testing parameter values, so the first thing I did once I had learned how to write reentrant assembler was implement TSO commands to handle IF/THEN/ELSE logic in CLISTs, including nesting, which the Hursley TSO support team then put into production for the PL/I department a month after I joined IBM (although those commands disappeared later, probably when PL/I transferred away from Hursley). And I've used ISPF from when it was SPF, and I wrote software primarily for z/OS and its predecessors (including MFT, MVT, VS1, VS2 and MVS) for my entire career, even though for the last 37 I used VM/CMS as my primary working environment.
Of course you can invoke commands and macros in ISPF, and for code which is self-contained and written in REXX there is very little difference from CMS, but for a complex process like building a product I found it far easier to handle in CMS. You don't have to be aware of data set space allocations on CMS, nor whether a data set is already allocated. In CMS you can create a file in any format just by writing to it (as in Unix), and you can read records efficiently by record number, which for example makes it very simple to use a binary chop to locate a record in a sorted control file. CMS is also much more systematic about the way in which command output and messages are trapped, with fewer special cases. I also like the way that in CMS you have your own clean environment, so you aren't having to filter your own stuff out of all those other data sets, users and jobs running on the same system. CMS Pipelines is immensely powerful. Unix cannot compare. You can write a basic Pipelines HTTPS web server in about 30 lines. I helped to develop the VM Charlotte web browser, for which I rewrote the HTML formatting in systems programming C, which all runs as a CMS Pipeline. Within IBM, we also had TSO Pipelines, based on an earlier internal level of the same code, and I made heavy use of it in our MVS jobs, as it greatly simplified many tasks. IBM included a variant of that as BatchPipeWorks in BatchPipes but then sold that off to a vendor. If z/OS had TSO Pipelines at the same level as current CMS Pipelines, it would be a far more programmer-friendly environment. Our XEDIT environment had a COMPARE macro which skipped to the next difference, but for review purposes we used a diff-like tool "HIGHLITE" based on SUPERC (a Toolkit program owned and maintained by my HLASM team, and used by ISPF to implement SUPERCE and SRCHFOR) which browsed a listing in which blocks of deleted or replaced lines had a red background and added or replacement lines had a green background. The browse process was written in REXX using the FSX tool (I think that is another of Mike Cowlishaw's contributions) for full screen 3270 output, and to make it easy for users, the user interface emulated the IBM internal enhanced BROWSE command. I have some familiarity with the SUPERC code myself as I added the ASCII support in 2012, as well as other minor fixes. I very rarely needed to use CP TRACE but it requires minimal preparation and ensures that the debugging process was cleanly isolated from the program being debugged, and it is not limited to programs for which we had the source code. On a couple of occasions the "store into" trace helped me solve an overwrite very quickly. For source-level debugging we used ASMIDF, another Toolkit program owned and maintained by the HLASM team. Our build process created the ASMLANGX files, so we didn't need any special preparation to run HLASM under ASMIDF. Our process for trying a change to HLASM was basically to CREATE a private SFS directory for the fix, access it as file mode B (ahead of any previous uncommitted changes optionally accessed as C and the production level accessed as E), edit the relevant modules, save them in the fix directory, then build them. By default our build command built anything in the fix directory for all four platforms, but one could just build selected parts and could optionally specify the target platform CMS to skip building for the other three platforms. It's then one command to link for a given platform, then it's ready to run some assembly to test it. As the build process itself runs the assembler, there was some logic in there to make sure that the production level is used for the build, temporarily renaming any executable assembler module in the fix directory. The longest step of the build was dynamically creating the product internal MACLIB from the latest level (earliest visible level in the file mode sequence) of each macro, which was a few seconds if it hadn't been done recently (so the files were not in cache), then the actual assemblies ran at two or three per second. Of course with enough programming you can do most things on most platforms. But for example HLASM like its predecessors provides a documented command to invoke the assembler on CMS, but the equivalent TSO assembler prompter was dropped long ago and you have to use a script which works out naming conventions, allocates the appropriate files (creating new data sets if necessary, requiring guesses at appropriate space allocations) and then calls the assembler with the relevant options. Jonathan Scott -----Original Message----- From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf Of Jon Perryman Sent: 05 September 2025 02:02 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Using (0) to suppress alignment checks in HLASM On Thu, 4 Sep 2025 10:18:13 +0100, Jonathan Scott <jonathan.scott...@gmail.com> wrote: > I think any access would fall disappointingly far short of what I was used to. ... You need to look at ISPF because it's all there. SuperCE, SearchFOR, various languages (e.g. HLASM), copy, dataset list, member list and much more. IBM provides scripts to HLASM interactively or batch. For beginners, they can be accessed through menus.
