Samba on VMS

[John E. Malmberg]

From: Dan Kaminsky <effugas at best.com>

> On the subject of the VMS port, I'm curious how well Samba performs on
> VMS?  How decently does it scale?  What special admin-level issues come
> into play?

I have not played with SAMBA-VMS on large VMS sites, just my home hobby
system.
I do not have 2.0.6 fully running yet, I am having some connection timeout
problems that I have not isolated yet.  (Right now the paying job is tying
me up for quite a bit of overtime)  Unfortunately I do not have one of those
jobs where I am paid to write Open Source code. :-(

On the SAMBA-VMS list, the majority of users are running an older version,
and there have been some complaint that it is slow.  Not having access to
their systems, or a detailed analysis, I can not say why it is slow.  I do
see a number of improvements in the 2.0.x base that may help.

There are a number of stupid VMS sysadm myths that are followed by some that
will kill performance, and again, I do not know if they come in to play.  I
posted some tuning suggestions on the SAMBA-VMS list and got no feedback at
all.


The mainstream OpenVMS beta port of 2.0.3 does not support oplocks or
encrypted passwords.  This is also a major limitation.

The oplocks issue is because fcntl() for file record locking is not
implemented in OpenVMS.  I have written a routine that looks like it works,
but there are a lot of side effects that result from it, and I need to
verify how this affects SAMBA'S usage of files.


Scaling should be no problem based on what hardware that the site has.
OpenVMS does not have many limits on that.  The largest and fastest search
engine on the WWW today is running OpenVMS.  No, it is not AltaVista, that
one runs TRU-64.  See http://www.nlsearch.com

> There are more than a few companies, I'm sure, who literally migrate their
> entire IS systems just so they can feed some files into Microsoft Clients
> more conveniently.  A quick writeup about what Samba on VMS is like might
> be useful to some.

The competition for SAMBA in the OpenVMS market is a Product from Compaq
named Pathworks.  The last time I looked up the license prices, it was about
$90 - $120 per client connection, depending on the quantity purchased.  In
some cases posted on comp.os.vms it is reported as slower than an NT server
running on identical hardware.

The Pathworks product also does not have anything as the equivalent of
SMBCLIENT functionality.

SAMBA-VMS is known to run on OpenVMS 5.5-2 on up to the current version of
7.2-1.

Pathworks 6.0x as I currently understand it is available for OpenVMS 6.2 and
higher.  It makes the OpenVMS system appear to be a NT 3.51 server.

There is also a Pathworks 7.x for OpenVMS 7.2 and higher.  I do not have any
experience with that version.

For OpenVMS 5.5-2, and later the PATHWORKS 5.0 product is available.  It
basically is Windows-For-Workgroups that can somewhat pretend to be a server
or a domain controller.  As it is Windows-For-Workgroups based, it will not
interoperate with an NT domain with more than 251 groups defined.

It is my understanding that the Pathworks programs are based on code and
other information licensed from AT&T Globalsys, and that AT&T license that
code from Microsoft.

As I have only a personal desire to be running SAMBA on OpenVMS, and not a
business need, and I want to use the features not in the main line port, I
am taking advantage of OpenSource to make it so.

What I am doing is a slightly different approach to a port than the main
SAMBA-VMS group.  Both them and I are now using a shared image wrapper
library for functions that SAMBA needs and OpenVMS does not provide in their
C run time library.

The main difference there is that I have prefixed all of the routines in
mine with a unique 7 letter code to avoid namespace problems.  I also added
quite a few additional routines for some functions that SAMBA uses, and
tried to be closer to The Open Group's official specification.

I have also used some tricks with C macros in config.h, where by use of the
complier defining a symbold of MOD_<module_name>, I can change the behavior
of how a specific routine calls another with out patching the source.

The idea is that I will not have to spend as much time trying to synchronize
changes from one UNIX version of SAMBA to another.

With these added routines, I currently have only 2 #ifdef __VMS required in
the basic UNIX code.  I know that at least one more will be needed based on
analysis of the mainstream OpenVMS port.


The first one is because OpenVMS file locking will only work on records that
exist, so calling fcntl on a non-existant record has to do an extend, or not
take out a lock at all.

The second is in smbclient.  Control-Z is the typed in OpenVMS where you
would type ^D in Unix.

The third will be that OpenVMS users will expect that SMBSTATUS would report
process id's in hexadecimal.

Once I discover why this connection timeout is occuring, I should be able to
move much faster in getting the feature parity working, and using the
OpenVMS run-time profiler to find the hot spots in the program to look at
any performance issues.

One I have something running, I plan to write up a detailed analysis of what
it took.  I am keeping a change journal of my progress.

For 2.0.6 on OpenVMS:

NMBD, NMBLOOKUP, MAKECODEPAGE, TESTPARMS running with NO source patches at
all.

SMBCLIENT, running poorly with one source patch, it keeps dropping
connections after about 1 minute.

SMBD is timing out during connection dialogs, and I need to put in some more
OpenVMS specific tweaks for user authentication.

RPCCLIENT will require a patch.  It does not have LIB_READLINE support, and
OpenVMS does not implement the extension to the socket library that allows
socket calls to be used on non-socket channels.

-John
wb8tyw at qsl.net