IBM Mainframe Forum

Over in the Cobol section a user asked what does this AMODE and RMODE business mean? A similar query can be made for us Assembler programmers: what do I have to do differently to make my program AMODE 31, or AMODE 31, RMODE ANY?

Let's take a look at a minimal data set copy program.One of the changes is already hinted at in the code. Many data areas in OS/360 specified an address as 24 bits, and used the remaining 8 bits of the 32-bit word for other purposes. The I/O data areas such as the DCB and the parameter lists for the data set open and close services are particularly nasty in this regard. A beginner, with no knowledge of the history of z/OS may question why this was done.

The answer is that old problem: storage. In 1964 and 1965, when OS/360 was designed and implemented, storage was very expensive. One byte of storage cost roughly one US dollar. The dreamers that were marketing System/360 had the dream that there would be one operating system for all systems. The engineers building what became OS/360 used every trick they could imagine to cut OS/360's footprint. One of the tricks was to use the high order byte of a full word used as an address for other data. For example -The high order byte of the DCB address specifies the options. In the OPEN parameter list, the options are 0X8F. The first bit indicates the last DCB address in the parameter list, the next three bits – 000 in our example are used for other options, and the F in 0X8F indicates output. This pattern is repeated in the CLOSE parameter list.

The DCB repeated this. There are many addresses in the DCB. With one exception – not used until MVS/XA and OS/390 – all these addresses use the high order byte for something else. For example -
Another trick in the DCB was to not assemble unused data areas. For example -Yet another trick was to simply overlay part of the DCB in OPEN, and restore it in CLOSE. The DD name data, for example, disappears and is replaced by (yet another) truncated address and other data that is not seen in the DCB data area as shown here.

The little copy program at the start of the post runs fine as an AMODE 24, RMODE 24 program. It takes two changes to run AMODE 31, RMODE 24:

• Add an AMODE 31 Assembler statement. It can be linked AMODE 31 without the statement, but it won't run.
• Remove the * from the N 1,=A(X'FFFFFF') statement. This statement removes the CLOSE macro option, leaving the 24-bit DCB address. A wise programmer always uses this statement, so the same technique is used for both an AMODE 24 and an AMODE 31 program.

In a few days I will post the little copy program revised to run RMODE ANY.

These users thanked the author steve-myers for the post:

Aki88 (Wed Mar 02, 2016 10:32 am)

As promised a few days ago, here is the simplified copy program arranged to run AMODE 31, RMODE ANY.Those of you who have been programming a while will note that this program is coded like a reenterable program. Well, it is reenterable: the added cost is so small as to make no difference.

The second thing a beginner will notice is the program uses a DCBE, a DCB extension. What is this new, strange beast? The DCBE serves several purposes. Obviously it adds some new capabilities, which we are not using here. In addition, it provides a mechanism to provide 31 bit addresses for selected addresses, like the end of data routine, that cannot be specified in the DCB because the corresponding data area in the DCB has just 24 bits.

As we have previously mentioned, all DCB data areas you are actually using must be below the line. Traditional parameter lists for OPEN and CLOSE must also be below the line because of those pesky 24-bit addresses.

The code specifies one DCB in the program text -

MASTDCB DCB DSORG=PS,MACRF=(GL,PM),DDNAME=INPUT,DCBE=*-*

As coded, no address constants are actually used so it can be coded even though the program text is above the line. The DCBE parameter is specified because it sets flag bits that a DCBE address might be present.

MACRF=(GL,PM) permits the DCB image to be used for both input and output, though not at the same time. It does make it possible to use a single prototype in the program for both real DCBs in the work area.

The Program

LA 5,WASIZE
GETMAIN R,LV=(5)
LR 4,1
LR 11,1
SR 15,15
MVCL 4,14

Like most reenterable programs, the first thing the program does is allocate and initialize the work area. Strictly speaking, the MVCL instruction to initialize the entire work area is not necessary here since most of the work area consists of DCBs and a DCBE that are initialized elsewhere, but it's a good idea to do this all the time.

The GETMAIN macro allocates storage for the work area below the line. The GETMAIN service has a long history.

The only positional parameter – R – specifies the type of GETMAIN. If you look up the GETMAIN macro discussion in MVS Programming: Assembler Services Reference, Volume 1 you will discover a large number of these parameters. Most go back to OS/360 and are rarely used any more. The remainder were introduced with the first MVS release. The only OS/360 parameter still commonly used is R. Since it's an OS/360 parameter, the storage it allocates will be below the line. A more “recent” GETMAIN would be -

GETMAIN RU,LV=(0),LOC=(24,ANY)

MVC OPARM,MASTOPEN
MVC INDCB,MASTDCB
MVC INDCBE,MASTDCBE
MVC OUTDCB,MASTDCB
LA 0,INDCBE
ST 0,(DCBDCBE-IHADCB)+INDCB
MVC (DCBDDNAM-IHADCB)+OUTDCB,=CL8'OUTPUT'

Addresses specified like (DCBDCBE-IHADCB)+INDCB are a way to avoid code like

LA 1,INDCB
USING IHADCB,1
ST 0,DCBDCBE
DROP 1

DCBDCBE-IHADCB specifies the offset of the data area in the DCB, INDCB specifies the DCB being modified.

LOOP GET INDCB
LR 0,1
PUT OUTDCB,(0)
B LOOP

The copy loop is identical to the copy loop in the prototype AMODE 24, RMODE 24 program.

MASTOPEN OPEN (*-*,INPUT,*-*,OUTPUT),MF=L

This is the prototype of the parameter list for the OPEN macro. The *-* generates a value of 0 and is a visual indication a value will be stored later.

MASTDCBE DCBE EODAD=EOF

MASTDCBE specifies the prototype for a DCBE that is copied to the work area. Unlike the DCB, a DCBE can be specified above the line, so why move it? It has to be moved because OPEN modifies it. Since MCOPY is supposed to be reenterable, the copy in MCOPY's program text cannot be modified, so it is moved.

OPARMS OPEN (*-*,,*-*),MF=L
OPARM EQU OPARMS,*-OPARMS

These statements define the space for the parameter list for the OPEN and CLOSE macros. The EQU statement effectively redefines the parameter list; *-OPARMS defines a length value for the OPARM symbol so that MVC OPARM,MASTOPEN will copy the correct number of bytes to OPARM. The same technique is used for the two DCBs and the DCBE.
Accepted practice in the 1960s for reenterable programs was for the 72 byte register save area to be at the start of the work area, as it is here, and for register 13 to define the start of the work area as well as the start of the register save area. This practice continued to become the root practice for execution environments for some high level languages such PL/I and C/370 and continued to become the practice in the Language Environment execution environment. However, Assembler programmers largely abandoned this model. Register 13 still pointed to a register save area, but it was no longer tied to an immovable work area; another register pointed to the work area. It was much more convenient for register 13 to be used for a single purpose. While it is not necessary for MCOPY, the work area pointer (register 11) is separate from the save area pointer, (register 13, as usual). This was effectively true in the original non-reenterable version of MCOPY in the first post; register 12 was effectively the work area pointer as well as the program base register.

These users thanked the author steve-myers for the post:

Aki88 (Sat Mar 05, 2016 4:55 pm)