Oppolzer - Informatik / Blog

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




Am 15.11.2011 14:15, schrieb M.N.:
> It's easy to demonstate: write to little pgm to display the args.
> compile, load,&  genmod it&  add it to the end of the gcce exec to display,
> say, 'mary had a lttle lamb'. gcce the little pgm again&  observe correct
> display of the args. introduce a bug ( such as #include<asdf>  ) and run gcce again&
> observe wrong display of the args. As I said in the 1st post I know the plist is good.
>
> I've not looked much further into this (didn't look at the eplist), but I know
> the problem is 'reset' if the assembler runs (ie, remove the rc check, let assembly
> bomb too). Be interesting to see if it happens even when the compiler gets an rc=0
> (by removing the asm step), but I haven't tried that. Also it's the assembler that
> needs to run; I didn't find anything else I could run that would fix it.
>
> Can't say why, butI don't think it's VM/370 or PDPCLIB. Instinct says it's the
> compiler itself doing something funky.
>
>
>