How to mount NFS UNIX volume using VMS client

[Carlos Moreira]

I am a beginner when when it comes to VMS. I would like to know what the commands are to mount an NFS volume (UNIX server), proceeded by how I can change into the directory and write information to that directory (from any account on the system).

I am more familiar with UNIX than VMS, so an equivalent UNIX explanation would be helpful.

Thanks in advance!

P.S. I would send along the pertinent version numbers, etc., but I don't know the commands.

[Steven Schweda · Accepted solution]

Start with "TCPIP SHOW VERSION". When that
fails, try "SHOW LOGICAL *TCP*" and
'WRITE SYS$OUTPUT F$GETSYI( "VERSION")'.

VAX, Alpha, or Itanium hardware?

There is more than one TCP/IP kit for VMS,
and the details for NFS and everything else
differ among them.

[Carlos Moreira]

Here is the post and version of TCPIP (UCX):

Welcome to OpenVMS (TM) Alpha Operating System, Version V7.3-2

$ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 1
on a AlphaStation DS15 running OpenVMS V7.3-2

[Steven Schweda]

TCPIP HELP MOUNT

As a crude example:

$ tcpip
mount dnfs16: /host = urt /path = "/" /auto
mount dnfs17: /host = urt /path = "/usr" /auto
mount dnfs18: /host = urt /path = "/var" /auto

Defining some logical names can make some
things more convenient.

$ define /system urt_root dnfs16:[000000]
$ define /system /trans = conc urt_root_ dnfs16:[000000.]
$ define /system urt_usr dnfs17:[000000]
$ define /system /trans = conc urt_usr_ dnfs17:[000000.]
$ define /system urt_var dnfs18:[000000]
$ define /system /trans = conc urt_var_ dnfs18:[000000.]

To see "/net/urt/usr/local/src/vim":

ALP $ dire /date /size /prot urt_usr_:[local.src.vim]

Directory URT_USR_:[LOCAL.SRC.VIM]

PATCH.DIR;1 2 25-JAN-2004 01:15:50.95 (RWED,RWED,RED,RED)
VIM-5$5N7.DIR;1 1 25-JAN-2004 01:16:13.51 (RWED,RWED,RED,RED)
VIM-5.7-RT$5NTAR$5NGZ;1
2147 27-FEB-2001 21:45:08.00 (RWD,RWD,RD,RD)
VIM-5.7-SRC$5NTAR$5NGZ;1
2405 27-FEB-2001 21:45:20.00 (RWD,RWD,RD,RD)

Total of 4 files, 4555 blocks.

The ODS2-compatible names may be annoying.

Note that VMS lacks the concept of a root
file system, so looking for files in "/usr"
in the root fails:

ALP $ dire /date /size /prot urt_root_:[usr]
%DIRECT-W-NOFILES, no files found

even though the directory appears there:

ALP $ dire /date /size /prot urt_root_:[000000]usr

Directory URT_ROOT_:[000000]

USR.DIR;1 1 24-JAN-2004 23:26:44.73 (RWED,RWED,RED,RED)

Total of 1 file, 1 block.

But "urt_usr:" or "urt_usr_:[000000]" works.

Is that sufficiently confusing?

[Jan van den Ende]

Steven,

