Access Windows file share from OpenVMS

[A.W.R]

Hi,

Is it possible to mount a Windows file share
on a Windows system from OpenVMS Alpha system, and use the BACKUP utility to create my BACKUP savesets and store the BACKUPs there? Will I see it as a DNFS device?

Thanks
Andrew

[Hoff · Accepted solution]

This is not (directly) possible with TCP/IP Services for OpenVMS IP stack and the HP SMB CIFS Samba package.

Unlike TCP/IP Services and the DNFS device used for its NFS client implementation, there is no Windows SMB CIFS client provided for OpenVMS within the CIFS package. CIFS specifically provides a server and no client.

There is an smbclient SMB copy tool around that can potentially be used; that's basically akin to ftp that rides atop a connection into a CIFS server.

The usual solution here is to prepare a saveset or (usually as effective if nit better these days, a zip "-V" archive) and then sftp or ftp the file over to whatever the target box is. The use of zip "-V" both compresses and it also protects the file attributes while the OpenVMS file(s) are stored on Windows or another platform. BACKUP doesn't compress (yes, I know about the undocumented switch) and it doesn't automatically protect and recover the saveset attributes (yes, I know about /REPAIR), so you have to repair the attributes when the file arrives back.

http://labs.hoffmanlabs.com/node/684

Some related reading (as I might guess you're looking to use either a Windows Server box or potentially one of the many available NAS boxes) is here:

http://labs.hoffmanlabs.com/node/1211

Please log a problem report against HP CIFS here, either to have the (lack of) a client documented (as yours is a common question) and related suggestions added to the product managers, or to see if HP will implement a CIFS client for OpenVMS parallel to what DFS or NFS can provide folks.

[Bill Pedersen]

Andrew:

I notice from your other posts that you have been working with Unix and Windows primarily.

I suspect it is safe to say you do not have too much experience with OpenVMS file attributes. This is probably the biggest difference between PC file systems and Unix file systems when it comes to the OpenVMS file system. OpenVMS stores information about the file structure, the file and record attributes, in the file header, which is not directly part of the file. As such when a file is transferred to a file system which does not have this feature and these attributes are "lost" and either have to be copied separately or "recovered" by analyzing the file. As such most OpenVMS utilities do not then directly write to "foreign" file systems.

As Hoff has mentioned there are various utilities but they all work after the file is created and all generally require knowing about the attributes separately. FTP does have a mode where it copies the attributes into a separate file (a FDL file, for File Descriptor Language, which is what describes the attributes for the OpenVMS Record Management System utilities if you are creating a file using the utilities.) This then allows the movement of files through a "foreign" file system without too much hassle. Again, you still have to create the file on the OpenVMS environment and then transfer it.

Bill.

[David Jones_21]

If your need is to store backup savesets on windows volumes, there's the virtual tape library I wrote in 2005, see:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=965502

[Bill Pedersen]

Thanks for the comment Dave! But the link is broken. And if you go to the OpenVMS Freeware page the all they offer now are the disk images...

Is the TCP version on the disk image?

Thanks,

Bill.

[Steven Schweda]

> [...] these attributes are "lost" [...]

It may be worth noting that Macintosh file
systems also maintain OS-specific meta-data
for files (resource fork, Finder info, and
some newer ACL and other extended-attribute
things since OS X 10.5), but there exists
infrastructure on Mac OS X to handle file
storage on simpler file systems. A Web
search for "AppleDouble" would find much
information, such as:

http://en.wikipedia.org/wiki/AppleSingle_and_AppleDouble_formats

This allows, for example, high-fidelity Mac
file storage on a FAT-formatted USB flash
EEPROM storage gizmo.

Something similar could have been done (and
could still be done) for VMS, but I suspect
that its proprietors thought of VMS more as
a server than as a client in the realm of
file sharing, so it was never done.

The Info-ZIP Zip and UnZip programs
currently handle all that ATR$ stuff using
the "extra field" mechanism defined for Zip
archives. (They can do similar things for
Mac OS X files using the AppleDouble scheme,
and archiving two files for every real Mac
file.)

One can imagine some basic VMS file-system
infrastructure which could store (and
manipulate) those VMS-specific data in a
separate "VMSdouble" file, which could be
accommodated on any minimally capable foreign
file system. An NFS client or a Samba client
on a VMS system could use this mechanism to
get high-fidelity VMS file storage on a
non-VMS file system.

Implementing this would require some actual
engineering, so I wouldn't hold my breath,
but if Apple can cope, I see no technical
reason which would stop HP.

[Martin Vorlaender]

Bill,

it now is at http://www.digiater.nl/openvms/freeware/v80/zt/

HTH,
Martin

[Bill Pedersen]

Thanks for the insight, Steven.

Martin, thanks for the URL.

Bill.

[David Jones_21]

>>Thanks for the comment Dave! But the link is broken. And if you go to the OpenVMS Freeware page the all they offer now are the disk images...<<

Are you refering to the forum thread link (ID 965502) or the link in that thread to the freeware CD that no longer works? If you can get to the forum thread, the zip file is an attachment.

The link provided by Martin Vorlaender appears to be to the original ZT driver that provides access to remote (physical) tape drives over DECnet.

[Bill Pedersen]

Thanks, I missed the attachment...

The link to the item under Freeware is broken as HP consolidated all the freeware and only now offers the download of the three disk images, not the individual items.