Thank you, I'll look at that.
When playing with PL/1-F, there was even an issue, that drive letters of the
PL/1 phases are frozen into the generated modules using a feature which is
called GENDIRT, if I recall it correctly. If you put the modules later on
another minidisk, the compiler will not run any more. Because I didn't know this
feature from my VM experience from the past (80s and 90s), I had some hard time
to understand what's going on and to get the PL/1-F compiler running.
I guess these things were conceived by the VM or CMS people for performance
reasons in the 60s and 70s (CP67 heritage), but it seems kind of strange today
(GENMOD building a storage image without relocation on loading it).
Am 15.11.2011 18:56, schrieb M.N.:
> I had similar problems (0c?, ?0a, other abends) trying to use the Cobol compiler
> that comes with the vm370 6pk. I choose to use LOAD/START (ie, skipping GENMOD
> altogether) for all the examples in the "Jay Moseley's 'VSAM for Cobol' package"
> MVS->CMS conversion I posted in the VM370 forum files area.
> I'm too busy trying to get "KICKS for CMS" ready to go to work on Cobol beyond
> that point, but I suspect the issue with Cobol and similar ported programs is that
> GENMOD (in vm370) produces non-relocatable modules, so memory overlays are quite
> likely in programs that were designed for an OS multi module dynamic load/link/xctl
> structure, even if you use some kind of calculated origin resets for the load
> points for the corresponding CMS modules.
> Using relocatable TEXT files instead of MODULE files has its own set of issues,
> but in the case of the Cobol compiler resolved the memory abend issues I saw.
> --- In firstname.lastname@example.org, Bernd Oppolzer<berndoppolzer@...> wrote:
>> Don't know what it's worth, but:
>> I'm working with a newer (and more powerful) version of Stanford Pascal
>> on VM/370 on Hercules,
>> and until today I didn't manage to get my Pascal objects running the
>> usual way, that is, LOAD, GENMOD,
>> and then call the module by symply typing it's name. Instead I have to
>> do the following:
>> GLOBAL TXTLIB FORTLIB
>> LOAD &1 PASMONN (ORIGIN 20580 RESET $PASENT CLEAR
>> &IF &RETCODE NE 0 &GOTO -NOLOAD
>> GENMOD &1
>> &IF &RETCODE NE 0 &GOTO -NOMOD
>> RUNPARM &1
>> RUNPARM is a short piece of ASSEMBLER, which maps the CMS OS interface to
>> the MVS interface (because the Pascal interface is a MVS interface). But
>> the thing is:
>> I have to LOAD and GENMOD the module every time, look at the RESET parm.
>> I cannot rely on a prebuilt MODULE; if I try to do it, I get errors 0C1
>> RUNPARM issues a LINK macro call, if I recall it correctly. I'm not
>> sure, if the GENMOD
>> is really needed and if the created MODULE is in fact really used.
>> That said, I observed strange things with CMS, too, and, for example,
>> things went stable
>> only after I added the RESET parm on the LOAD above. So I could imagine,
>> that there
>> is really a bug (or: a flaw) in CMS, which is responsible for the GCC
>> problems, too.
>> I want to fix all this, when I have time to do it, but for the moment,
>> it is OK for me as it is.
>> If you have some suggestions, please tell me.
>> Kind regards