John Dunlop ([log in to unmask]) wrote:
: REMOTE FILE MYSTDIN;DEV=#
 
: REMOTE RUN RR.PUB.TYM;PARM=1;STDIN=*MYSTDIN
 
: This works fine (and still works) if the host and remote systems have the
same
: operating system (e.g. both on MPE/iX 4.0 or both on 5.0) but fails with a
                                               ^^^^^^^^^^^
                                               Are you _sure_ about this?
 
: nasty message if the host is on MPEX/iX 4.0 and the remote is on 5.0.
 
: The display is :
: **** OPEN OF STDIN FAILED (CERR 14)
 
: ABORT: RR.PUB.TYM
:        PC=a.00a1f35c dbg_stackdump_cmds+$28
: NM* 0) SP=41837c60 RP=a.004d4e10 trap_handler.handle_setdump+$f4
: NM  1) SP=41837be0 RP=a.004d62a4 trap_handler+$3a4
: NM  2) SP=41837b60 RP=a.0021038c subsystem_abort_handler+$28
: NM  3) SP=41837520 RP=a.00210330 ?subsystem_abort_handler+$8
:          export stub: 6e0.000c1ce0 _csu_error+$e4
: NM  4) SP=418374e0 RP=6e0.000a99a0 _open_std_file+$70
: NM  5) SP=41837360 RP=6e0.000a991c ?_open_std_file+$8
:          export stub: dac.0008da70 _start+$20
: NM  6) SP=41837320 RP=dac.0003403c $START$+$1c
: NM  7) SP=418361c0 RP=dac.00000000
:      (end of NM stack)
 
: As I read somewhere about the internal file numbers being changed in 5.0 to
: bring it into compliance with the POSIX file system where STDIN is file #0
: rather than #1 for 4.0, I am assuming this is a sympton of this change.
 
: Anyone want to comment on this ?
 
The routine _start is the C initialization routine.  It calls _open_std_file
to get its stdin, stdout and stderr files open.  When you said RUN, the
system opened *MYSTDIN as MPE file 0.  When _start reopened it, it ran into
some error.  This problem has nothing to do with how files are numbered
on either 4.0 or 5.0.  If you had been directly logged into that machine,
I would expect the error to be the same.  The most suspect part would seem
to be the DEV= on the file command.
 
The error stack may contain some useful information...
 
Steve