OVMS 8.2-1: Linking on NFS filesystem causes errors

[Thomas Ries]

Overview
--------
Trying to link an object file that is located on a NFS
filesystem results in the following errors:
ILINK-W-CLOSEIN, error closing DNFS1:[FRW.TEMP]T.OBJ;23 as input
-SYSTEM-F-IVCHNLSEC, invalid channel for create and map section


Details
-------
Scenario:

NFS Server (SERVER)

$ tcpip sh map
Dynamic Filesystem Map
Pathname Logical File System
/freeware DKB400:

$ tcpip sh export
File System Host name
/freeware/frw *

$ tcpip sh proxy
VMS User_name Type User_ID Group_ID Host_name
FRW OND 2000 2000 *
TCPIP$NFS OND 0 1 *
TCPIP$NOBODY OND -2 -2 *


NFS Client (CLIENT)

$ tcpip sh proxy
VMS User_name Type User_ID Group_ID Host_name
FRW OND 2000 2000 *
SYSTEM OND 0 1 *
TCPIP$NOBODY OND -2 -2 *

$ tcpip sh mount
_DNFS1:[FRW] automount (inactivity timer 0 00:30:00.00), mounted
SERVER:/freeware/frw


From the client side, read/write access is working fine on the NFS
mounted drive. However, if I try to *LINK* an simple object file
I get the following effect (reproduceable, every time):

$ set def DNFS1:[FRW.TEMP]
$ typ t.for
PROGRAM T
IMPLICIT NONE
type *, 'Hello World'
END
$ for t
$ link t
%ILINK-W-CLOSEIN, error closing DNFS1:[FRW.TEMP]T.OBJ;23 as input
-SYSTEM-F-IVCHNLSEC, invalid channel for create and map section
$


Combinations tried so far:

NFS Server NFS Client Result
----------------------------------------------------------------------
AXP 7.3-2 TCPIP 5.4 ECO2 I64 8.2 TCPIP 5.5 failed
AXP 7.3-2 TCPIP 5.4 ECO2 I64 8.2-1 TCPIP 5.5 ECO1 failed

AXP 7.3-2 TCPIP 5.4 ECO5 I64 8.2 TCPIP 5.5
AXP 7.3-2 TCPIP 5.4 ECO5 I64 8.2-1 TCPIP 5.5 ECO1 failed

AXP 7.2-1 TCPIP 5.1 ECO3 I64 8.2 failed
AXP 7.2-1 TCPIP 5.1 ECO3 I64 8.2-1 failed

AXP 7.3-2 TCPIP 5.4 ECO5 AXP 7.3-2 TCPIP 5.4 ECO5 ok
AXP 7.3-2 TCPIP 5.4 ECO5 AXP 7.3-2 TCPIP 5.4 ECO2 ok

Linux I64 8.2-1 TCPIP 5.5 ECO1 ok


It seems always to happen if:
- NFS is operating in "VMS to VMS" mode (VMS on both ends)
- NFS Client is OVMS 8.2/8.2-1 (I could not check with AXP 8.2 client)


Beside the above mentioned linking error, I noticed the following
other effect:

- CXX compiler: on SOME .CXX modules the CXX compiler dies with
INTERNAL ERROR: Can not create tmp file


Has anyone seen this? Any hints?

Thanks,
/Thomas

[Wim Van den Wyngaert]

Just tried it with a NFS server and client on 7.3 with TCP 5.3 eco 2.

It works for C and FORTRAN. BTW : you need 6 blanks before each fortran line.

sh log *nfs* ?
tcpip show nfs (do zero nfs first, then recompile, then show) ?
type tcpip$etcsysconfigtab.dat ?
Try it as SYSTEM (add proxy first) ?

Wim

[Volker Halle]

Thomas,

could this explicitly be related to the I64 linker ? Maybe it's using some functionality, which is not correctly provided by NFS ? The linker is completely different between Alpha and I64, so testing with LINK on an OpenVMS Alpha client may not provide any additional insight into this problem.

Volker.

[Volker Halle]

Thomas,

I tried to reproduce this linker 'error' (or more exact: 'warning') message and couldn't...

NFS Client: I64 V8.2, TCPIP V5.5
NFS Server: Alpha V8.2, TCPIP V5.5

