Conference decwet::windows-nt

Why not put PATHWORKS on OpenVMS and store the files there?

PJDM

This looks like a job for Pathworks 6 when it is released. Pathworks
V5 will do the job that you are asking. Just check the file/data 
formats that the customer is wanting to use ( maybe just try it on
your local friendly pathworks server). 

Pathworks = Lanmanger services for VMS....


Good luck,

Greg Harkness
Sydney CSC 

Well, PATHWORKS for OpenVMS(LAN Manager) will do what .1 is talking 
about, not necessarily *exactly* what .0 is asking for. It will not 
act as a client to an NT Server.

Pedanticaly yours

    					"Just the place for a Snark,
    					 I said it thrice,
    					 What I say you three times is true.."
    					Lewis Caroll, Hunting of the Snark
    
    Well in .0 I tried many times to repeat that OVMS is *CLIENT* and WNT is 
    *SERVER* I even put it note's header. The fact, that pathworks allow
    to export OVMS file system to WNT client is known to me, now
    I want to ask those guys, who adviced me to use pathworks 
    
    can OpenVMS with Pathworks V6 mount the file system from WNT Server ?
    
    (to be sure:
     disks with files are on the Windows NT server
     users are on the OpenVMS client
     users want access files on WNT server as easy as local files
     (EASY means NO FTP or other file transfer PLEASE !)
    )
    
    =Seva

    You might try asking in CPEEDY::PW-AS-V6.
    
    I think some other Advanced Server products do support this (but I
    don't have my SINIX AS/X system running now to check). If I'm not
    mistaken (but I often am ;-) PW V6 (at least for Digital UNIX) is based
    on the same code.
    

No. The PATHWORKS servers for OpenVMS, be it v5 or v6, has no 
workstation code that would allow this.

That said, there is a company (in the UK, I believe, I'll stop back 
with a URL when I get it) that does have a LAN Manager redirector for 
OpenVMS that does exactly this sort of thing.

I'll repeat my solution.

If you put the files on OpenVMS, you can export them to any Windows NT system. 
The users won't know whether the files are on Windows NT or OpenVMS, they'll 
just mount the share as usual. This way, both OpenVMS users and Windows NT users 
have complete access to the files, with no extra software (except PATHWORKS), no 
extra cost, everything supported, and easier than trying to get NFS to work.

Is there any particular reason why you don't want the files on the OpenVMS 
system?

PJDM

>I'll repeat my solution.
>
>If you put the files on OpenVMS, you can export them to any Windows NT system. 
  
    If you're the Customer I would agree with your solution.
    
>Is there any particular reason why you don't want the files on the OpenVMS 
>system?

    Yes, customer want to migrate to WNT . They have old VAX'en with OVMS
    and new Alphas with NT. They want to allow their CAD users that still 
    should work at old irons to access the brave new world they building
    on Alphas with WNT.

    =Seva
    

	I agree with .7.  The end result is the same as what you are asking
	for.  I know it does not do it in the way the customer is asking that
	it be done, but is he more interested in how it is done or in getting
	it done?

tgc

>>	I agree with .7.  The end result is the same as what you are asking
>>	for.  
    
    Hmmm.... End result. I hope you did read that customer want to get
    ride of old VAX'es and go to Alphas with NT. Then your proposal is:
    
    Let's remove all disks from Alpha File server and then let's connect
    them to VAX workstation. It is no matter that Alpha, that designated
    to be file server (CPU, Memory, FW SCSI etc.) will DO NOTHING. The
    VAX Workstation will do its work (CAD) and in the same time serve
    files from disks hanging on it's narrow and slow SCSI
    
    Great Idea !
    
>>           I know it does not do it in the way the customer is asking that
>>	it be done, but is he more interested in how it is done or in getting
>>	it done?
    
    
    OK I understood that NFS is the only solution.
    
    Thank You
    
    =Seva

	You can install NFS Server from Hummingbird on the NT System.  It's
  available for both Intel and Alpha.  Then they can use an NFS Client on the
  VMS systems to mount the disks.

		Danny

    re .11: errr... didn't he just say in .0 they had already tried?

    
    	Nice going, Danny ... the answers thus far weren't pissing him off
    	enough so you had to suggest that he try exactly what he was comp-
    	laining about in the first place.
    
    	8^)
    

    re: .0 by COL01::VSEMUSCHIN
    
    >> Could we do it easier ?
    
    I guess the real answer here seems to be NO.
    
    >> and probably will ask a question about customer's problem.
    
    So what is the real problem encountered in using "Hummingbird NFS
    server on WNT Server and UCX NFS client on Open VMS client?"
    
    /Bill

    re .14:
    
    >So what is the real problem encountered in using "Hummingbird NFS
    >server on WNT Server and UCX NFS client on Open VMS client?"
    
    Does NFS do any format conversion? I don't think VMS does too well e.g.
    with a raw DOS/NT text file...

