VMS backup to NFS shares

VMS backup to NFS shares

Post by Jason McCormi » Tue, 01 Jul 2003 11:24:26



I was hoping that a VMS guru could answer a question for me.  I have a
VAXStation 4000 90A and I'm attempting to get a usable backup solution
for it.  The tape unit I've been using on it requires a data stream
speed that the VAX simply can't keep pushing out to the unit and it's
casuing physical damage.  I have Multinet and I was looking at
mounting a remote NFS share to the VAX and using the backup command to
create savesets on the remote NFS server and then put those savesets
to tape on the remote server.

  I ran this idea past someone who's more familiar with VMS and they
expressed concern that this plan may not work whenever you attempt to
restore files from the savesets as "information specific to VMS may be
lost" but couldn't be clear to me what information that might be.  I
know that you can use backup to create savesets on-disk that function
identical to those on tape so I'm curious as to if there's any gotchas
that might be associated with creating backups on a remote NFS share
disk.  The remote computer serving NFS would be Linux or Solaris.  If
anyone could share insight on this plan, I'd be most grateful.

-- Jason McCormick

 
 
 

VMS backup to NFS shares

Post by Stanley F. Quayl » Tue, 01 Jul 2003 12:24:42



Quote:> I have Multinet and I was looking at mounting a remote NFS share to
> the VAX and using the backup command to create savesets on the
> remote NFS server and then put those savesets to tape on the remote
> server.

>   I ran this idea past someone who's more familiar with VMS and they
> expressed concern that this plan may not work whenever you attempt to
> restore files from the savesets as "information specific to VMS may be
> lost" but couldn't be clear to me what information that might be.

I do exactly this with all my VMS machines, VAX and Alpha, and it
works great (I do use the HP/Compaq TCP/IP stack, however).

Here's the command I use to mount the shares (again, it's specific to
the "UCX" stack):

$ UCX
  MOUNT DNFS0:[<dir>] NFS_<dir>  DISK$<dir>  -
    /HOST=<nfs box ip>  /PATH="<nfs mount point> -
    /PROTECTION=(S:RWED,O:RWED,G:RWED,W:RWED) -
    /RETRIES=100 /ADF=CREATE

The secret is the "/ADF=CREATE".  For every file that's created by
VMS, a second file which starts with ".$ADF$" which holds the file
characteristics (in Unix/Linux, files that start with a period are
"hidden").  This is the information that your guru mentioned -- this
information is stored in the file header on VMS volumes, but there's
no equivalent in Unix.

I don't know you do this in Multinet, but there might be an
equivalent.  Here's the HELP for /ADF in UCX:

TCPIP> help mount /adf

MOUNT

  /ADF

        /ADF=CREATE
        /NOADF

     Optional. Default: /ADF=CREATE.

     If attributes data files (ADFs) exist on the NFS server, the
     /ADF qualifier lets you use them.

     The server uses ADFs to store OpenVMS file attributes. These
     files appear on the server as .$ADF$file files, but you cannot
     view them directly on the local client system.

     The option is:

     o  CREATE

        The client uses and updates the ADFs, and creates ADFs for
        new files.

     /NOADF - No ADFs are created or used.
--Stan Quayle
Quayle Consulting Inc.

----------
Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363  Fax: +1 614 868-1671
8572 North Spring Ct. NW, Pickerington, OH  43147


 
 
 

VMS backup to NFS shares

Post by George Corneli » Tue, 01 Jul 2003 13:27:26



Quote:> I was hoping that a VMS guru could answer a question for me.  I have a
> VAXStation 4000 90A and I'm attempting to get a usable backup solution
> for it.  The tape unit I've been using on it requires a data stream
> speed that the VAX simply can't keep pushing out to the unit and it's
> casuing physical damage.  I have Multinet and I was looking at
> mounting a remote NFS share to the VAX and using the backup command to
> create savesets on the remote NFS server and then put those savesets
> to tape on the remote server.

>   I ran this idea past someone who's more familiar with VMS and they
> expressed concern that this plan may not work whenever you attempt to
> restore files from the savesets as "information specific to VMS may be
> lost" but couldn't be clear to me what information that might be.  I
> know that you can use backup to create savesets on-disk that function
> identical to those on tape so I'm curious as to if there's any gotchas
> that might be associated with creating backups on a remote NFS share
> disk.  The remote computer serving NFS would be Linux or Solaris.  If
> anyone could share insight on this plan, I'd be most grateful.