Could you issue a REPLY/ENABLE on the NFS server and look for NFS OPCOM messages while linking (or CXX compiling) ?

You could also log XQP functions issued by the linker with:

$ SET WATCH FILE/CLASS=MAJ
$ LINK t
$ SET WATCH FILE/CLASS=NOMAJ

Volker.

[Eberhard Wacker]

Hi Thomas,

NFS is NOT supported/fully implemented on Itanium. I'm waiting for this too. The information in the release notes of the TCP/IP eco are not clear, but in the basic release notes it is mentioned clearly. As far as I know NFS will "may" be part of the next TCP/IP version and there will "may" be a backport.

Cheers,
EW

[Wim Van den Wyngaert]

Read again boys. AXP 7.x has the problem. Not Itanium specific !

Wim

[Volker Halle]

Wim,

I've re-read this topic and still see the problem on the I64 side (NFS client):


%ILINK-W-CLOSEIN, error closing DNFS1:[FRW.TEMP]T.OBJ;23 as input
-SYSTEM-F-IVCHNLSEC, invalid channel for create and map section


This (%ILINK-W-CLOSEIN) clearly is a warning message from the I64 linker !

NFS Server does not work in TCPIP V5.5 on I64, but it will work in V5.6 (to be delivered with V8.3). NFS client in TCPIP V5.5 on OpenVMS I64 should be o.k.

The I64 linker seems to map to the .OBJ file with create & map section, but gets an error when trying to close the channel.

Volker.

[Thomas Ries]

Ok, first thanks for the answers and suggestions. Let's see...

The mentioned linker warning (with following -SYSTEM-F-IVCHNLSEC - afaik -F- refers to Fatal) does _only_ _appear_ if the NFS Client is an IA64 OVMS 8.2* system.
Up to now I did not have an AXP OVMS 8.2 to test with, but hope I find time to try this on Monday (I will test both, AXP 8.2 as NFS server and client)


Wim:
The T.FOR file does have a at the beginnig of each line, it must have been lost when copy/pasting it into the web browser...
Oh yes, the resulting .EXE file does execute properly (as far as you can judge this by such a simple program).

$ SHOW LOG *NFS* gives (on client & server):
"TCPIP$NFS_CLIENT_ENABLE" = ".1.."
"TCPIP$NFS_ENABLE" = ".1.."
"TCPIP$NFS_SERVICES" = "SYS$LOADABLE_IMAGES:TCPIP$NFS_SERVICES.EXE"

I did a TCPIP ZERO NFS on the NFS server (AXP OVMS 7.3-2) and linked the .OBJ again. I hope the output does not mess-up too much:
$ tcpip sh nfs

Server rpc:
tcp: calls badcalls nullrecv badlen xdrcall creates
0 0 0 0 0 0
udp: calls badcalls nullrecv badlen xdrcall
30 0 14 0 0

Server nfs:
calls badcalls badprog badproc badvers badargs
30 0 0 0 0 0
unprivport weakauth
0 0

Server nfs V2: (30 out of 30 calls)
null getattr setattr root lookup readlink read
0 0% 7 23% 1 3% 0 0% 1 3% 0 0% 4 13%
wrcache write create remove rename link symlink
0 0% 15 50% 1 3% 0 0% 0 0% 0 0% 0 0%
mkdir rmdir readdir statfs
0 0% 0 0% 1 3% 0 0%

Server nfs V3: (0 out of 30 calls)
null getattr setattr lookup access readlink read
0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
write create mkdir symlink mknod remove rmdir
0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
rename link readdir readdir+ fsstat fsinfo pathconf
0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
commit
0 0%

$ TYPE tcpip$etc:sysconfigtab.dat (comment lines stripped)
On Server (AXP 7.3-2)
nfs:
tcp_threads=8
udp_threads=8
vfs:
vnode_age=120

On Client (I64 8.2-1)
nfs:
tcp_threads=8
udp_threads=8
ovms_xqp_plus_enabled=0
vfs:
vnode_age=120

Trying to link the .OBJ file as SYSTEM results in equal error.


Volker:
Doing REPLY/ENABLE on the NFS Server does not produce any OPCOM messages during linking/compiling. When compiling (CXX) a file, waiting a few minutes and then compiling again I get a:
%%%%%%%%%%% OPCOM 30-MAR-2006 19:58:39.84 %%%%%%%%%%%
Message from user NFS Server on SERVER
stale file handle file [DISK_3:(4,4,0)(10674,447,0)+0169], getattr
client address = 10.1.2.3, errno 2
This does not happen with linking.


