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
