Name: Joshrandom Date: October 21, 2004 at 11:51:27 Pacific Subject: DEC Pathworks V4.0 and WFW 3.11 OS: WFW 3.11 CPU/Ram: 486 16Mb
Comment:
At our company we have a small network running on an old VAX/VMS server using Pathworks version 4.0, this system has been quietly and effectively running for years, and so I have no intentions of making any changes to it directly. However it would be very useful if I could link it with our main network running on windows98 and XP systems. I doubt that it is practical to attempt to connect these systems directly, so I thought I would attempt to use a windows for workgroups 3.11 system to connect to both networks. The networks.wri file in wfw3.11 suggests that it is possible to connect to both Pathworks and windows networks but doesn't explain how. I have found references to files that tell you how to do it, but the actual files themselves don't seem to exist anymore. I have played with different configurations and can get a connection to the VAX through windows, but only when Netbeui and ndishlp.sys fail to load. Any help would be appreciated.
We have a number of manuals for the VAX and for Pathworks, we also have the discs to install Pathworks client onto a PC. However, the documentation only refers to windows 2.0 and windows 3.0, so guess it must date from the very early 1990's or late 1980's.
That sounds reasonable. It has been a long while since Pathworks 4 was current, and I would be cautious until I details have been verified.
My best guess, without looking for the manuals and spending some time digging through them, is that the server MIGHT be able to interroperate with current clients which are not running Pathworks specific software, at least to the extent of providing file access. If not, the files could also be accessed by switching to a later version of Pathworks (and VMS) which do provide such support (or a variety of other techniques to access the files).
Is the need for access ongoing? Or is it a one shot conversion requirement?
However, there are limits to the amount of research that I can feasibly do gratis as a public service. Unfortunately, my public service budget would be obliterated if I took the extended time necessary to get a definitive answer.
Thanks for taking the time to try and help me with this problem Bob. After searching the internet for a solution I have come to realise that this would have been an obscure problem even 10 years ago, when people knew about Pathworks v4.0. Having said that I've come to believe that the problem is with wfw 3.11 and its 32-bit file access system. I still have a few more option to try, I believe DEC produced an integration kit to solve this problem, but I haven't been able to track it down yet.
The reason that I want to connect a PC to both the VAX and windows networks is to allow data to be loaded onto the VAX (which runs software that processes that data and then plots it on a laser photoplotter) from a windowsXP system, without having to use floppies, which can be a pain if the data files are bigger than 1.44Mb. Since the VAX does its job faultlessly and because I have no experience with VAX VMS, I have no intention of attempting any changes or upgrades to it, I'd rather stick with the floppies than risk damaging this system.
Another possibility is to use a serial link and a no-cost (or low cost) program (e.g., Kermit).
It will take a while to transfer a large data set, but the combination of ZIP and Kermit, can reliably transfer very large files over a simple serial interface at a speed faster than the process of writing multiple floppy disks.
Provided adequate space is available on both sides of the connection, I have transferred multiple megabytes of data. When you count the time and effort involved in dealing with multiple floppies, the serial speed of 9.6K or 19.2K is actually faster than the floppies. The use of ZIP allows you to transfer entire directory trees with a single transfer.
If you are able to use a version of C-Kermit, with the sliding window support, the average speed is improved.
There is an PW 4.1 implementation guide at : http://groups.google.com/groups?selm=coert.744630193%40athena.research.ptt.nl (long URL, may wrap). I don't know if this also works for 4.0.
If you only want to do file transfer, another option may be to install Decnet on the PC (assuming you have it on the server as well). There was a Pathworks utility to copy files using Decnet, I believe it was called NFT (network file transfer ?). Commands where like C:> NFT COPY filename VAXNAME"userid"::
Indeed. If Josh was talking about a transfer from the WFW 3.11 systems to the VAX, that would work.
The problem, according to his last posting, is to more data from a current Windows XP system (which does not, presumably have DECnet from his previous postings), to the VAX.
One possibility, to be sure, is to make the data on the Windows XP box a share readable to other NETBUEI machines. Then, in theory, if the WFW 3.11 machine can access the share, a simple copy, either of the drag and drop variety, or DECnet NFT file transfer can access the data on the XP machine as if it were a local file on the WFW machine.
I do not want to put words into Josh's mouth, but his description of the problem seemed to indicate a lack of connectivity between the WFW and XP systems, and a desire to minimize the costs and effort involved. Hence my reminder to go back to basics and see if KERMIT and a serial line address the problem.
I do not say that KERMIT is the best solution, but it is a solution to this type of problem that is often ignored, much to people's detriment.
The direct serial connection will be my next port of call if I fail to connect these networks using WFW. I will look into KERMIT and find out how to implement it with our systems, thanks Bob.
Thanks Erensm, for that link, it may come in useful. I had found some similar instructions which I had used to set up the system I described above. However these instructions are for configuring WFW3.1, not WFW3.11, to work with Pathworks, and apparently there are enough differences between these two versions that this configuration does not work. Although it does allow me to connect to the VAX using the windows network redirector when ndishlp.sys fails to load. When it loads I lose the ability to connect to the VAX but can connect to the XP system. However I have now been able to track down a rare copy of the WFW3.1 installation disks and so I will make a last attempt using these and the configuration described at the above site.
I think your best bet might be to create a dual boot system if feasable. Store the files from your Windows network locally, then reboot, log onto the VAX via Pathworks, and transfer the files. I use this method to transfer files from my old VAX via Pathworks 4.1 to my existing Win2K network.
I run pathworks v4.1 on vms 5.5-2 and pathworks v5 on a alpha running v7.1. I can connect to win NT4, win 2000, pathworks v4 and v5 servers from MSDOS, Win 3.11 (not Windows for workgroups), win95, win98, win98se, winnt 3.51 and winnt 4 SP6 clients. If you want to connect to VMS systems with win 2000 or XP you must upgrade to pathworks v6. There are system requirements for this on the HP site in the "ask the vms wizard" area.
Actually I've been running OVMS on a LAVC consisting of 2 4000-50 (Nemonix Brick Upgrades) and 1 VAXStation 3100 m76. One node runs the license server at V 5.06f. The guys at HP slipped me a set of drivers that allows me to map network drives to a service running on the VAX. I'm running the same mapped drives to IBM PC DOS 2000/Win3.1 Windows 98SE, Windows 2000, and XP with no problems. You can only utilize the mappings in XP by supplying the workstations with the older licenses. (DEC-PWLMDOS06.00 and DEC-PWLMXXX07.02)
The information on Computing.Net is the opinions of its users. Such
opinions may not be accurate and they are to be used at your own risk.
Computing.Net cannot verify the validity of the statements made on this site. Computing.Net and Computing.Net, LLC hereby disclaim all responsibility and liability for the content of Computing.Net and its accuracy.
PLEASE READ THE FULL DISCLAIMER AND LEGAL TERMS BY CLICKING HERE