I've been coding Assembler for several years now as an application programmer. At the moment I have some time and access to a mainframe (the IBM MtM machine) and would like to try some of the facilities an Assembler systems program would use. This is to give me a broader understanding of what Assembler can do.
I was wondering if anyone could give any pointers on what would be useful to learn and if there are any good resources on the internet or books on the subject. Note, I don't have access to a transaction manager such as CICS.
I've got a book called "Advanced Assembler Language and MVS interfaces" written by Carmine Cannatello and this has chapters on Supervisor Services and on Cross Memory Services, both of which look like something I'd like to understand better.
Joined: 30 Nov 2013 Posts: 843 Location: The Universe
Cross memory services are something that Assembler programmers rarely exercise. I only wrote - from scratch - one cross memory application, and that was some 40 years ago and was rather limited. These days a different approach would be used, one not possible then as the hardware (and software) didn't support what is now called cross memory services.
There are five huge manuals - MVS Programming: Authorized Assembler Services Guide, z/OS MVS Programming: Authorized Assembler Reference ALE - DYN, z/OS MVS Programming: Authorized Assembler Reference EDT - IXG, z/OS MVS Programming: Authorized Assembler Reference LLA-SDU, and z/OS MVS Programming: Authorized Assembler Reference SET - WTO. You'll hit the Guide manual pretty hard, as it is the primary description of dynamic allocation, and cherry pick from the other four as required.
At least 90% - probably more - of dynamic allocation can be exercised by anyone in any program. I never understood why it was placed as an "authorized" service, but there it is. The little piece that is "authorized" is not really marked out in the text.
Back in the days when I did product support for an ISV - never mind the product or ISV, we had one product that utilized the data in virtual piece of cross memory services. I got to understand the programming aspects of accessing the data in its data space, but, in part because we never had any trouble with that piece of the product, I never understood how to prepare the application to connect a "data space" to a VSAM Linear Data Set. To this day I think of it as some sort of voodoo exercise! One detail the ISV never adequately communicated to its customers (or for that matter to us grunts that supported the product) is that Data in Virtual amounts to a weird sort of BDAM data set in storage that uses what amounts to MVS paging services to read data from the LDS, but you have to explicitly write altered pages back to the LDS. When you use multiple gigabyte LDS data sets (as our product did then, and I presume it still does) it amounts to a multiple gigabyte storage requirement! In the 1990s and early 2000s this kind of real storage was kind of unusual. I understand that DB2 uses Linear Data sets, but I don't think it uses the Data in Virtual piece.