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.