It used to be explicitly stated that BACKUP savesets could not reside
on NFS volumes, or at least could not reside on HP TCPIP Services NFS
volumes.  I suppose the issue is that the record size information is not
recorded on an NFS volume - information that is crucial when restoring
from a saveset.

That being the case, you might have to play some games to get it
to work.  One of these is to do the backup disk-to-disk, then copy
the saveset to the NFS volume afterwards.  Equivalently, you could
use a pipe, say

 $ ! Note use of limited blocksize (may be necessary on a VAX)
 $ PIPE BACKUP/IMAGE mydisk SYS$OUTPUT:/SAVE/BLOC=4096 | -
     COPY SYS$INPUT nfsvol_destination_file

In the latter case you may have trouble with restores because COPY
as an initial pipeline stage feeding into BACKUP will not be able
to convert a stream of bytes into records of the correct size.  You
may, however, find that a tool such as EXCHANGE/NETWORK, or a simple
homegrown C program, could do this.  With the staging disk approach,
you would copy the file to the staging disk, then use $ SET FILE
/ATTRIBUTES to set its record format and logical record length
before using it as input to VMS BACKUP.

For restores in general, remember that you'll need a bootable
VMS system that includes NFS in order to restore any data.  This
makes system disk backups an issue unless you have a spare system
disk available or can restore using another node.

Also: be sure that your NFS connection supports binary files.  I don't
know how it works with Multinet, but I believe that with TCPIP Services
you have to make sure there is no automatic translation of data records
to and from STREAM/STREAM_LF.

Another approach is to use ZIP.  But you are then of course substituting
a public domain tool with little or no support and unknown reliability
for the highly reliable and well understood VMS BACKUP utility.

Oh, and if it's VMS to VMS, consider using DECnet:

   $ BACKUP/IMAGE mydisk node"access control"::saveset/SAVE/BLOCK=...

remembering that you may want to increase the RMS default network block
size at both ends of the network link, say in the LOGIN.COM files or by
issuing a $ SET RMS_DEFAULT/SYSTEM command in SYSTARTUP_VMS.COM .

--


- Show quoted text -

Quote:> -- Jason McCormick

 
 
 

VMS backup to NFS shares

Post by Andrew Balaa » Tue, 01 Jul 2003 14:20:51


Multinet stores the FDL info in a hidden file (ie, one starting with a .)
on an NFS server by default. So when the file is viewed from VMS, the
file attributes are correct.

If you are doing and image followed by daily and weekly incremental
backups, you will have to work out some method of restoring the image
backup (if it is the system disk).

Backup savesets seem to compress quite well using gzip on the linux box.
I went through an exercise recently, reading all our older project
archives that were stored on Exabyte (8mm) tapes. I mounted the tapes
non-foreign and copied all the savesets off the tapes to an NFS served
area on a Linux box. There was at the end, about 30GB of data. I gzipped
all the savesets, and removed all the hidden FDL files (the contents of
these files were all identical) and got all the data on to 2 DVD-Rs. To
read a saveset, I just copy one off the DVD into an area readable by my
VAX over NFS, gunzip it, create the hidden FDL file and then use backup
on the VAX.

Quote:>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<


regarding VMS backup to NFS shares:
Quote:> I was hoping that a VMS guru could answer a question for me.  I have a
> VAXStation 4000 90A and I'm attempting to get a usable backup solution
> for it.  The tape unit I've been using on it requires a data stream
> speed that the VAX simply can't keep pushing out to the unit and it's
> casuing physical damage.  I have Multinet and I was looking at
> mounting a remote NFS share to the VAX and using the backup command to
> create savesets on the remote NFS server and then put those savesets
> to tape on the remote server.
>   I ran this idea past someone who's more familiar with VMS and they
> expressed concern that this plan may not work whenever you attempt to
> restore files from the savesets as "information specific to VMS may be
> lost" but couldn't be clear to me what information that might be.  I
> know that you can use backup to create savesets on-disk that function
> identical to those on tape so I'm curious as to if there's any gotchas
> that might be associated with creating backups on a remote NFS share
> disk.  The remote computer serving NFS would be Linux or Solaris.  If
> anyone could share insight on this plan, I'd be most grateful.
> -- Jason McCormick

 
 
 

VMS backup to NFS shares

Post by Jason McCormi » Wed, 02 Jul 2003 02:58:24


Quote:> Multinet stores the FDL info in a hidden file (ie, one starting with a .
> )
> on an NFS server by default. So when the file is viewed from VMS, the
> file attributes are correct.

