I have written XRUNPARM some years ago (2016), based on a routine
called RUNPARM,
which IMO is or was part of the COBOL runtime or came with the
COBOL compiler
(which, AFAIK, is an MVS compiler, which can be used with VM, too,
and the objects
created by this compiler have to be started using RUNPARM).
IIRC, I created XRUNPARM to start my Pascal programs
look here:
same story as with the Cobol compiler above.
Because XRUNPARM changed its size several times, the origin where
the Pascal programs start is now 20700.
You can look at the PASRUN EXEC (which should be on the S or Y
drive of the VM CE edition);
there you find:
...
&L1 = PASMONN
&L2 = PASLIBX
&L3 = PASUTILS
&L4 = PASSNAPC
&O1 = ORIGIN
&O2 = 20700
&O3 = RESET
&O4 = $PASENT
&O5 = CLEAR
LOAD &L1 &L2 &L3 &L4 &M1 &M2 &M3
&M4 &1 ( &O1 &O2 &O3 &O4 &O5
&IF &RETCODE NE 0 &GOTO -NOLOAD
*-----------------------------------------------------------
GENMOD &1
&IF &RETCODE NE 0 &GOTO -NOMOD
*-----------------------------------------------------------
FILEDEF QRD DISK &1 DBGINFO (RECFM F
XRUNPARM &1 &R1 &R2 &R3 &R4 &R5 &R6
&R7 &R8 &R9 &R10 &R11 &R12 &R13
&R14
...
I also tried to get rid of XRUNPARM completely and link the
startup code in XRUNPARM together with the
generated code coming from the Pascal compiler to build one single
module, but when I did so, my programs failed
by unknown reasons ... so I was stuck with the XRUNPARM solution.
At the moment, the code generated by the Pascal compiler is the
same for MVS and CMS, and this is fine
and I don't want to change this. If I could find a solution where
only the runtime libraries are different,
this would be OK for me. But at the moments the runtimes are the
same, too (only one minor difference,
concerning the allocation of the debug information data: on MVS a
member in a library DBGINFO with the member
name of the Pascal program (say: PROGNAME), and on VM a file
PROGNAME DBGINFO.
If you want to know more about the reasons, why I had to write an
own version of RUNPARM
or how I found out the length of XRUNPARM, contact me offline (I
guess it was by looking at
the LOAD MAP after building the XRUNPARM MODULE - the source code
should be on the S or Y drive, too;
if not, I can send you the actual version, which is from August
2023, BTW.
HTH, kind regards
Bernd
Am 05.02.2024 um 00:06 schrieb Mark A.
Stevens via groups.io:
toggle quoted message
Show quoted text
On Sun, Feb 4, 2024 at 04:42 PM, Dave Wade wrote:
Not sure what you are planning, but if your program
has issued any storage requests, the space at the end of the
program will have been used to satisfy those requests so not
available to load a second program.
There is a modules called RUNPARM and XRUNPARM, which is on the
Y-Disk. There is also WMSASM from the CBT. All three are supposed
to be a 'front end' for programs that are by nature MVS code. They
take command line parameters and fix up the PLIST to be something
the MVS program will be able to understand.
My few examples show something like:
RUNPARM MYPROG ...
Where MYPROG is a MODULE. So I am attempting to set the load
address for MYPROG to be beyond the end of RUNPARM.
Do I really know what I am doing. Nope. Just trying to figure it
all out.
?... Mark S.
