topic Re: License for OpenVMS NFS client in Operating System - OpenVMS

License for OpenVMS NFS client

Larry Bleau — Tue, 22 Jul 2008 20:57:25 GMT

I'm running OpenVMS AXP 7.3-2 with TCPIP 5.4. I've been asked to get NFS client working; server part not needed. When I invoke TCPIP$NFS_CLIENT_STARTUP.COM I get the message

%TCPIP-E-STARTFAIL, failed to start TCPIP$NFS_CLIENT
-TCPIP-E-NOLICENSE, license check failed

I have the following licenses loaded (output of SHOW LICENSE):
NET-APP-SUP-150 DEC 1050 H 0 0.0 (none) (none)
UCX-IP-CLIENT DEC 0 0 100 0.0 (none) 31-OCT-2008
UCX-IP-NFS DEC 0 0 100 0.0 (none) 31-OCT-2008
UCX-IP-RT DEC 0 0 100 0.0 (none) 31-OCT-2008

Do I need some other license to get NFS to start? I would think the above is sufficient.

In case it helps, a TCPIP CHECK LICENSE defines the following symbols:

TCPIP$LICENSE_APP == "1"
TCPIP$LICENSE_NFS == "1"
TCPIP$LICENSE_RUN == "1"
TCPIP$LICENSE_TCPIP == "0"

All the FAQs I accessed were old and did not address this; if it's already covered a URL is appreciated.

Larry Bleau

Re: License for OpenVMS NFS client

Hoff — Tue, 22 Jul 2008 21:50:55 GMT

You have client licenses.

UCX or (for clients) NET-APP-SUP-250+ or (for servers) NET-APP-SUP-200

NET-APP-SUP-150 provides UCX-IP-CLIENT.

Licensing intro and related, and OpenVMS FAQ are here:

http://64.223.189.234/node/31
http://64.223.189.234/node/259
http://64.223.189.234/node/1

If you want to see what each of those licenses provide, see the SPD 46.46.xx document from

http://docs.hp.com/

http://docs.hp.com/en/12702/SPDTCPIP56.pdf

http://h30266.www3.hp.com/odl/axplp/databases/nas83c/nas_vax_over1.html

Stephen Hoffman
HoffmanLabs LLC

Re: License for OpenVMS NFS client

Larry Bleau — Wed, 23 Jul 2008 02:17:47 GMT

Here's aditional info:

I followed the links provided by Mr. Hoffman. One of them states that the NET-APP-SUP-150 license, which is what this system has, includes NFS client. Yet when I try to start NFS client the message says that the system does not have the proper license.

Clearly, something is wrong in the description of the NAS-150 license, or in how the system is evaluating the license condition.

Re: License for OpenVMS NFS client

Jess Goodman — Wed, 23 Jul 2008 18:23:59 GMT

What happens if you just do:

$ mcr sysman io connect DNFS /noadapter/driver=SYS$LOADABLE_IMAGES:TCPIP$DNFSDRIVER.EXE

Re: License for OpenVMS NFS client

Larry Bleau — Thu, 24 Jul 2008 01:03:46 GMT

I tried:

$ mcr sysman io connect DNFS /noadapter/driver=SYS$LOADABLE_IMAGES:TCPIP$DNFSDRIVER.EXE

It completed without any error message. When I tried running TCPIP$NFS_CLIENT_START.COM again, though, I got the same error message: no license.

I did a UCX SHOW SERVICE, and here's the NFS entry:

NFS 2049 UDP TCPIP$NFS 0.0.0.0 Disabled
N

I then tried UCX ENABLE SERVICE NFS, and got

$ ucx
TCPIP> enable serv nfs
%TCPIP-E-STARTERROR, error starting NFS service
-TCPIP-E-NOAPPLIC, TCPIP PAK is not enabled
TCPIP> enable serv nfs-client
%TCPIP-E-STARTERROR, error starting NFS-CLIENT service
-TCPIP-W-NORECORD, information not found
-RMS-E-RNF, record not found

I guessed at the second service name; no luck there.

Let me know what else I should try.

Larry

Re: License for OpenVMS NFS client

Hoff — Thu, 24 Jul 2008 01:35:35 GMT

You bought a license, and you can't get what the SPD seems to say you should get, which implies you're wasting your time in ITRC. ECO to current, test, confirm the 5.4 SPD has the same text, then ring up HP.

Re: License for OpenVMS NFS client

Jess Goodman — Thu, 24 Jul 2008 14:48:34 GMT