So unlike UCX (as pointed out in this thread) there's no need to
specify a qualified like /ADF= since it's automatic? (Just wanting to
make sure)

Quote:> If you are doing and image followed by daily and weekly incremental
> backups, you will have to work out some method of restoring the image
> backup (if it is the system disk).

I'm going to use our old TZ86 to back up the system disks and then all
the user/application data is on other disks.  I can use backup/image
across NFS for the disks that aren't the system disk though correct?

Quote:> To read a saveset, I just copy one off the DVD into an area readable by my
> VAX over NFS, gunzip it, create the hidden FDL file and then use backup
> on the VAX.

And all the files restored correctly?  Terrific.

Thanks for the insight into Multinet.  And thanks to everyone else who
had some ideas.  It's much appreciated.

-- Jason

 
 
 

VMS backup to NFS shares

Post by Andrew Balaa » Wed, 02 Jul 2003 05:44:51


Jason,

I have not used UCX, so I can't comment on how that package handles NFS
mounts. As I said, the default behaviour for Multinet is to preserve FDL
information in these hidden files. These files are named as follows:-

     .$fdl$name-of-file.name-of-tail[;version-number]

for a backup file with a block size of 8192, the FDL file contains the
following:-

FILE
        MAX_RECORD_NUMBER 8192
        ORGANIZATION sequential
RECORD
        FORMAT fixed
        SIZE 8192

I think most shells appreciate the $ characters being escaped when typing
in the file names.

There is a gotcha though - If you have more than one version of a file,
there is a file name associated with each of the versions (plus its FDL
'friend') with the name having the (;n...) semi-colon and version number.
The file name with no version number is hard linked to the lastest
version of the file. So, if you TAR the area, your TAR file will be
larger than it needs to be because of the hard link!

Making and restoring image backups of non-system disks should work fine -
I would suggest for all backups to NFS, that you pick a reasonable block
size, like 8192, the same as is used by default for tapes. If you have a
major problem, you could create VMS compatible tapes using your *nix box.

I have had no problem with vms backups over NFS. I have in the past had
problems with other file types, but it was so long ago, I don't remember
what it was (and it was on an earlier version of Multinet V3.something).
I currently use v4.0 as we stopped maintenance some time ago.

Don't take my word for any of this - check yourself that it all works OK.
Data is (should be) too valuable to gamble on the posting of a stranger
on a news group! :-)

Let me know how you get on.
Andrew.

Quote:>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<


regarding Re: VMS backup to NFS shares:

Quote:> > Multinet stores the FDL info in a hidden file (ie, one starting with a .
> > )
> > on an NFS server by default. So when the file is viewed from VMS, the
> > file attributes are correct.
> So unlike UCX (as pointed out in this thread) there's no need to
> specify a qualified like /ADF= since it's automatic? (Just wanting to
> make sure)
> > If you are doing and image followed by daily and weekly incremental
> > backups, you will have to work out some method of restoring the image
> > backup (if it is the system disk).
> I'm going to use our old TZ86 to back up the system disks and then all
> the user/application data is on other disks.  I can use backup/image
> across NFS for the disks that aren't the system disk though correct?
> > To read a saveset, I just copy one off the DVD into an area readable by
my
> > VAX over NFS, gunzip it, create the hidden FDL file and then use backup
> > on the VAX.
> And all the files restored correctly?  Terrific.
> Thanks for the insight into Multinet.  And thanks to everyone else who
> had some ideas.  It's much appreciated.
> -- Jason

 
 
 

VMS backup to NFS shares

Post by David J. Dachter » Wed, 02 Jul 2003 11:45:19



> I was hoping that a VMS guru could answer a question for me.  I have a
> VAXStation 4000 90A and I'm attempting to get a usable backup solution
> for it.  The tape unit I've been using on it requires a data stream
> speed that the VAX simply can't keep pushing out to the unit and it's
> casuing physical damage.  [snip]

Whoa, there!!!

Care to elucidate???

How can BACKUP be causing physical damage to a tape, drive, etc. ???

--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

 
 
 

VMS backup to NFS shares

Post by Jason McCormi » Thu, 03 Jul 2003 04:57:55


Quote:> > I was hoping that a VMS guru could answer a question for me.  I have a
> > VAXStation 4000 90A and I'm attempting to get a usable backup solution
> > for it.  The tape unit I've been using on it requires a data stream
> > speed that the VAX simply can't keep pushing out to the unit and it's
> > casuing physical damage.  [snip]