I really do NOT like any syntax that contains [000000.
Of course it is OK to specify the [000000] pseudo-directory itself, but if you specify a subdirectory by using a full stop after the 6 zeroes, you are inplying a REAL, existant 000000.DIR.
And if you do that in any command that implicitly creates directories (like BACKUP) you end up with a real 000000.DIR.
Still no harm done, but if you some time later repeat those actions, you create [000000]000000.DIR, and NOW the real fun can start!

Secondly, if these concealed devices are going to be needed by innermode code, they need to be /EXECUTIVE
An illustrative example is to use it as the device spec in AUTHORIZE.

In short, do not:
$ define /system /trans = conc urt_usr_ dnfs17:[000000.]
but use:
$ define /system/exec /trans = conc urt_usr_ dnfs17:

hth,

Proost.

Have one on me.

jpe

[Carlos Moreira]

I must be doing something wrong:

TCPIP> mount dnfs16: /host=engna2.bu.edu /path="/vol/research/eng_research_mctda
ta" /auto
%TCPIP$DNFSMOUNT-S-MOUNTED, /vol/research/eng_research_mctdata mounted on _DNFS1
6:[000000]
TCPIP> define /system mctdata dnfs16:[000000]
%CLI-W-NOQUAL, qualifiers not allowed - supply only verb and parameters
\SYSTEM\
TCPIP> exit
$ define /system mctdata dnfs16:[000000]
$ dire /date /size /prot mctdata_:[000000]
%DIRECT-E-OPENIN, error opening MCTDATA_:[000000]*.*;* as input
-RMS-F-DEV, error in device name or inappropriate device type for operation
$ define /system mctdata dnfs1:[000000]
%DCL-I-SUPERSEDE, previous value of MCTDATA has been superseded
$ dire /date /size /prot mctdata_:[000000]
%DIRECT-E-OPENIN, error opening MCTDATA_:[000000]*.*;* as input
-RMS-F-DEV, error in device name or inappropriate device type for operation

Any assistance would be great, thanks!

[Jan van den Ende]

Carlos,

if you posted EXACTLY what you did, then it is clear.

$ define /system mctdata dnfs16:[000000]
$ dire /date /size /prot mctdata_:[000000]


Look very good:

you DEFINE mctdata

and then USE mctdata_

Whatch carefully and notice the extra underscore.

But there is something more.

Either you define a construct containing a directory spec to SUBSTITUTE that dierectory spec, OR, you specify a CONCEALED DEVICE as a substitute for a device spec.
Concealed device definitions contain the mandatory /TRANS=CONCEAL qualifier ( "switch" in U*x speak )
A concealed device defines a name for a device spec (ending with : (colon) OR a name for a concealed device root, consisting of a real device spec, a colon, a directory spec WITH A FULL STOP ( . ) DIRECTLY IN FRONT OF THE CLOSING SQUARE BRACKET { ] }
in your example:
DEFI/SYS/EXE mctdata_ dnfs16: /trans = conc
or
DEFI/SYS/EXE mctdata_ dnfs16:[data.] trans is conc

Now, use it as

DEFIN /SYSTEM MCTDAT_XYZ /ctdata_:[XYX]

In the first case, use U*X system would have
/vol/research/eng_research_mctdata/xyz
in the second case that would be
/vol/research/eng_research_mctdata/data/xyz

A little extra advise: please choose your naming a little less confusing!
Two totally different definitions with only an underscore as (hardly visible) differentiator CAN BE a little confusing, as you yourself have made very obvius!

PS. If you want to have a clearer view of the exact spellings, then copy the text out ot the forums display, and paste it into a plain ASCI format, like any VMS or U*x editor, or even M$ Notepad.

hth,

Proost.

Have one on me.

jpe

[Jan van den Ende]

Carlos,

me again.

Sorry, I was a little late in noting your request for explanatios from a U*x perspective.

Unix does not display the notion of devices.
Perhaps the best way I can describe it: consider VMS to have not just ONE filesystem, but a separate one PER DEVICE.
And you can use them all mixed together, if only you specify them each time, like you would use a mix of files in /dev /var /etc /bin ...
(and lets forget about relative adressing, although the concepts are similar)

The concept of Logical Names has no real U*x equivalent.
Loosely speaking, they may be considered as environment variables. But /SYSTEM logicals are usable by all processes on the system, and can be changed with immedeate effect on all processes by suitably privileged users. Same applies for /GROUP logicals for all processes in that UIC group (cf the same gid )

Proost.

Have one on me.

jpe

[Carlos Moreira]

Thank you for your notes. They appear to be helpful, but I am still a bit confused.

How do I verify that I have successfully mounted the UNIX volume?

Also, what is the command to "change into that directory"? After that, I will try writing a file to see if that works. That is basically all I want to do.

Thanks,
Carlos

[Steven Schweda]

> How do I verify that I have successfully
> mounted the UNIX volume?

The DIRECTORY command offers a clue.

> Also, what is the command to "change into
> that directory"?

SET DEFAULT

You appear to need a general VMS primer.
Google can probably find several.

> After that, I will try writing a file to
> see if that works.

Writing how?

[Carlos Moreira]

My apologies, I meant to say that I just want to test the creation of a file so that the users of the system can begin storing data on this mount point.

I've been searching for a primer but haven't found anything specific enough.

How do I translate the following UNIX commands to VMS:

1) mount engna2.bu.edu:/vol/research/eng_research_mctdata /mnt/mctdata
(is this VMS directory dnfs#:[000000]?)
2) df
(i presume show dev /mou will work similarly)
3) cd /mnt/mctdata
(set def dnfs#:[000000]?)
4) touch test.file
(create /dir test.file?)

