On 12/2/2023 7:19 AM, Peter Relson wrote:
In the RMODE=SPLIT case you can end up with one part of the executable in one 
RMODE and the other part in another RMODE and V-Con's between the two parts are 
resolved at module fetch time.

Which is BTW ultra-cool functionality! (Too bad they don't allow tri-modal splitting... 😕 )

We have a product that uses RMODE(SPLIT) for 64-bit and 31-bit CSECTs. It does this because many z/OS services still require AMODE(31). The RMODE(64) code BASSMs to the RMODE(31) CSECT to call those services. Module fetch splits them for us at load time. It's a beautiful thing...

For the occasional AMODE(24) requirement (extremely rare), we usually just copy a tiny bit of self-contained code to a dynamically-acquired 24-bit work area somewhere and BASSM to it. If it's an RMODE(24) exit point or something, that code loads some previously-saved registers from the 24-bit work area and BASSMs to a routine above the line or above the bar to do whatever. These 24-bit work areas tend to be *very* small -- usually less than 256 bytes in length (but we round to a cache line boundary).

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/


--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Reply via email to