>        Nice going, Danny ... the answers thus far weren't pissing him off
>        enough so you had to suggest that he try exactly what he was comp-
>        laining about in the first place.
>    
>        8^)
	I guess I should have reread the base note! :-)

		Danny

On one hand, you're saying that you're getting rid of the VAXen and just using 
Windows NT; from your .10:

    I hope you did read that customer want to get
    ride of old VAX'es and go to Alphas with NT.

On the other hand, you're saying that you're continuing to do work on your 
VAXen; also from your .10:

    The VAX Workstation will do its work (CAD) and in the same time serve
    files from disks hanging on it's narrow and slow SCSI

Presumably this is a transition period where you need to access these files both 
from OpenVMS and from Windows NT.

So, the real problem is not "how do I make NFS work?", but "how can the OpenVMS 
users and the Windows NT users access the files during the transition period?".

You solution is to copy the files to Windows NT and use NFS to share the files 
to OpenVMS, which apparently doesn't work.

An alternative solution is to use PATHWORKS on OpenVMS, which we know does work. 

Some more from your .10:

    It is no matter that Alpha, that designated
    to be file server (CPU, Memory, FW SCSI etc.) will DO NOTHING. The
    VAX Workstation will do its work (CAD) and in the same time serve
    files from disks hanging on it's narrow and slow SCSI

    Great Idea !

You didn't actually tell us that you would use a VAX workstation with a narrow 
slow SCSI as a PATHWORKS server, so saying "Great Idea!" helps nobody.

The Alpha designated as a file server need not do nothing. Install OpenVMS and 
PATHWORKS on it, and everybody (on OpenVMS and Windows NT) has access to the 
files with no problems. If the customer already uses OpenVMS, they might be 
willing to believe that OpenVMS is a better backend server than Windows NT 
anyway.

Again from your .10:

    OK I understood that NFS is the only solution.

It is if the problem is "What UNIX oriented network file system can I use 
to share files from Windows NT to OpenVMS?".

The answer to your question "Could we do it easier?" appears to be "yes", but 
you don't want to hear it.

PJDM

    Re .17, I already wanted to write another sarcastic note, but let's 
    forget about smiles and remember that we're in Real World.
    
    Dear PJDM, you wrote:
    