> Whoa, there!!!

> Care to elucidate???

> How can BACKUP be causing physical damage to a tape, drive, etc. ???

 According to the vendors of the unit, if the VAX isn't pushing out
enough data to fill the stream for continuous writing, the tape drive
back-catches and stops and starts, etc. over and over.  They claim
that this puts an enormous amount of wear and tear on the tapes and
heads inside the unit and the repeated failures I'm seeing is the
result of this.  I have an identical unit on a large, fast server with
an LVD card and the unit has performed flawlessly.  The combination of
a slower unit and the SCSI-1 is appearantly not enough to support the
unit. They've actually gone as far as to replace the entire unit so I
know it's not a lemon unit.  I've been dealing with this issue for 3
years so I'm trying to remove the tape unit from the equation.
 
 
 

VMS backup to NFS shares

Post by Andrew Balaa » Thu, 03 Jul 2003 05:46:08


We've had repeated problems with both DAT and 8mm Exabyte units over the
years - the VAXstations we have are just not fast enough to get these
drive streaming, so they have to keep starting, stopping and going back.
8mm Exabyte are worse - the system was really designed for video, not
data - too much of the tape is wrapped around the head. Writing file
markers is very slow - and with the VMS using ANSI labelling, the label
itself is a file as I recall.

tape position lost errors were quite common.

Quote:>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<


regarding Re: VMS backup to NFS shares:
Quote:> > > I was hoping that a VMS guru could answer a question for me.  I have a
> > > VAXStation 4000 90A and I'm attempting to get a usable backup solution
> > > for it.  The tape unit I've been using on it requires a data stream
> > > speed that the VAX simply can't keep pushing out to the unit and it's
> > > casuing physical damage.  [snip]

> > Whoa, there!!!

> > Care to elucidate???

> > How can BACKUP be causing physical damage to a tape, drive, etc. ???
>  According to the vendors of the unit, if the VAX isn't pushing out
> enough data to fill the stream for continuous writing, the tape drive
> back-catches and stops and starts, etc. over and over.  They claim
> that this puts an enormous amount of wear and tear on the tapes and
> heads inside the unit and the repeated failures I'm seeing is the
> result of this.  I have an identical unit on a large, fast server with
> an LVD card and the unit has performed flawlessly.  The combination of
> a slower unit and the SCSI-1 is appearantly not enough to support the
> unit. They've actually gone as far as to replace the entire unit so I
> know it's not a lemon unit.  I've been dealing with this issue for 3
> years so I'm trying to remove the tape unit from the equation.

 
 
 

VMS backup to NFS shares

Post by Rob.Bux.. » Thu, 03 Jul 2003 09:44:06


On Mon, 30 Jun 2003 21:45:19 -0500, "David J. Dachtera"



>> I was hoping that a VMS guru could answer a question for me.  I have a
>> VAXStation 4000 90A and I'm attempting to get a usable backup solution
>> for it.  The tape unit I've been using on it requires a data stream
>> speed that the VAX simply can't keep pushing out to the unit and it's
>> casuing physical damage.  [snip]

>Whoa, there!!!

>Care to elucidate???

>How can BACKUP be causing physical damage to a tape, drive, etc. ???

>--
>David J. Dachtera
>dba DJE Systems
>http://www.djesys.com/

>Unofficial Affordable OpenVMS Home Page:
>http://www.djesys.com/vms/soho/

It's becoming quite a problem for a number of architectures. There are
reports of the newer SDLT Drives wearing out far quicker than the MTBF
figures suggest because of what is termed "showshining".
 
 
 

VMS backup to NFS shares

Post by David J. Dachter » Thu, 03 Jul 2003 10:37:43



> > > I was hoping that a VMS guru could answer a question for me.  I have a
> > > VAXStation 4000 90A and I'm attempting to get a usable backup solution
> > > for it.  The tape unit I've been using on it requires a data stream
> > > speed that the VAX simply can't keep pushing out to the unit and it's
> > > casuing physical damage.  [snip]

> > Whoa, there!!!

> > Care to elucidate???

> > How can BACKUP be causing physical damage to a tape, drive, etc. ???

>  According to the vendors of the unit, if the VAX isn't pushing out
> enough data to fill the stream for continuous writing, the tape drive
> back-catches and stops and starts, etc. over and over.

This is going to be true of any streaming tape drive.

Quote:> They claim
> that this puts an enormous amount of wear and tear on the tapes and
> heads inside the unit and the repeated failures I'm seeing is the
> result of this.

