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
