Sharing drives between systems

[Mike Smith_33]

I am trying to share a couple drives from one OpenVMS box to another along the lines of nfs. I have shared out drives to my unix box over nfs with no problem but I don't know how this should be done in VMS. Basic scenario is this, the drive for all intents and purposes, appears to be local to both nodes. No, I don't want to cluster them.

Anybody got any advice?

[Hein van den Heuvel]

Simple VMS to VMS sharing? Just allow RMS to do transparent network file IO over decnet (over IP).

Commands like:

$DIR other_node::some_disk:[some_dir]

and

$TYPE other_node"username password"::test.txt

Of course there are all sorts of security opens: defaul accounts (not advised), proxies, explicit username/password.

Hein.

[Jan van den Ende]

Mike,

you may even be so lucky, that your network people do not block DECnet.
Then you do not even have to hassle with the DECnet-over-IP config.
A simple DECnet config __IF allowed__, is much simpler.

But after successful config, they work exactly the same.

Proost.

Have one on me.

jpe

[Mike Smith_33]

The decnet stuff is viable but I was really looking for something more along the lines of nfs. You are right though, that would work.

[Doug Phillips]

Do both systems have a TCP/IP stack installed? If so, then you probably have NFS available if you need it. But, DECnet is the *natural* way to go VMS to VMS.

Aside from your familiarity with NFS, what advantages do you feel it has over DECnet?

[Antoniov.]

Mike,
1) you have to enable NFS service
$ @SYS$MANAGER:TCPIP$CONFIG
Choice server component and client component.
2) enter into TCPIP console
$ TCPIP
look at MOUNT command that's like /etc/mount of unix system
TCPIP>HELP MOUNT

Good Luck!

Antonio Vigliotti

[Robert Gezelter]

Mike,

In one of your earlier responses, you mentioned that you were looking for something "DECnet is more viable, but more like NFS".

I may be missing something. What characteristic of NFS is important?

In NFS, most definitely provides client/server access to files. It is by no means "both systems having the drives as local". DECnet transparent file access, properly configured with proxies and logical names, will give essentially the same degree of access. For jollies, I have, on occasion, set my default device to a DECnet-including path, and even done compilations, links, and, executions directly over the DECnet.

It is, for many people, a somewhat unexpected result. It is a direct result of OpenVMS' architectural approach to most things. A file is a file is a file, after all.

- Bob Gezelter, http://www.rlgsc.com

[Anton van Ruitenbeek]

Mike,

If you want security you use DECNet (for sure) and if security isn't such a big deal you can use the IP stuf. We still have to wait for IPv6 if we want some option of security in IP.

On the VMS site you can mount the drive eg:
$ tcpip mount dnfs1: " /host="" /path="" /gid=200 /uid=4029 /system

The best thing is to do this under the SYSTEM account. At boottime this wont work because the bootprocess is started as 'STARTUP'. We do checking at boottime or the username is an identifier, if not 'SUBMIT/USER=SYSTEM' .

AvR

[Ian Miller.]

See also the DFS layered product - like NFS but over DECnet and native to VMS.

[Mike Smith_33]

I need to get more information from the dba. He presented to me something about the checkpoint files that he would be restoring from having hard coded device information in the file so that the device would need to be locally mounted in order for his database restore to work. That is why I felt nfs type mounting might be more appropriate. We currently do some decnet file stuff now as well as nfs between my vms and unix box. I really like the way the vms device appears as a mounted volume on the unix box. You all are correct, the decnet stuff is pretty powerful as well. I had mainly used it by pointing a logical over to a directory and having a proxy to give access.

[Jan van den Ende · Accepted solution]

Mike,

suppose your DBA needs a "local" device with syntax like like DZA100: or even DFSA123: if he 'requires DFS, for that matter), then,
for a device DUA4: at remote system "ABC", do a

$ DEFINE/SYS/EXEC/TRANS=CONC DZA100: ABC::DUA4:

and (assuming DB node XYZ) at ABC, do a
$ MCR AUTHORIZE ADD /PROX XYZ:: * /DEF

You also need to create your DBA's account with the same name, /ACCESSS=NETWORK, and give it whatever rights needed on XYZ.

Now, for all purposes, DZA100: can be used as-if local.


replace DZA100:, DAU4:, ABC::, XYZ, ,dba>, as needed.
If you have NOT defined logical names to your system and network authorisation files, then do a $ SET DEF SYS$SYSTEM before the AUTHORIZE command.

HTH,

Proost.

Have one on eme.

jpe

[Antoniov.]

Mike,
on vms you can add new devices that are slightly different from unix filesystem. Mounted device is like network disk of windows but vms can usename longer than 1 charactes; e.g. DKA0: (vms), F: (windows).

Decnet scenario is sure but you must use proxies to avoid publish password.

Antonio Vigliotti

[Daniel Fernandez Illan]

Mike
I have a network of VMS and Tru64 nodes.
On my experience, the best prectique to sharing drives between VMS nodes is to use DECnet (as say Jan) without forget to define nodes in database with DECNET_REGISTER. I use only NFS to share VMS and UNIX files. For my, DECnet guaranteed more security because use proxies defined on VMS.
Saludos.
Daniel.

[Mike Smith_33]

I am now ready to work on setting up the system as specified in the replies.