This is from a tachyon pdf: AMODE 64 Linkage
Using a Format-4 Save Area Entry Linkage from AMODE 64 caller: * STMG 14,12,8(13) *Save caller's registers * LARL 14,SAVEAREA *Get new save area address * STG 13,128(,14) *Chain to previous save area * STG 14,136(,13) *Chain to new save area * LGR 13,14 *Set R13 to save area address * LARL 12,DATA *Set base register for data * USING DATA,12 *Tell the assembler Exit Linkage: * LGHI 15,0 *Set return code * LG 13,128(,13) *Restore caller's R13 * LG 14,8(,13) *Restore caller's R14 * LMG 0,12,24(13) *Restore caller's R0-R12 * BR 14 *Return to caller *DATA LTORG *Start of data area *SAVEAREA DC 0D'0',F'0',C'F4SA',17FD'0'* Joe On Sun, Aug 17, 2025 at 11:11 AM Joseph Reichman < [email protected]> wrote: > Right that’s what I saw so in order to establish addressable you would do > > LARL RX,CSECTNAME right > > > > On Sun, Aug 17, 2025 at 12:09 PM Joe Monk < > [email protected]> wrote: > > > "At the begining of a rmode64 pgm to look at the register values and > > register 15 didn’t have the entry point " > > > > Correct. > > > > R15 on entry to a 64-bit program will have x'00000000 FFFFF002' - its a > > flag to say youre running in 64-bit mode. > > > > Joe > > > > On Sun, Aug 17, 2025 at 11:04 AM Joseph Reichman < > > [email protected]> wrote: > > > > > I inserted a DC H’0’ > > > At the begining of a rmode64 pgm to look at the register values and > > > register 15 didn’t have the entry point > > > > > > > On Aug 17, 2025, at 11:04 AM, Seymour J Metz <[email protected]> wrote: > > > > > > > > Standard linkage is different for AMODE24/31 and AMODE64. An RMODE64 > > > program should expect R15 to have flag rather than the EP address. > > > > > > > > -- > > > > Shmuel (Seymour J.) Metz > > > > http://mason.gmu.edu/~smetz3 > > > > עַם יִשְׂרָאֵל חַי > > > > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > From: IBM Mainframe Discussion List <[email protected]> on > > > behalf of Joe Monk <[email protected]> > > > > Sent: Sunday, August 17, 2025 11:00 AM > > > > To: [email protected] <[email protected]> > > > > Subject: Re: RMODE 64 > > > > > > > > > > > > External Message: Use Caution > > > > > > > > > > > > Standard linkage > > > > > > > > Joe > > > > > > > >> On Sun, Aug 17, 2025 at 9:52 AM Joseph Reichman < > > > >> [email protected]> wrote: > > > >> > > > >> My only question is when submitting a batch job to execute rmode 64 > > what > > > >> is the value > > > >> > > > >> Of Register 15 in entry > > > >> > > > >>> On Aug 17, 2025, at 10:32 AM, Peter Morrison < > > > >> [email protected]> wrote: > > > >>> > > > >>> People, > > > >>> > > > >>> > > > >>> > > > >>> I have watched this discussion for several days. I thought I would > > > weigh > > > >>> in. I have created and executed programs in RMODE 64. > > > >>> > > > >>> > > > >>> > > > >>> RMODE 64 has been supported by z/OS for a long time. I am not sure > > what > > > >>> level it came in with (someone else can provide that) but all the > > > >> relevant > > > >>> items have been changed, as mentioned below. > > > >>> > > > >>> > > > >>> > > > >>> Note that before I begin to list things, to execute in an RMODE 64 > > > >>> environment (i.e., located above the 'bar') you *MUST* be in AMODE > 64 > > > (if > > > >>> you are not sure why, please read the principles of operation. You > > > *MUST* > > > >>> also remain in AMODE 64 for as long as the code that is being > > executed > > > is > > > >>> above the bar. > > > >>> > > > >>> > > > >>> > > > >>> * You can use the assembler to create a CSECT that can be > > > loaded > > > >>> into 64-bit storage by using the '<csectname> RMODE 64' statement. > > > >>> > > > >>> > > > >>> > > > >>> * There is no specific 'xD' ESD entry. Instead, the object > > > format > > > >>> has been enhanced to add a bit to the flags field in the ESD which > > says > > > >> 'add > > > >>> 4 to the length of the field'. Thus VD and external AD fields can > > be > > > >>> handled. Similarly, the object RLD records also have a flag bit > that > > > says > > > >>> 'add 4 to the length - allowing an RLD entry for an 8-byte xD. Note > > > that > > > >> you > > > >>> do not need to use GOFF to have RMODE 64 CSECTs. > > > >>> > > > >>> > > > >>> > > > >>> * When you bind (link-edit) the program, you can specify > the > > > >> binder > > > >>> option via the JCL Parm field (you can also use an input option, > not > > > >>> discussed here, read the manual). *DO NOT* use 'RMODE=64'. Instead > > you > > > >>> *MUST* specify 'RMODEX=64TRUE'. Don't ask me why (RTFM). The > > resulting > > > >>> program is an RMODE64 program. > > > >>> > > > >>> > > > >>> > > > >>> * Note that an RMODE 64 program *DOES NOT* have to be a > > program > > > >>> object. The load module format in a PDS (not a PDSE) has been > > enhanced, > > > >> The > > > >>> RMODE in the directory entry has a RMODE64 bit, the CESD entry > flags > > in > > > >> the > > > >>> actual load module have a 'add 4 to the length' bit, and the RLD > > entry > > > >> flags > > > >>> in the actual load module have a 'add 4 to the length' bit. > > > >>> > > > >>> > > > >>> > > > >>> * Program management was enhanced to load RMODE 64 programs > > > above > > > >>> the bar. The CDE (still in 24-bit storage) will point to a CDX > which > > > >> point > > > >>> to a 64-bit extent list, which has 8-byte addresses and lengths. > > > >>> > > > >>> > > > >>> > > > >>> * The ATTACH[X], LINK[X], XCTL[X], and LOAD facilities all > > can > > > >> load > > > >>> RMODE 64 programs. Whether the parameter list passed to that > program > > > >> will be > > > >>> correct is another matter (note that the parameter list format > > depends > > > on > > > >>> the AMODE, not the RMODE) - the system doesn't alter the passed R1 > > > value > > > >> so > > > >>> you probably need to specify the correct parameter list format - > > > >> determining > > > >>> the target's RMODE (or AMODE) will be fun! (you can't use BLDL, > > because > > > >> the > > > >>> target program could be in the DLPA). I don't know what happens > (IPL > > > >> wait or > > > >>> ignored) if an RMODE 64 program that is put into PLPA (or MLPA or > > > FLPA) - > > > >>> there is no 64-bit xLPA (the DLPA can have RMODE 64 programs in it > > but > > > >> is > > > >>> not built during IPL) and the compressed extent list in the LPDE > does > > > not > > > >>> have 8-byte addresses and lengths. Note that all RMODE 64 programs > > > >> *MUST* be > > > >>> AMODE 64 but the reverse isn't true. (the parameter list format is > > > based > > > >> on > > > >>> the AMODE of the target, not the RMODE) > > > >>> > > > >>> > > > >>> > > > >>> * The JCL EXEC statement can execute an RMODE 64 program by > > > >> simply > > > >>> specifying its name. I don't know whether or not the PARMS passed > are > > > in > > > >> the > > > >>> correct format for a AMODE 64 program (does anyone want to test > > that?). > > > >>> Under the covers the EXEC statement uses ATTACH[X]. > > > >>> > > > >>> > > > >>> > > > >>> This list doesn't cover everything, but hopefully covers the main > > > things. > > > >>> > > > >>> > > > >>> > > > >>> It's pretty easy to make a program execute in RMODE 64 (as > mentioned > > > >> above, > > > >>> you *MUST* be in AMODE 64). However, as others have mentioned, only > > > some > > > >>> system services allow a user to be in AMODE 64, and even fewer > allow > > a > > > >> user > > > >>> to be located above the bar (i.e., RMODE 64). The safest rule is to > > > >> assume > > > >>> the AMODE64 and RMODE 64 code cannot use a service unless that > > service > > > >>> explicitly says it can. > > > >>> > > > >>> > > > >>> > > > >>> Peter Morrison > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > ---------------------------------------------------------------------- > > > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > > > >>> send email to [email protected] with the message: INFO > > IBM-MAIN > > > >> > > > >> > ---------------------------------------------------------------------- > > > >> For IBM-MAIN subscribe / signoff / archive access instructions, > > > >> send email to [email protected] with the message: INFO > > IBM-MAIN > > > >> > > > > > > > > > ---------------------------------------------------------------------- > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to [email protected] with the message: INFO > IBM-MAIN > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to [email protected] with the message: INFO > IBM-MAIN > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] with the message: INFO IBM-MAIN > > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