I don't believe you need to enable any services to use the NFS client. After you did the SYSMAN IO CONNECT command, you should have a DNFS0: template device. If so, then I think you should be able to do a TCPIP MOUNT command to access a remote file system.

Re: License for OpenVMS NFS client

Larry Bleau — Thu, 24 Jul 2008 18:08:13 GMT

Jess,

The SYSMAN IO CONNECT worked, or at least did not give an error. I then tried just a TCPIP MOUNT, but got a fatal error:

TCPIP> mount dnfs1: /host="shrgproc3.engin.umich.edu"/path="/shrg1/vms/ulysses"
%TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS1:[000000]
-SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node

I was given the hostname and pathname by the sysadmin of the remote system, so I have high confidence in them.

Do you recognize this error?

In another, related issue, before doing the above I did an ADD PROXY with the local (VMS) username and the remote system's UID and GID. That shouldn't matter for mounting purposes, though, only for accessing. It would only allow me to add a single proxy record for the remote host, however. What if I want more than one local user - or all local users - to access the same uid/gid on the remote system? I checked the manual, and it didn't give a hint of how to do this, only a warning against doing so.

Larry

Re: License for OpenVMS NFS client

Jess Goodman — Thu, 24 Jul 2008 20:30:37 GMT

I'm not sure, but perhaps it means that the remote network is not letting your site's NFS traffic to get through their firewall.

I only use the VMS NFS client on our local network, so I'm not sure of the security issues involved. I'm also not up on how to set up the proxies in the manner you mention.

In any case your problem is no longer on your end. I got the same "NOSUCHOBJ" error when I attempted the same mount you did (perhaps you posted a bit too much information :) )

Re: License for OpenVMS NFS client

Hoff — Thu, 24 Jul 2008 21:35:48 GMT

Firewalls or network errors or NFS configuration errors should not generate the error:

%TCPIP-E-STARTFAIL, failed to start TCPIP$NFS_CLIENT
-TCPIP-E-NOLICENSE, license check failed

if you have a valid license for starting an NFS client.

Re: License for OpenVMS NFS client

Larry Bleau — Thu, 24 Jul 2008 22:38:53 GMT

I asked the sysadmin of the remote system to check things out for me. He restarted the remote NFS server just in case. he was able to mount the file system I'm trying to access from his desktop system. So that confirms the file system is exported properly and the server works.

I then retried the mount command on the client (VMS) end, and it failed in the same manner:

%TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS1:[000000]
-SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node

Re: License for OpenVMS NFS client

Larry Bleau — Thu, 24 Jul 2008 22:52:30 GMT

One more datum: I have access to another OpenVMS system at the site, and it is licensed with NET-APP-SUP-200. (Note: It also runs an earlier version of VMS and TCPIP.)

I entered the exact same TCPIP MOUNT command, and it failed in exactly the same way!

This may not be a license problem after all. Can someone think of a non-license reason for this error?

Re: License for OpenVMS NFS client

Jon Pinkley — Thu, 24 Jul 2008 23:51:53 GMT

Or as Jess mentioned, perhaps a firewall is blocking the NFS traffic. Perhaps the nfs server has to explicitly allow your system access.

Are their any other boxes on your network segment that can nfs mount from the system?

Are you sure that the network connection isn't dropping packets that are large. Can you ping with a large packet?

$ ping -s 10000 shrgproc3.engin.umich.edu

A laptop with an nfs client could be a useful debugging tool, since you could determine where it works and possibly where it doesn't.

Good luck,

Jon

Re: License for OpenVMS NFS client

Larry Bleau — Fri, 25 Jul 2008 00:10:27 GMT

I asked about a firewall; no response to that email yet.

The desktop system that was able to nfs mount the file system isn't on the same network segment, but it is in the same building.

The system from which I'm working is remote to both, so I can't troubleshoot anything using my home system.

I am able to ping the server system from the client system. I used /packet_size=10000 as was suggested, and that worked without any problems.

Re: License for OpenVMS NFS client

Larry Bleau — Sat, 26 Jul 2008 19:23:42 GMT

Thanks, everyone. It turns out the problem was the server configuration. I can't say I understand what it was, exactly, but the sysadmin noticed something not quite right, changed it, and now the TCPIP MOUNT command works.

The procedure TCPIP$NFS_CLIENT_START.COM still fails (licensing problem), but that doesn't seem to make a difference. I'll just not execute it on system startup.