Pure, un*erated horse-shit!

The only cause attributable to this would be tapes that shed
excessively, and that's going to contaminate *ANY* drive, regardless of
how much start/stop goes on.

Quote:> I have an identical unit on a large, fast server with
> an LVD card and the unit has performed flawlessly.  The combination of
> a slower unit and the SCSI-1 is appearantly not enough to support the
> unit.

I'd "blame" SCSI-I first, but only after exhausting all other
possibilities. I had SCSI-I drives direct-connected to small VAXes
before, with no appreciable problems.

You *HAVE* tuned your "backup" account for the requirements of the
BACKUP utility, right? Huge working-set? Lots of FILLM, DIOLM, BIOLM,
etc.?

Quote:> They've actually gone as far as to replace the entire unit so I
> know it's not a lemon unit.  I've been dealing with this issue for 3
> years so I'm trying to remove the tape unit from the equation.

Go ahead and replace it with something better then. The VAX is not the
problem, the drive is: it can't take it, so it doesn't deserve to be in
your equipment room.

--
David J. Dachtera
dba DJE Systems
http://www.veryComputer.com/

Unofficial Affordable OpenVMS Home Page:
http://www.veryComputer.com/

 
 
 

VMS backup to NFS shares

Post by David J. Dachter » Thu, 03 Jul 2003 10:43:20



> On Mon, 30 Jun 2003 21:45:19 -0500, "David J. Dachtera"


> >> I was hoping that a VMS guru could answer a question for me.  I have a
> >> VAXStation 4000 90A and I'm attempting to get a usable backup solution
> >> for it.  The tape unit I've been using on it requires a data stream
> >> speed that the VAX simply can't keep pushing out to the unit and it's
> >> casuing physical damage.  [snip]

> >Whoa, there!!!

> >Care to elucidate???

> >How can BACKUP be causing physical damage to a tape, drive, etc. ???

> It's becoming quite a problem for a number of architectures. There are
> reports of the newer SDLT Drives wearing out far quicker than the MTBF
> figures suggest because of what is termed "showshining".

Ours (SDLT-320, 16MB/sec uncompressed) are fed via fibre-channel
(100MB/sec). I don't see this as a problem.

One caveat I will offer, however: Quantum SDLT-320s do not appear to be
100% VMS-compatible out of the box. I have 12, and can presently only
use seven(7) of them due to parity errors, errors positioning the tape
and just general "flakiness".

Sure wish I could convince my VAR to swap 'em out for HP-badged drives!

--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

 
 
 

VMS backup to NFS shares

Post by Bob Koehl » Thu, 03 Jul 2003 22:06:00



Quote:

>  According to the vendors of the unit, if the VAX isn't pushing out
> enough data to fill the stream for continuous writing, the tape drive
> back-catches and stops and starts, etc. over and over.  They claim
> that this puts an enormous amount of wear and tear on the tapes and
> heads inside the unit and the repeated failures I'm seeing is the
> result of this.

   On the one hand the data flow issue is nothing new.  It first poked
   it's head up when streaming 9-tracks were attached to VAX 8200.
   BACKUP got a lot of work in the area of performance just after.  You
   might want to look at the recommended account parameters for the
   account being used for BACKUP since a lot of the solution is in
   memory consumption.

   On the other hand I wouldn't expect a tape drive vendor to sell me a
   tape drive that wasn't robust enough for the environment I was
   planning to use it in.  Does this vendor list VAXen as supported
   systems for this drive?

 
 
 

VMS backup to NFS shares

Post by Jim Agnew - VCU/MCV Neurosurger » Thu, 03 Jul 2003 22:34:19


Actually, the 8mm units if you have the correct microcode/firmware in
them, they last us for years...  'course we tuned backup to the limit,
with an entire vaxstation dedicated just to backup...

jim


> We've had repeated problems with both DAT and 8mm Exabyte units over the
> years - the VAXstations we have are just not fast enough to get these
> drive streaming, so they have to keep starting, stopping and going back.
> 8mm Exabyte are worse - the system was really designed for video, not
> data - too much of the tape is wrapped around the head. Writing file
> markers is very slow - and with the VMS using ANSI labelling, the label
> itself is a file as I recall.

> tape position lost errors were quite common.

> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<


> regarding Re: VMS backup to NFS shares:

