🚀 go-pugleaf

Michel Castelein wrote:
> Girls and Boys,
>
> In z/OS V1R3 and using HLASM R4, the following lines of assembler coding:
>      MAINPGM  CSECT
>      MAINPGM  AMODE 64
>      MAINPGM  RMODE ANY
>               SYSSTATE AMODE64=YES  <-- !!!
>      PROLOG   SAVE  (14,12)
> expand into:
>      PROLOG   DS    0H
>               STMG  14,12,8(13)     <-- !!!

yes. so?

> Cf. the Store Multiple "Grande" (STMG) instruction:
> Seemingly, the SAVE macro assumes there is a caller-provided 144-byte Format
> 4 save area available to save the ENTIRE 64-bit contents of R14-R12.
>
> 1st question:
> For a main program, the caller is the system (z/OS).
> What kind of save area is supplied by z/OS V1R3 (and later)?
> Is it still a traditional 72-byte "Format 0" save area or is it a new
> 144-byte Format 4 save area?
> Or does the type of save area provided by z/0S depends upon the AMODE of the
> (main) program?

You get a 144-byte save area, regardless of the AMODE,
from z/OS V1R3 and later.

>
> In the same assembler source, i.e. still under control of SYSSTATE
> AMODE64=YES, the macro call
>             RETURN (14,12),RC=0
> expands into:
>             LMG   14,12,144(13)     <-- !!!
>             LA    15,0(0,0)
>             BR    14
> Cf. the Load Multiple "Grande" (LMG) instruction:
> Seemingly, the RETURN macro also assumes the caller-provided save area to be
> of type Format 4.
>
> 2nd question:
> - The distance 144 used by LMG goes beyond the 144-byte save area!
> - 144 happens to be the offset in a (208-byte) Format 5 area used to
> save/restore the HIGH HALVES of R0-R15!
> What point am I missing (or is it a bug)?
>
> BTW, the LMG is the cause for a S0C4 with reason code 11. Not a surprise to
> me.


see comments below
>
> The complete JCL is:
> //ARCIS07X JOB 'HLASM',CLASS=A,MSGCLASS=X,COND=(0,NE),NOTIFY=&SYSUID
> //STEP1    EXEC PROC=ASMACLG,PARM.C=ASA  HLASM Release 4 - z/OS V1R3
> //C.SYSIN   DD  *
> MAINPGM  CSECT
> MAINPGM  AMODE 64
> MAINPGM  RMODE ANY
>          SYSSTATE AMODE64=YES
> PROLOG   SAVE  (14,12)
>          BALR  R12,R0
>          USING *,R12
>          LA    R11,SAVEAREA
>          ST    R11,8(R13)
>          ST    R13,SAVEAREA+4
>          LR    R13,R11
> *
> EPILOG   L     R13,SAVEAREA+4
>          RETURN (14,12),RC=0
> SAVEAREA DC    18F'0'
>          YREGS
>          END
> /*
> //L.SYSIN   DD  DUMMY

Wait.

1. Why are you using BALR / USING? When you
    are entered in in AMOD64, you _must_
    user LARL to get your base address

2. Forward and backward chaining are
    different if you will be working
    in AMODE64 - the 144-byte layout
    has different displacements for the
    forward and backward pointers.

Try this:

TEST64   CSECT
TEST64   AMODE 64
TEST64   RMODE ANY
          SYSSTATE AMODE64=YES
PROLOG   SAVE  (14,12)
          LARL  R12,TEST64
          USING *,R12
          LA    R11,SAVEAREA   point to my savearea
          STG   R11,136(R13)   save in calling pgm's savearea
          STG   R13,SAVEAREA+128  save z/os's save area pointer
          LGR   R13,R11        establish my save area
*
EPILOG   LG    R13,SAVEAREA+128  pick up z/OS's save area pointer
          RETURN (14,12),RC=0   return
SAVEAREA DC    18FD'0'
          YREGS
          END


<ad>
All this and a lot more is discussed in our
three day course "z/OS Assembler for Applications
Programmers". New hardware instructions, new
operating system linkages, and so on.

Currently reflects all except new z9 instructions
(no POPs yet) and the latest z/OS 1.7 (not much
there, I don't think, but have not had time to
add yet). So we include z990 instructions and
z/OS 1.6 info.

details at:
http://www.trainersfriend.com/Assembler_%20courses/C500descrpt.htm
</ad>

Kind regards,

-Steve Comstock