AMODE considerations

When a called COBOL program returns control to a calling assembler program, the AMODE won't be reset to the AMODE of the calling program. Upon return to the calling assembler program, the AMODE will be the same as when the COBOL program was invoked. Therefore, when an assembler program calls a COBOL program that has a different AMODE, the calling program must save its own AMODE before calling. When control returns from the COBOL program, the calling assembler program must then restore its own AMODE.

The following instruction sequence illustrates the previous discussion:

     LA     2,RESET  SAVE BRANCH ADDRESS AND CURRENT
     BSM    2,0      AMODE IN REGISTER 2
     BASSM 14,15     CALL COBOL PROGRAM
     BSM    0,2      BRANCH AND RESTORE AMODE FROM REG. 2
RESET DS     OH

If an assembler program that is AMODE 31 calls a COBOL program that is AMODE 24, the assembler program must also be RMODE 24 in order for COBOL to return to the assembler program. If the assembler program is AMODE ANY, in this case, an abend may result from the COBOL program as a result of branching to an invalid address since R14 will contain a 31–bit address from the assembler program's save area, but COBOL will return to the assembler program in AMODE 24.

When you have an application with COBOL subprograms, some of the COBOL subprograms can be AMODE(31) and some can be AMODE(24). If your application consists of only COBOL programs and you are only using static and dynamic calls, each COBOL subprogram will always be entered in the proper AMODE. For example, if you are using a COBOL dynamic call from an AMODE(31) COBOL program to an AMODE(24) COBOL program, automatic AMODE switching is done.

However, if you are using assembler programs along with other HLL programs that call COBOL subprograms, you must ensure that when a COBOL subprogram is called more than once in an enclave, it is entered in the same AMODE each time it is called.