> > > > I was hoping that a VMS guru could answer a question for me.  I have a
> > > > VAXStation 4000 90A and I'm attempting to get a usable backup solution
> > > > for it.  The tape unit I've been using on it requires a data stream
> > > > speed that the VAX simply can't keep pushing out to the unit and it's
> > > > casuing physical damage.  [snip]

> > > Whoa, there!!!

> > > Care to elucidate???

> > > How can BACKUP be causing physical damage to a tape, drive, etc. ???

> >  According to the vendors of the unit, if the VAX isn't pushing out
> > enough data to fill the stream for continuous writing, the tape drive
> > back-catches and stops and starts, etc. over and over.  They claim
> > that this puts an enormous amount of wear and tear on the tapes and
> > heads inside the unit and the repeated failures I'm seeing is the
> > result of this.  I have an identical unit on a large, fast server with
> > an LVD card and the unit has performed flawlessly.  The combination of
> > a slower unit and the SCSI-1 is appearantly not enough to support the
> > unit. They've actually gone as far as to replace the entire unit so I
> > know it's not a lemon unit.  I've been dealing with this issue for 3
> > years so I'm trying to remove the tape unit from the equation.

--
"4,000 years ago I made a mistake."  Elrond Half-Elven, in "Fellowship
of the Ring"

"I try not to be right any more than necessary". -- Larry Wall, author
of the Perl Language

 
 
 

1. VMS server file sharing with W2K clients: NFS and Pathworks grief

Hi,

We're looking for file sharing solutions in an evolving VMS + W2K
network.

We have implemented for some time Pathworks V5.0F ECO 2 with a
Compaq-supplied patch that enables it to work with earlier W2K systems.
However, Service Pack 2 or higher for W2K (which presumably means XP
too) breaks authentication. This is a known problem and the recommended
fix is apparently to upgrade to Pathworks 7.

Well, licensing for Pathworks 7 would be rather costly, so we're looking
for a reliable low-cost solution to offer file shares from VMS to W2K
clients.  Any suggestions?

We initially thought perhaps we could use NFS and tried VMS 7.2-1 and
TCP/IP 5.1 ECO 2 with all the latest patches as our NFS server.  But
we've had nothing but grief trying to get it to fly.

For the client side, we're using Windows Services for UNIX 2.0 which
includes Microsoft NFS Gateway.  We have been unable to even connect
using that product and TCP/IP Services 5.1.  We have also tried a
variety of other NFS clients on W2K all with similar results, including
Hummingbird (tried both NFSv2 and NFSv3).

Just as a point of reference, we tried a Linux client to ensure that the
VMS NFS server was functional, and found that it could connect as an
anonymous NFSv2 user without any trouble.  (Ideally, we would like
username mappings, but are starting out simple, testing with just the
anonymous user.)

Compaq tells us that they use Hummingbird NFS clients with the same
versions of VMS and TCP/IP as we are trying without any trouble and have
concluded that it "must be a Windows problem" and have referred us to
Microsoft.  My Windows technical people here tell me that getting help
out of Microsoft isn't going to be easy or cheap.  My hunch is that
they'll end up pointing their fingers back at Compaq.

So where do we go from here?  Has anyone implemented a VMS server + W2K
client file sharing solution successfully that doesn't require forking
out hefty license fees for a Pathworks upgrade?  Are there alternatives
we have overlooked?

Ben Armstrong
p.s. Yes, I know there is a Samba for VMS.  But I understand that it
     has its own authentication issues with W2K.  Not that this
     entirely rules it out for our purposes, but we're concerned, given
     how much effort we've put into NFS so far with no success yet,
     about switching ships mid-channel, how much time it will take,
     and compounded with that, how much functionality we'd have to give
     up (that last one a moot point if it turns out to be the only
     viable solution ;)
--
      Ben Armstrong                -.       Medianet Development Group,

      <URL: http://www.dymaxion.ca/>    `-  Halifax, Nova Scotia, Canada

2. xsl in html

3. I am unable to mount in VMS a NFS share on my HP9000 D390

4. Major Notes Releases

5. VMS <-> UNIX data sharing: NFS performance known?

6. Major OS/2 Applications List (V3.0)

7. exporting NFS shares from VMS to Linux

8. No IOS Image on AP350 after upgrade

9. Q: UCX NFS Client and Multinet NFS Server w/ NFS group defined

10. UCX NFS VMS BACKUP of UNIX Files

11. Can't write to TCPIP 5.0A NFS share from UCX 4.1 ECO 8 client

12. VMS NFS and PC-NFS (Reflexion)