$ SET WATCH FILE/CLASS=MAJ
$ LINK T
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (3515,2,0) Status: 00000001
%XQP, Thread #0, Access SYS$PUBLIC_VECTORS.EXE;1 (3515,2,0) Status: 00000001
%XQP, Thread #0, Control function (3515,2,0) Status: 00000001
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Access IMAGELIB.OLB;1 (3401,1,0) Status: 00000001
%XQP, Thread #0, Control function (3401,1,0) Status: 00000001
%XQP, Thread #0, Final status: 00000870
%XQP, Thread #0, Deaccess (3401,1,0) Reads: 11, Writes: 0, Status: 00000001
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Access DEC$FORRTL.EXE;1 (3325,2,0) Status: 00000001
%XQP, Thread #0, Control function (3325,2,0) Status: 00000001
%XQP, Thread #0, Control function DEC$FORRTL.EXE;1 (3325,2,0) Status: 00000001
%XQP, Thread #0, Deaccess (3325,2,0) Reads: 3, Writes: 0, Status: 00000001
%XQP, Thread #0, Deaccess (3515,2,0) Reads: 0, Writes: 0, Status: 00000001
%ILINK-W-CLOSEIN, error closing DNFS1:[FRW.TEMP]T.OBJ;26 as input
-SYSTEM-F-IVCHNLSEC, invalid channel for create and map section

I assume the Status-codes are in hex (x910 -> no such file).

The above does not look completely wrong to me.


The funny thing is, that this effect only pops up when having NFS operate in "VMS-to-VMS" mode (server & client are VMS). If the server is a Linux box and the client is I64 OVMS 8.2-1 everything links and compiles fine.

I will post more details about my test on Monday.

Regards,
/Thomas

[Eberhard Wacker]

Quote:
does _only_ _appear_ if the NFS Client is an IA64 OVMS 8.2* system

Again: at the moment NFS can NOT be used on IA64.

Cheers,
EW

[Eberhard Wacker]

... be used ... successfully !

[Eberhard Wacker]

Too early answered, quote from Volker:
NFS client in TCPIP V5.5 on OpenVMS I64 should be o.k.
I don't know, this was not told to me when I've opened a HP call some times ago.
Again cheers,
EW

[Volker Halle]

Thomas,

as with most communication-related problems it's hard to tell, who's right or wrong. Testing from an OpenVMS Alpha NFS client also does not provide any help, as the I64 linker is a different piece of software compared to the Alpha linker and may use different means of opening/mapping/closing the .OBJ file.

From the %ILINK-W-CLOSEIN message point of view, it's a warning message only. The underlying system service did exit with a fatal error. But the .EXE file should work o.k. - does it ?

Eberhard,

the TCPIP V5.5 release notes state in chapter 3.2:

NFS Server Does Not Run on I64 Platforms

There are no limitations mentioned for NFS client on I64.

Volker.

[Thomas Ries]

Now I also tried the following combinations:
Server: AXP OVMS 8.2 TCPIP 5.5 ECO1
Client: I64 OVMS 8.2-1 TCPIP 5.5 ECO1
and
Server: AXP OVMS 7.3-2 TCPIP 5.4 ECO2
Client: AXP OVMS 8.2 TCPIP 5.5 ECO1

As expected, with I64 as a CLIENT, the effect pops up. With AXP as client, everything works fine.

Side note:
The CXX compiling issue ("can not create tmp file") seems to be related to C++ files using templates like:
CMatrixMap mg_matrixmap;
and having SYS$SCRATCH pointing to a location that is in the NFS device. Also the specified include paths (/INCLUDE=...) seem to matter in some way.

We're going to open a call at HP and see what results we get.
I'll update this thread when we get feedback from HP.

Thanks,
/Thomas

[Thomas Ries]

Ok, we got some feedback from HP:

- This effect is "internally known" by HP, though no customer has complained before. With OVMS 8.3 (TCPIP V5.6) this issue *should* be fixed.

- The ECO2 for TCPIP V5.5 *might* include this fix.


Thanks to anyone helping.

Regards,
/Thomas