symlink on NFS client ODS-5 disk

[Tom Hartsook]

I have mounted an NFS disk as ODS-5.

Disk DNFS1: (ADM1), device type Foreign disk type 7, is online, mounted, file-
oriented device, shareable, accessed via DFS or NFS.

Volume Status: ODS-5, access dates enabled.

I can create the symlink, but any access fails. Any ideas?

$ dir/size test2.txt

Directory NOLIJ:[000000]

test2.txt;1 1

Total of 1 file, 1 block.
$ create sl.txt/sym="test2.txt"
$ dir/size sl.txt

Directory NOLIJ:[000000]

sl.txt;1 -> test2.txt
1

Total of 1 file, 1 block.
$ type sl.txt
%TYPE-W-OPENIN, error opening NOLIJ:[000000]sl.txt;1 as input
-RMS-F-ORG, invalid file organization value

[John Gillings]

Tom,

Odd!

$ HELP/MESSAGE ORG

ORG, invalid file organization value

Facility: RMS, OpenVMS Record Management Services

Explanation: An invalid file organization is encountered on an $OPEN system service or specified for a $CREATE system service. Files must be either sequential, relative, or indexed, unless block I/O processing is requested.

User Action: Verify that the call to the RMS file system service is coded correctly.

What does DIRECTORY/FULL for TEST2.TXT and SL.TXT say?

I also note the Volume Status doesn't say "Special Files". Try:

$ SET VOLUME/VOLUME=SPECIAL_FILES NOLIJ

and retry.

Curious because the default for ODS-5 should be "(NOHARDLINKS, NOACCESS_DATES, SPECIAL_FILES)"

[Tom Hartsook]

[000000]$ dir/full test2.txt

Directory NOLIJ:[000000]

test2.txt;1 File ID: (911,20875,0)
Size: 1/1 Owner: [DEVELOP,HARRIST]
Created: 27-MAY-2008 14:49:26.02
Revised: 27-MAY-2008 14:49:26.02 (0)
Expires:
Backup:
Effective:
Recording:
Accessed: 1-JUL-2008 12:26:28.78
Attributes: 27-MAY-2008 14:49:26.02
Modified: 27-MAY-2008 14:49:26.02
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: No_caching
File attributes: Allocation: 1, Extend: 0, Global buffer count: 0
No version limit
Record format: Stream_LF, maximum 0 bytes, longest 0 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RED, World:D
Access Cntrl List: None
Client attributes: None

Total of 1 file, 1/1 block.

[000000]$ dir/full sl.txt

Directory NOLIJ:[000000]

sl.txt;1 File ID: (2799,20873,0)
Size: 1/1 Owner: [DEVELOP,BANBATCH]
Created: 1-JUL-2008 12:29:06.61
Revised: 1-JUL-2008 12:29:06.61 (1)
Expires:
Backup:
Effective:
Recording:
Accessed: 1-JUL-2008 15:04:59.57
Attributes: 1-JUL-2008 12:29:06.61
Modified: 1-JUL-2008 12:29:06.61
Linkcount: 1
File organization: Special: symbolic link
Link Contents: test2.txt
Shelved state: Online
Caching attribute: No_caching
File attributes: Allocation: 1, Extend: 0, Global buffer count: 0
No version limit
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RED, World:D
Access Cntrl List: None
Client attributes: None

Total of 1 file, 1/1 block.

[Hoff]

Definitely odd. Roll your ECO kits up to current for both OpenVMS Alpha and for TCP/IP Services, (for grins) toss an SET VOLUME/VOLUME_CHARACTERISTICS=HARDLINKS and then an ANALYZE /DISK /REPAIR at the volume (because you're probably going to get asked to do that anyway), and then (if the problem persists) ring up HP support. It appears that hardlinks haven't been either integrated with NFS, or haven't been tested with NFS.

[Tom Hartsook]

[000000]$ set vol DNFS1: /volume=SPECIAL_FILES
%SET-E-NOTSET, error modifying _DNFS1:
-RMS-E-FNF, file not found

So I guess I will open a case with HP.

Thanks to all.

Tom

[Craig A Berry]

I don't think symlinks have anything to do with hardlinks, but they do, as John points out, apparently require "special files" capability on the volume. Whether the NFS client can serve up that capability via one of its virtual volumes is what's in doubt. According to the release notes here:

http://h71000.www7.hp.com/doc/83FINAL/tcprn/tcp_rnpro.html#nfs_symlink_support

TCP/IP Services v5.6 includes symbolic link support in the NFS server, but it says nothing about the NFS client. Most likely that is still a to-do.

[x2084]

This works for me with VMS/TCPIP serving an ODS5 disks and with VMS/TCPIP on the client side. I agree, being with the empire, in my current setup I use not yet available versions on the server side. So this can't be a proof point for you. But I expect this to work with the released versions, aka V8.3 and V8.3-1H1.

I didn't see what software and OSes are involved, here nor which versions of them. It would be interesting to know.

Hardlinks are a different thing, they are not required, here. In the released version of VMS, using symbolic links with hardlinks doesn't always work as expected, but that is also a different thing.

[Tom Hartsook]

The client is HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 2
on an AlphaServer GS160 6/1001 running OpenVMS V8.3

and the server is Solaris 10.

Tom

[x2084]

With a non-VMS server - I used Linux as a server - I can reproduce the error. As you probably observed, the client created symbolic link is created on the served disk and usable locally on the server side, but it does not work on the VMS client side.

The same error shows if you create a symbolic link locally on the server side and try to access it on the VMS client side.

It looks like the TCPIP client has a problem to access remote symbolic links on non-VMS servers.