Thanks in advance,
Carlos

[Steven Schweda]

1) With the "/auto" in the TCPIP MOUNT
command, any reference to the remote file
system should get the thing mounted. (Just
as a reference to "/net/node/dir/file" would
on a UNIX system.)

TCPIP SHOW MOUNT can show what's mounted (or
subject to automounting).

2) "SHOW DEVICE DNFSxx" should show free
(512-byte) blocks. On my systems:

ALP $ sho dev DNFS16

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DNFS16: Mounted 0 URT$/ 729470 1 1

ALP $ sho dev DNFS17

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DNFS17: Mounted 0 URT$/usr 4270322 1 1


urt# df / /usr
Filesystem 512-blocks Used Available Capacity Mounted on
root_device 1048576 319106 708624 32% /
usr_domain_x#usr 14628416 10358094 3730320 74% /usr


Of course, this forum de-formats all that
output into practical illegibility,

3) "set def dnfs#:[000000]" looks reasonable.
(Filling in "#" with a real value, of
course.)

4) There is no exact match for "touch" in
DCL. People have written "touch.com"
procedures to get pretty close. "CRE /DIR"
creates a directory. To create a simple
empty file, you could try something like:
COPY NL: dnfs#:[000000]test.file
or
SET DEFAULT dnfs#:[000000]
COPY NL: test.file

NL: = NLA0: = the null device (like
"/dev/null")

More device info is available using a
lexical function, F$GETDVI(). For example:

ALP $ write sys$output f$getdvi( "dnfs17", "freeblocks")
4270322

ALP $ write sys$output f$getdvi( "dnfs17", "maxblock")
14628416

HELP LEXICAL F$GETDVI

Isn't this all interesting and educational?

[Carlos Moreira]

Here is where I am at:

TCPIP> mount dnfs: /host=engna2.bu.edu /path="/vol/eng_research_mctdata"
%TCPIP$DNFSMOUNT-S-MOUNTED, /vol/eng_research_mctdata mounted on _DNFS27:[000000]

TCPIP> show mount
_DNFS27:[000000] mounted
ENGNA2.BU.EDU:/vol/eng_research_mctdata

TCPIP> exit
$ set def dnfs27:[000000]

$ show def
DNFS27:[000000]
%DCL-I-INVDEF, DNFS27:[000000] does not exist

What did I type incorrectly or should this work?

Thanks!

[Steven Schweda]

That all looks reasonable (except for the
result). The local analogue works on my
system, of course.

I assume that:

1) The UNIX file system is suitably exported.
2) It can be NFS mounted on a non-VMS system.

What sort of UNIX system is this?

Are you working as SYSTEM on the VMS system,
or could there be a permissions problem?

[Carlos Moreira]

I feel better. I thought I was going crazy.

I am logged on as SYSTEM. I can mount the volume on other UNIX systems.

The UNIX server is actually a NetApp filer (3020c). Here is the output from sho dev /mou dnfs:

Device Device Error Volume Free Trans Mnt
Name Status Count Label Space Count Cnt
DNFS27: Mounted 0 ENGNA$/vol/e 319.99GB 1 1
DNFS28: Mounted 0 MCTDATA$DISK 319.99GB 1 1

[Steven Schweda]

> I thought I was going crazy.

Could still be true.

> [...] NetApp filer (3020c) [...]

That's beyond my (limited) range of
experience.

If you get desperate, the current ECO for
TCPIP V5.4 is 5, which is higher than your 1.
No bets, but it might be worth reading the
release notes and/or installing the thing.