>>The Alpha designated as a file server need not do nothing. Install OpenVMS and 
>>PATHWORKS on it, and everybody (on OpenVMS and Windows NT) has access to the 
>>files with no problems. If the customer already uses OpenVMS, they might be 
>>willing to believe that OpenVMS is a better backend server than Windows NT 
>>anyway.
    
    'Install Open VMS and Pathworks on it' means:  customer have to pay us
    for 2-3 days for VMS/Pathworks installation and configuration and then
    for another 2-5 days  for  migration of VMS/Pathworks server (now with
    files) back  to  Windows NT. We're do business, not charity, you know.
    Of course we could give  him for this  time  temporary (trial) OpenVMS
    NAS and Pathworks PAK's. For  nothing.  It  is not our  official sales 
    policy, but it is possible.
    
    Of course customer could change his decision and make OpenVMS to be 
    backend server. Being myself a OpenVMS specialist I would like this
    decision.  But I think, that  decision maker at customer site would
    dislike it. OpenVMS as back end server means for him that he took a
    wrong decision and let  his employer to  pay to correct it (license
    fees -  conversion WNT -> OpenVMS cannot be happened for free - and
    service bill - 2 or more days see above). This can only happen when
    Windows NT  as  back end server will not work at all, what I doubt.
    Besides it I see no other reasons to let this person 'eat his hat'. 
    BTW  I  saw  many problems with pathworks V5 and only last vesrions 
    (ECO's) are work stable.
     
>>The answer to your question "Could we do it easier?" appears to be "yes", but 
>>you don't want to hear it.

    Yes, in general case you're right. It is possible, it is easy, it more
    realiable and more more performant. But it is not for this world ...
    
    =Seva
    
>>You didn't actually tell us that you would use a VAX workstation with a narrow 
>>slow SCSI as a PATHWORKS server, so saying "Great Idea!" helps nobody.
    
    Sorry I never  heard  about FW SCSI controller for VAX'en. Some newer
    3100  Series  models have SCSI-2, but FastWide ... Another possiblity
    would let'em to buy some DSSI/SCSI adapter's to use them some months.
    However DSSI is too old for race with FW SCSI ... When I thought about
    moving of disks to VAX'en I consider only such configurations. It was 
    a reason to call it 'Great Idea'. Did you have another Idea how to
    do it ?

    
    
    

    What about the original problem. Customer, when saving the second
    version of his file got the extension: .XYZ;2. Differently from OpenVMS
    WNT understood it not as 'file type .XYZ version 2' but 'file type .XYZ;2' 
    As resdult the WNT version of CAD Application could not found files
    after their type. I looks like, that customer simply misunderstood how 
    the UCX NFS client handle version numbers. Description of it I got on 
    LASSIE:: in UCX notes conference:
    
    ================================================================================
    Note 5253.2      ucx nfs client: creates files w/version numbers      
    LASSIE::CORENZWIT "stuck in postcrypt queue"         22 lines   20-FEB-1997 18:30
                              -< it depends, sort of... >-
    --------------------------------------------------------------------------------
    
    <... removed stuff see in the original note ... Seva>
        
        Assume you are using an editor that always defaults the version number,
        and you start with a file that has no version number.  When you exit
        the editor, the NFS client sees that you are trying to create a new
        file, but a file by that name already exists.  It does the best it can
        to help you by renaming the existing file to a ;1 name.  Then it writes
        the new file as ;2 and also creates a link to the ;2 file with no
        version number.  Now the UNIX host knows the file by its versionless
        name and by its ;2 name.  If you edit the file again, the versionless
        link is redirected to the ;3 file.
        
        Julie
    ================================================================================
    
    Now the customer is testing whether his application defaults version 
    numbers. If so the only problem he will have - he can purge old file 
    versions from VMS Client only. And NFS mix can be accepted.
    
    =Seva
    
      

	Boy, I guess we should have asked a lot more questions about what you
	were trying to do before we started offering any suggestions.  Every
	response changes the playing field significantly.  So, here goes:

	How much data are we talking about?
	What are the hardware configurations?
	How long do the systems have to co-exist?
	How much data will the VAX workstations have to access on a regular
	basis?
	How quickly can the VAX users move to NT workstations?
	Can the VAX users' data be moved overnight to the NT workstation?
	...

	Without this sort of information, I am afraid to make any more
	suggestions.

tgc

.6: 
> No. The PATHWORKS servers for OpenVMS, be it v5 or v6, has no 
> workstation code that would allow this.
> 
> That said, there is a company (in the UK, I believe, I'll stop back 
> with a URL when I get it) that does have a LAN Manager redirector for 
> OpenVMS that does exactly this sort of thing.

Vector Networks
http://www.vector-networks.co.uk/

though I can't find mention of this particular product on their website.

Let us know if Vector's product(s) work for you/your customer.

>>Vector Networks
>>http://www.vector-networks.co.uk/
>>
>>though I can't find mention of this particular product on their website.
>>
>>Let us know if Vector's product(s) work for you/your customer.
    
    It is very interesting idea, I would inform customer, and I will
    remeber it for the next time, since I think, that this should
    be easier (and cheaper) to configure VMS with LM redirector as
    to configure both NT and VMS with NFS.
    
    However in this particular case the customer is almost tamed
    after he begun to mount NFS from VMS client with /ADF qualifier.
    Then he got exactly the effect, that was described in UCX notes
    conference. 
    
    Next week I will contact customer still one time.
    
    Thanks to all.
    
    =Seva

    This is likely to become more of an issue, not less. One of the needs
    for this kind of functionality is serving CDROM Jukeboxes, CD-R
    mastering systems, etc, from NT systems to the OVMS systems.
    
    The required SW to drive these devices does not exist on OVMS, and is
    not likely to ever exist on it. An NT based platform is the only
    reasonable server.
    
    So - Either a good way is found to allow OVMS to access these servers, 
    or the customers who need this functionality write off VMS completely.
    
    More ideas are welcome.....
    
    Chris 

    The free utilities mentioned in hackers (from W. Moeller in Germany)
    allow using PCs to serve CDs, jukeboxes, etc. from PCs to VMS,
    though those are directed more at msdos/w95.
    
    There are remote tape/disk images on the freeware CD (V3) that
    do remote tape/disk over tcp/ip and whose clients need pretty
    well only block access to the devices. A port to NT of those
    functions is, shall we say, not beyond invention.
    
    Currently, driving "funny" iron is simplest from msdos or W95;
    NT drivers seem to come later. Thus the freebies mentioned are
    generally better at remote-ing the access to hardware for you
    than the stuff that needs a TCP/IP stack.
    
    Still, Chris is absolutely right: client access to devices on
    PC type iron is important and will become more so. Mentioning that
    what's around is at least more than the null set can't hurt,
    though it won't help much if someone wants formal support etc.
    Glenn