One more remark, BTW:
when I tested my Pascal compiler - including XRUNPARM - on modern
z/VM,
I found out that XRUNPARM with its current coding doesn't work
there, because the layout
of the module description areas have changed, and the length
information of the modules
(which is read by XRUNPARM to retrieve the needed length for
GETMAIN) isn't at the place any more
where it used to be).
So XRUNPARM on modern VM constantly failed with this error
message:
BADSIZE? DS??? 0H
???????? LA??? R2,1024-1(,R2) CONVERT REQUIRED SIZE TO 'K'
???????? SRL?? R2,10
???????? LINEDIT TEXT='"...................." REQUIRES ....K MORE
STORA*
?????????????? GE',DOT=NO,RENT=NO,SUB=(CHAR8A,MODNAME,DEC,(R2))
???????? LA??? R15,104????????????? SET RETURN CODE
which gives (for example):
MODULE XXXXXXXX REQUIRES 192K MORE STORAGE
no matter how many storage you allocated to your VM/CMS session.
I found a way to overcome this error message, but don't recall
what it was;
because z/VM doesn't belong to my regulary working environments, I
didn't pay much
attention (this was a user's request, and I didn't find an easy
way to make XRUNPARM
run on the old VM/370 R6 system and on z/VM at the same time ...
and I don't have the resources
to support different environments, which I do not use myself).
I'm sorry to say that MVS 3.8 and current z/OS are no problem in
this respect,
although I'd prefer working on VM, when preparing new mainframe
versions of the Pascal compiler.
Sorry, kind regards
Bernd
Am 05.02.2024 um 00:57 schrieb Bernd
Oppolzer via groups.io:
toggle quoted message
Show quoted text
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:
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.
