Re: How Big/Long is a CMS Module
Corrections to my earlier post:
The ability to execute load modules from an OS resident LOADLIB is only available in VM/SP and above.
At the VM/370 level, e.g. VM/CE, you can still define an OS resident PDS that contains object decks, and use that from VM/CMS.
Sorry for any confusion caused.
Mark
|
Re: How Big/Long is a CMS Module
Hi, Mark,
See:
? ? ??
and:
? ?
Section 8 - pages 127 and following --?page 141-142 talks about using OS resident MACLIBs.
Hope that helps,
Mark
|
Re: How Big/Long is a CMS Module
On Tue, Feb 6, 2024 at 02:10 AM, Dave Wade wrote:
I still wonder what Mark hopes to achieve as my experiences with the G assembler were not good.
Dave, I'm a masochist? ;-) I am certainly an optimist. In looking at the XF code, I saw there were overlays, but didn't understand how you would figure out how to make/apply them. Behind the self flagellation, is the thought of adding XA/ESA/z support, and seeing if any of the SLAC mods for ASMH could be added. In one of the sets of tapes/files/XMIT/DASD, I ran into an EXEC which looked similar to my efforts to create load modules with LKED (Yeah, I know it's for NCP, but long ago, I successfully used it to create a module, but the details are lost in the mists of time. Thanks for the tape/file. I'll go through it, as I can manage. ?... Mark S.
|
Re: How Big/Long is a CMS Module
On Mon, Feb 5, 2024 at 09:54 PM, Mark Waterbury wrote:
Then, when done, you can just remove the FILEDEF, release the "O" minidisk, and CP DETACH the OS volume when no longer in use.
Mark W., I think I understood all that! :-D I have copied Jay MOseley's SYSCPK to my VM/370, and have accessed it as? 'O' but I wasn't sure where to go from there. You've given me some ideas. ?... Mark S.
|
Re: How Big/Long is a CMS Module
On Mon, Feb 5, 2024 at 08:37 PM, David Durand wrote:
Mark S., some thoughts in case they are helpful.
David, Always appreciated. I've been able to take the TEXT decks and create MODULEs which load at specified addresses. I am just not sure if the addresses I have been using are correct. ?... Mark S.
|
Re: How Big/Long is a CMS Module
Folks, The ASSEMBLER XF uses auxiliary directories to overlay the assembler. I do have an ASSEMBLER G tape for VM and I have had it running but I forget how. ? ? There are multiple VMFPLC2 (or perhaps TAPE) dumps on it but I forget what you need to do to create the auxiliary directories. I am busy today demonstrating the Baby Replica Computer (let me know if you come to Manchester) but I will try and have a look tonight. (I am on GMT at present). ? I still wonder what Mark hopes to achieve as my experiences with the G assembler were not good. ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Dave Wade via groups.io
Sent: Tuesday, February 6, 2024 7:50 AM
To: [email protected]
Subject: Re: [h390-vm] How Big/Long is a CMS Module? Mark, Looking at the code on the tape I have, (I sent you a link) it uses auxiliary directories. I¡¯ll try and have a look tonight to see if these can be added to CMS but I am curious to know what problem you think this is going to solve? Dave ? ? On Mon, Feb 5, 2024 at 02:50 AM, Dave Wade wrote: Are you building a compiler for VM?
Still struggling with U of Waterloo Assembler G. I need the OS to VM conversion program, RUNPARM/XRUNPARM/WMSASM/... but am struggling with figuring out how/where to load that module, and the ASMG* MODULES, that is, their load/entry address. I also don't get to spend a lot of time thinking about it, as I have a grandson (2 1/2 years old) running around the house 4 days per week. My wife has Parkinson's Disease, so I am picking up more of her duties as time goes along. No tears. It's life.
I am learning a H*** of a lot along the way.
?... Mark S.
|
Re: How Big/Long is a CMS Module
Mark, Looking at the code on the tape I have, (I sent you a link) it uses auxiliary directories. I¡¯ll try and have a look tonight to see if these can be added to CMS but I am curious to know what problem you think this is going to solve? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Mark A. Stevens via groups.io
Sent: Tuesday, February 6, 2024 1:30 AM
To: [email protected]
Subject: Re: [h390-vm] How Big/Long is a CMS Module? On Mon, Feb 5, 2024 at 02:50 AM, Dave Wade wrote: Are you building a compiler for VM?
Still struggling with U of Waterloo Assembler G. I need the OS to VM conversion program, RUNPARM/XRUNPARM/WMSASM/... but am struggling with figuring out how/where to load that module, and the ASMG* MODULES, that is, their load/entry address. I also don't get to spend a lot of time thinking about it, as I have a grandson (2 1/2 years old) running around the house 4 days per week. My wife has Parkinson's Disease, so I am picking up more of her duties as time goes along. No tears. It's life.
I am learning a H*** of a lot along the way.
?... Mark S.
|
Re: How Big/Long is a CMS Module
Hi, Mark,
Here is another idea that may help to make your job easier in trying to get ASMG running under VM/CE CMS.
You can create a small OS mini-disk DASD volume, just big enough to have a minimal VTOC and one PDS library.? Size the minidisk just a few cylinders, just large enough to hold everything needed, with a little extra for "maintenance" activities, such as re-linking certain modules to incorporate fixes, etc.
Then, you run the link-edits under the real OS/360, or OS/VS1 or MVS (could even be MVS TK3, TK4- or TK5), to create your load modules from the object decks.
Then, to use it from VM/CE CMS, you issue CP LINK to that minidisk, then ACCESS it as a "mode" letter, (I like "O" for this, since it is an "OS disk"), and then issue a FILEDEF to define it to CMS, and then your main front-end program, equivalent of XRUNPARM or WMSASM, etc. can just issue a LOAD EP=name and then you load the address into R15 and issue a BALR R14,R15 to call the desired module, or even issue LINK EP= to let OS Simulation handle loading and unloading each "phase" in turn.
Then, when done, you can just remove the FILEDEF, release the "O" minidisk, and CP DETACH the OS volume when no longer in use.
Hope this helps,
Mark S. Waterbury
|
Re: How Big/Long is a CMS Module
Hi, David,
You are correct to point out how often times, people used the CMS loader to combine one or more TEXT object decks (CSECTs) into a single CMS load MODULE that could then be loaded on demand.? But, as you pointed out, you have to assign the different module "origins" (load addresses) yourself.? This can be a pain to figure out.
One nice thing is, with VM/CMS OS Simulation, we can just put all the object decks in a TXTLIB and issue GLOBAL TXTLIB and then, run the command front-end module, and have it issue the OS LINK OR LOAD macro to dynamically load those objects from the TXTLIB "on demand."
With newer versions (VM/SP and above), you also have the LKED command in CMS, that creates a LOADLIB that works similar to a TXTLIB, but with pre-linked load modules. They are still "relocatable" just like load modules on OS/360, or OS/VS1, SVS or MVS.? ?You could also issue a CP LINK to an OS DASD volume (on 2314, 3330, or 3350) and then ACCESS it as a CMS mode letter, and issue a special format FILEDEF to allow you to access an OS PDS library directly from CMS.? In this way, you could also use the LINK, LOAD, ATTACH or XCTL macros from CMS to load and run OS resident load modules under OS simulation.
Also of interest, we do have the LKED command on VM/370 Rel. 6 CMS, as it was there to facilitate creating a load module for use with VTAM NCP, to create the image that CP used to download into the IBM 3705 or equivalent.? ?I am working (part time) to experiment to see if we can create a few small "mods" to the OS simulation in VM/CE CMS to allow a similar use of those CMS resident LOADLIBs.? This would make it easier when porting various compilers, assemblers, etc., to run under CMS.
I note also that with? VM/CMS and virtual memory of up to 16 MB per user, we now have the luxury of just linking everything into one big fat "mega-MODULE" rather than having to deal with programmed "overlays."? ?The only problem with this approach is certain old applications relied on the overlay supervisor to re-load certain overlays into memory each time they were called, and that would re-initialize certain local variables, when the code was not reentrant.? Otherwise, I have had good success in the past in un-doing overlay structures with that approach.
Hope that helps,
Mark S. Waterbury
|
Re: How Big/Long is a CMS Module
Mark W.,
You are correct to point out the Transient Area as critical to understanding this issue.
Mark S., some thoughts in case they are helpful.
It's important to remember that?modules are imager of memory after the link loader has been run. This means that all address constants (external or internal, ACONS and VCONS, as we used to call them) have been resolved into absolute addresses, preventing relocation of the code. It's possible to have fully relocatable 370 code, but it is more than a bit painful, and?I'd be surprised if the whole assembler is relocatable.
The lack of relocation is why the transient area is handy. The different load areas means that even without relocation, transient modules can call non-transient modules, and nontransient modules can call transient modules. XEDIT and REXX used various forms of voodoo to load essentially all their code except for an initial boot module into high memory (or they lived on a DCSS at an address above the usual user area).?They could run arbitrary modules (as long as there was enough main memory in play). We do have the CMS dynamic loader, but it did not exist at the time that asmg was ported. I believe it's also possible to have a small transient module that can serve as an overlay manager, capable of loading and calling multiple heavyweight non-transient modules that do most of the work. The alternative is to rely on SVC 202, and ensure that the entry point of any module you via SVC will be at the same address as the return address from SVC. While that is theoretically possible, I don't think it's really maintainabl, especially since you have two different memory areas into which you can load modules without conflict.
I have not ported stuff from MVS, and indeed I know relatively little about OS variants, but especially the compilers tended to have complicated overlay structures. These were replicated when proting to CMS by using multiple Modules (one for each overlay), and loading and branching to them directly. That's why PLI on CMS consists of so many different modules. Building this up from scratch could be pretty painful at this remove. If you are trying to get ASMG running (even if you only have the MVS version, as it seems), and given that ASMG started as a patched version of Assembler F, I'd start first by looking at the source and build structure for? Assembler F in CMS, as you might be able to use that build structure (and it's execs) as a starting point for the task. With luck you might even be able to replace the existing F Modules with thjeir equivalent G modules.
At Brown where I was an undergrad, and where I did most of my hacking on VM, they did have ASMG running in VM, but I'm afraid that I never looked at the implementation.
|
Re: How Big/Long is a CMS Module
On Mon, Feb 5, 2024 at 02:50 AM, Dave Wade wrote:
Are you building a compiler for VM?
Still struggling with U of Waterloo Assembler G. I need the OS to VM conversion program, RUNPARM/XRUNPARM/WMSASM/... but am struggling with figuring out how/where to load that module, and the ASMG* MODULES, that is, their load/entry address. I also don't get to spend a lot of time thinking about it, as I have a grandson (2 1/2 years old) running around the house 4 days per week. My wife has Parkinson's Disease, so I am picking up more of her duties as time goes along. No tears. It's life. I am learning a H*** of a lot along the way. ?... Mark S.
|
Re: How Big/Long is a CMS Module
Mark, Are you building a compiler for VM? If so you might want to look at the two assembler routines on the Fortran 191 disk which provide the interface between CMS and the OS Fortran compiler. Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Mark Waterbury
Sent: Monday, February 5, 2024 12:35 AM
To: [email protected]
Subject: Re: [h390-vm] How Big/Long is a CMS Module? Hi, Bernd,
See my reply to Mark Stevens regarding RUNPARMS and XRUNPARM... :-)
Also, for VM/SP and above, you should be able to use the OSRUN command that is built-in to VM/SP and above to invoke your compiler with an OS style parameter list.
All the best,
Mark S. Waterbury
|
Re: How Big/Long is a CMS Module
Hi, Mark,
For the archives and future folks reading these messages:
The CMS "transient area" is defined and explained in several of the CMS manuals, such as:
?
and
?
or
?
(under the LOAD and GENMOD commands).
Mark S. Waterbury
|
Re: How Big/Long is a CMS Module
For future reference.
From GC20-1809-7_VM370_OLTSEP_and_Error_Reporting_Guide_Rel_6_PLC_1_Mar79.pdf
Transient Program Area (X'0E000' to X'10000') Since it is not
essential to keep all nucleus functions resident in storage all the
time, some of them are made "transient." This means that when they
are needed, they are loaded from the disk into the transient program
area.? Such programs may not be longer than two pages, because that
is the size of the transient area.? (A page is 4096 bytes of virtual
storage.) All transient routines must be serially reusable since
they are not read in each time they are needed.
User Program Area (X'20000' to Loader Tables) User programs are
loaded into this area? by the LOAD command.? Storage allocated by
means of the GETMAIN macro instruction is taken from this area,
starting from the high address of the user program.? In addition,
this storage area can be allocated from the top down by DMSFREE, if
there is not enough storage available in the low DMSFREE storage
area. Thus, the usable size of the user program area is reduced by
the amount of free storage that has been allocated from it by
DMSFREE.
Free Storage Management
Free storage can be allocated by issuing the GETMAIN or DMSFREE macros.
Storage allocated by the GETMAIN macro is taken from the user program
area, beginning after the high address of the user program.
... Mark S.
|
Re: How Big/Long is a CMS Module
On Sun, Feb 4, 2024 at 06:32 PM, Mark Waterbury wrote:
RUNPARMS and XRUNPARM are very small, so no reason they could not be compiled and loaded with "(ORIGIN TRANS" to run in the CMS transient area (only 8K), then that way they can load and run any normal VM/CMS module that has the default origin address of x'20000' ... :-)
Had not considered that, since I don't know off hand how big the transient area is. I'm sure it's in a manual someplace :-D So, I'll add that to my list.? Thanks! However, since RUNPARM issues a GETMAIN, I need to learn what it does when running from the transient area, as compared to the user area. More to learn. ?... Mark S.
|
Re: How Big/Long is a CMS Module
On Sun, Feb 4, 2024 at 05:57 PM, Bernd Oppolzer wrote:
I have written XRUNPARM some years ago (2016), based on a routine called RUNPARM,
I wondered where XRUNPARM came from, and now I know! Thank you!! I do know where the source is, and have assembled it. The TEXT and LISTING files are somewhere around here. I had been looking at LOAD MAPs for both XRUNPARM and RUNPARM, and could not determine where the end/length of/size of the MODULEs were. Something I read steered me to look at DMSMOD, where I found the information cited above. I *think* I'm using it correctly. ?... Mark S.
|
Re: How Big/Long is a CMS Module
Hi, Bernd,
See my reply to Mark Stevens regarding RUNPARMS and XRUNPARM... :-)
Also, for VM/SP and above, you should be able to use the OSRUN command that is built-in to VM/SP and above to invoke your compiler with an OS style parameter list.
All the best,
Mark S. Waterbury
|
Re: How Big/Long is a CMS Module
Hi, Mark,
RUNPARMS and XRUNPARM are very small, so no reason they could not be compiled and loaded with "(ORIGIN TRANS" to run in the CMS transient area (only 8K), then that way they can load and run any normal VM/CMS module that has the default origin address of x'20000' ... :-)
All the best,
Mark S. Waterbury
|
Re: How Big/Long is a CMS Module
On Sun, Feb 4, 2024 at 05:54 PM, Ren¨¦ Ferland wrote:
Have you check the assembler code of RUNPARM? I can't say for sure but, looking at it, I feel RUNPARM does make a call to GETMAIN to obtain storage for the module beyond the end of itself.
Rene, Yes, I have, and it has a call to GETMAIN and FREEMAIN. ?... Mark S.
|
Re: How Big/Long is a CMS Module
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.
|
Mark A. Stevens