ftp://ftp.itrc.hp.com/openvms_patches/layered_products/alpha/

Look for "DEC-AXPVMS-TCPIP_ECO-V0504-155-4.*".

[Jan van den Ende]

Carlos,

looks like Steven took over nicely while I was asleep.

Checking your profile, I am a little ashamed by my omisson yesterday, but here is a belated, although sincerely meant:

WELCOME to the VMS Forums!!!

I think there is one more general note I should add:

HELP

in VMS really DOES help! It is very good (although not completely perfect), and in pretty reasonable human-readable English.
Lots of utilities (amongst them TCPIP) even have their own HELP, so
TCPIP HELP
or for example
MC SYSGEN HELP
provide even more.

and as you found out you can ask here.

Proost.

Have one on me.

jpe

[Stanley F Quayle]

By the way -- if you add /ADF=CREATE to your TCPIP MOUNT command, each file's VMS characteristics will be stored on the NFS server in a "hidden" file (".$ADR$"). This is very useful for keeping the files useful on the VMS system.

[Carlos Moreira]

Is the mapping that I've seen in other posts required? In other words, is it merely a permissions problem that is causing me not to have the ability to read and/or write. At this point, I don't care which account can write to the NFS mounted volume. For my purposes any account on the system should have full access.

Thanks in advance,
Carlos

[Steven Schweda]

"mapping"?

"permissions problem"?

What did you do, and what happened when you
did it? Or has nothing changed since Jan 7,
2006 03:49:36 GMT?

Have you installed the latest TCPIP ECO?

[Carlos Moreira]

Nothing has changed, but I was wondering if the problem might be related to permissions. I'm not sure exactly what I'm asking, but I thought I may have overlooked something.

Also, I'm not comfortable upgrading the software because the machine is hooked up to equipment critical to research.

Thanks,
Carlos

[AdriaansenT]

Hi,

I have a problem with the free-blocks on VMS with a NFS mounted NetApp FAS6030 Volume. On Unix all looks oke.

on Unix:
-------------------------------------------
Filesystem Size Used Available Capacity Mounted on
145.43.80.130:/vol/volnfsvms 40G 1777M 38G 5% /mnt
-------------------------------------------

On VMS:

I have mounted the volume as an ODS-5 and an ODS-2 disk.
TCPIP> mount dnfs5: /host="rbndtcfasp001.b2b.regn.net" /path="/vol/volnfsvms" /system /superuser /write /adf=create /structure=5 /auto
TCPIP> mount dnfs2: /host="rbndtcfasp001.b2b.regn.net" /path="/vol/volnfsvms" /s
ystem /superuser /write /adf=create /auto

DNFS2: Mounted 0 rbndt$/vol/v 4194296 1 1
DNFS5: Mounted 0 rbndt$/vol/v 0 1 1

$ write sys$output f$getdvi( "dnfs5", "freeblocks")
4194296
$ write sys$output f$getdvi( "dnfs5", "maxblock")
4194296

$ write sys$output f$getdvi( "dnfs2", "freeblocks")
4194296
$ write sys$output f$getdvi( "dnfs2", "maxblock")
4194296

On the VMS disks the freeblocks = maxblock
(NFS client V2)

The Tru64 machine (NFS client V3)the data
is as follows

Size Used Available Capacity
40G 1777M 38G 5%

On VMS the used blocks are
$ set def dnfs5:[000000]
$ dir/size/grand

Grand total of 1 directory, 11 files, 3619413 blocks. (= 1767 MB)

4194296 blocks = 2047 MB

where is the correct freeblocks attribute?

Greetings from Doetinchem, Holland
Tom Adriaansen
IT-Specialist on VMS/Unix and SAN

[Steven Schweda]

AdriaansenT:

1. Start a new thread for a new problem.

2. TCPIP SHOW VERSION

[AdriaansenT]

Steven,

I did, just now

Tom Adriaansen

P.S.

My TCPIP Version is

$ tcpip
TCPIP> show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6
on a AlphaServer 4100 5/600 8MB running OpenVMS V7.3-2