Oppolzer - Informatik / Blog

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).

Kind regards

Bernd



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 hercules-os380@yahoogroups.com, 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
>> etc.
>> 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
>>
>> Bernd
>>
>>
>>
>>