[Info-vax] Pathworks or one of its descendants on x86

[Jan-Erik Soderholm]

Den 2018-02-21 kl. 05:40, skrev terry-groups at glaver.org:
> On Tuesday, February 20, 2018 at 7:40:05 AM UTC-5, Kerry Main wrote:
>> For something like Samba, the native file system and TCPIP stack are 
>> critical components of the overall solution.
>> 
>> Lets not forget that an entirely new, more modern TCPIP stack and
>> file system will also be part of the upcoming OpenVMS X86-64 equation,
>> so comparing OpenVMS Samba X86-64 performance to the past is not
>> likely much of a comparison.
> 
> I have always run Multinet which likely performs better than UCX or
> whatever its nom du jour is. I believe the slow file serving performace
> was mainly file-system related, anyway.
> 
>> New OpenVMS file system notes: 
>> <http://www.hp-connect.se/SIG/New_File_System_VMS_Boot%20Camp_2016.pdf>
>
>> 
> Those slides say "Fully compatible API − 99% of applications run without
> modification" which I interpret as meaning RMS or RMS emulation. If that
> is the case, any file-serving to PC clients is going to need to do the
> same "if it isn't fixed-512, read the file a record at a time and munge
> the record attributes" that PATHWORKS did before sending it to a PC
> client. I think I'll stick with my "an inefficient choice for anything
> other than accessing files that must reside on the VMS system" comment
> until convinced otherwise.
> 

I have never seen file serving from VMS as anything but a convienient
way of sharing files that was either created on VMS, or was needed
by something on the VMS system. For a general "file server", there
was easier solutions.

Was using VMS for file sharing/serving since PCSA 1.2 or 2.0 (I think).