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
&IF &RETCODE NE 0 &GOTO -NOMOD
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
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.
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.