The following won't help with solving the system crash but I agree it
might be due to what Jerry mentions (I never learned to read memory
dumps). As of MPE/iX 5.0 (actually 4.5) when file number 0 became a
valid file number to use in intrinsic calls, I have dealt with numerous
programs that were failing (in user mode, not PM) that inadvertantly
called
FCLOSE (0). The symptoms would vary but things like:

- Getting socket number 0 on your next socket call (causing strange
fallout later).

- Your next FOPEN to some file from a program running in a job seemed to
attach itself to the job's $STDIN instead and read records from there.

- Strange stuff with RPMCREATE.

ALL of these were fallout from FCLOSE (0). If you can easily run the
program in session, you could try this.

<disclaimer>
WARNING!!!

I have done this kind of thing (very benign) in debug many, many times
with no problem. Then, without warning, a system crashes using the same
command (happened to me twice the other day on my test system). I've
found the probability to be very small but the possibility is very real.
There are no guarantees. Some people take the risk. Others with 24x7
systems choose not to (and rightly so) or do it at off-peak times. In
any case...

DON'T DO THIS UNLESS YOU ARE WILLING FOR THAT SYSTEM TO CRASH !!!

</disclaimer>

:RUN myprog;DEBUG
nmdebug> b FCLOSE,,,{wl;wl 'FCLOSE ' r26;tr,i,d;c}
added: NM    [1] SYS a.00eb389c FCLOSE
nmdebug> c

The above jibberish will set a breakpoint (bp) on entry to FCLOSE. When
the bp is hit, the commands within the {} will be executed. Be sure you
have those 3 commas before the {.

wl = write line
r26 is the first parm to FOPEN. It is passed by value.
tr,i,d = TRace, across Interrupt frames, Dual (nm and cm) mode (this one
I          use out of habit)
c = continue running

Also note that FCLOSE is the intrinsic and fclose is the posix routine.
Case matters. The space-id (that's the 'a' after SYS and before the '.'
in the 'added:' line above) should be 'a'. This means the bp is set in
XL.PUB.SYS (you, that is, the user and acct need PM to be able to set a
bp in a system library but the program itself does not). Without PM, I
think you can set the bp at the stub (?FCLOSE instead of FCLOSE). This
may affect how we get the return value (mentioned below, I haven't done
it this way in a long time, since always having PM :-)

Of course, if you FCLOSE file number 0, you want to know where the 0
came from. If you can't tell by looking at the source code, it helps to
know which FOPEN returned 0 (the condition code was probably not checked
or checked improperly). So, we need a bp after we return from FOPEN.

nmdebug>
 b FOPEN,,,{lev 1;b pc,-1,,{wl;wl 'FOPEN returned ' r28;tr,i,d;c};c}
added: NM    [1] SYS a.00ec1dbc FOPEN
nmdebug> c

This sets a bp on entry to FOPEN. When it is hit, we:
lev 1  = level down to stack frame 1 (we are at 0 now).
b pc  = set a bp at pc (Program Counter). This is the first instruction
        to execute after we return so we want to stop here.
,-1 = make this a temporary bp, we do it only once then it gets deleted.
      The next time FOPEN is hit, the bp is set again.
,,{...} = discussed below, these get executed when we return from FOPEN.
c = continue after setting our temp bp.

When we return from FOPEN, we do the inner set of {}:
r28 = the functional return value, that is, the file number. This is
what
      we're after.

Note that the values are in hex but you're really just looking for 0
anyway.


HTH  Erik :-)


Jerry Fochtman wrote:
>
> I've seem these problems when a program issues an FCLOSE against a
> zero (0) fnum while in PM...