I have first results of loading an RM64 executable on MVS/380. I modified my loader to support 8-byte relocations (to some extent):
https://sourceforge.net/p/pdos/gitcode/ci/08848a821d247c9e7132c650ee75ced2fa92ce89/ And here is the main program to do the load on MVS/380: https://sourceforge.net/p/pdos/gitcode/ci/master/tree/util/loadmvs.c Should work on MVS 3.8J too - but load into 24-bit space instead of 31/32-bit space. JCL to run it is in same spot. Note that my definition of "64-bit executable" is all external references are VD such that it is CAPABLE of being loaded RM64 (especially on z/OS). Corresponding LG etc changes too. So I have a 64-bit executable - but I'm not actually loading it above 4 GiB at the moment. And here is the code - that contains a VD reference and build script. rem use z390 1.8.3 and the latest pdld built from source to rem produce an RMODE 64 executable that hopefully runs on z/OS rem you need to reverse the ftp with rdw option process rem and then do an iebcopy load call bat\asm one call bat\asm two rem i am surprised to see link working without me needing rem to provide a binder file (.LKD) with explicit INCLUDE statements rem and SYSLKD() option rem del two.obj rem call bat\link one amode31 rmode31 noinit rem as390 -o three.o -m64 -mzarch -march=z900 three.s rem pdld --oformat z390 --amode 31 --rmode any -o pdptest.exe one.obj two.o three.o rem call bat\exec one pdld --oformat mvs --amode 64 --rmode 64 -o pdptest.exe one.obj two.obj *********************************************************************** * * * This program written by Paul Edwards. * * Released to the public domain * * * *********************************************************************** *********************************************************************** * * * ONE - call TWO to set R15 * * * *********************************************************************** * AMODE 64 RMODE 64 CSECT YREGS * ENTRY ONE ONE DS 0H BALR R15,0 ONEZ DS 0H SAVE (14,12),,ONEZ LGR R10,R15 USING ONEZ,R10 LGR R9,R13 LA R13,SAVEAREA * WTO 'About to call two for two' LG R15,=VD(TWO) LGR R0,R14 BALR R14,R15 LGR R14,R0 LGR R13,R9 RETURN (14,12),RC=(15) SAVEAREA DS 19F END ONE *********************************************************************** * * * This program written by Paul Edwards. * * Released to the public domain * * * *********************************************************************** *********************************************************************** * * * return 3 in R15 * * * *********************************************************************** * AMODE 64 RMODE 64 CSECT YREGS * ENTRY TWO TWO DS 0H USING TWO,R15 LA R15,3 BR R14 END The pdld author is making a modification at the moment so that the resultant executable can be in XMIT format instead of a simple IEBCOPY + RDW. When he provides an update, I'll publish a new pdld executable. But the source code for the pdld I am using is already in sourceforge. So the next thing to do is to see if I can enhance my test program to do a WTO, by allocating BTL memory and moving the string to be displayed into low memory - something that needs to happen on z/OS too, I believe. Note that MVS/380 uses a modified IEWFETCH already, to support automatically dispatching an executable in AM31. I assume that that is where the RLDs are resolved as well, so Ideally that would be updated to honor the flag to process an 8-byte RLD - even if it is done in a crude manner - ie still gets loaded BTL, first 4 bytes are zeroed, and the relocation only affects the last 4 bytes. It was only a few lines of C code to do that, so I would expect a dozen or two lines of assembler code. So that RM64 executables are at least executable, even if they remain BTL. If any assembler expert is interested in making these changes, please contact me. Gerhard used to do such changes. Thanks. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
