Learning about Systems Assembler programming

WilliamDownie · New User Joined: 01 Jul 2020 Posts: 21 Location: UK

Hello,

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.

Thanks

steve-myers · Posted: Mon Jul 20, 2020 9:03 pm

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.

Gary Adair · New User Joined: 31 Oct 2013 Posts: 2 Location: USA

Back when I was doing dynamic allocations, 10 plus years ago, you needed to have Protect Key 0 and Supervisor State to change the DCB before executing the DYNALLOC. That is why it is an Authorized Service.

steve-myers · Posted: Mon Aug 31, 2020 6:21 pm

Bulls****. I have been using MVS dynamic allocation and before that the MVT IKJDAIR service, which called some form of dynamic allocation. In all that time, never once did I change to key 0. The only change to the DCB is to copy a system determined DD name to the DCB after completing the allocation, or to copy a DD name to dynamic allocation data before using allocation to unallocate a DD.

Gary Adair · New User Joined: 31 Oct 2013 Posts: 2 Location: USA

No need for the bulls*** comment sir, not appreciated. I am saying what I had to do many times in order for application programs to modify the DCB and use DYNALLOC. If not it would abend with a S0C4 Protection Exception.

steve-myers · Posted: Tue Sep 01, 2020 4:53 pm

In most application programs the DCB is in user key storage. You do not need to be in key 0 to alter it. Period. End of story.

I grant that I had one user key program that wanted to alter the DEB to simulate dynamic allocation. Foolish. This was in VS2 Release 1 (SVS). That program had to go to key 0. I have user key programs to look at the LINKLIB DCB, but just to look, not alter. I still have programs that look at JOBLIB and TASKLIB DCBs. Just look, not alter. TASKLIB DCBs should be user key. I honestly do not know about JOBLIB DCBs.

Real system programmers do every thing possible to run in user key, and only go to privilege state when absolutely required. It is much safer that way.