vms_tdb.c modifications

[John E. Malmberg]

On Thu, 26 Jun 2003, Dave Jones wrote:

> The port will be different in the approach taken to resolve incompatibilities
> the Samba code has with the VMS environment.

A wrapper shared image can be used with more than just SAMBA if it is done
correctly.

>  For example, the Samba code
> assumes the st_dev and st_ino is a stat struct fields are scalars, but in VMS
> they area char pointer and an array.

The last time I looked at the SAMBA code, st_dev was not supposed to be
used as a type, it was suppose to be using a SAMBA specific typedef or
macro that was defined in config.h.

If you only want to support current and future ALPHA/IPF, you can have
st_ino as a compile time option with the current C RTL.  This is the same
for supporting the large files.

> The traditional approach is to locate all the places throughout the
> code with this assumption and apply an approriate
> work-around with #ifdef's.  Another approach is to adjust the
> environment so the stat struct has compatible data types that require no
> changes to the C source module itself.  In this case, the stat wrapper for
> VMS would stuff the 48 bits of file ID into a 64 bit integer and dynamically
> build a shared, persistent table to map device names to unique 32-bit
> integers.

Or tell SAMBA that the ino_t type is 64 bits in the ino_t, but that will
only work for Alpha.

I ended up with a TPU macro that will replace the references to the ino_t
with a couple of C macros.  For OpenVMS the macro would use memset() and
memcpy(), otherwise it used = or ==.  The SAMBA technical team seemed to
be willing to put that type of macro in their code and let a test in the
configure script manage it.  But so far the TPU macro seems to do a good
job.  It has done the right thing on every release of the SAMBA and RSYNC
modules that I have run through it.

I use a search list for local source/objects, cms reference for OpenVMS
modules, and then readonly access to the UNIX source.

What I need is RSYNC to work so that I do not have to periodically replace
the UNIX source with fresh FTP copies.


The other thing that I do is that in the CC compile statement, I define a
macro that is "MOD_FOO" where "FOO" is the module name.

Then in the config.h file, I can put:

#ifdef MOD_FOO
#define load_params vms_load_params
#endif

This changes module foo and only module foo to call the VMS specific
routine with out modifying either the FOO.C or the module that load_params
is in.

It is a way of making code patches with out editing the code.

> Another area where it is different is that I'm not defining a TCPIP service
> to start the samba processes.  I have my own listener daemon that manages a
> pool of processes that are handed connections when they come in (similar to
> the way Apache 1.x works).  In development mode, the workers are spawned,
> rather than created detached, so I see the tracebacks on the screen
> immediately when it crashes. (BTW is it possible with "$ TCPIP show
> device/full" to verify that the NODELAY socket option is in effect?).

That should be a big speed up for connections.

I do not know about the NODELAY socket option.

-John
wb8tyw at qsl.network
Personal Opinion Only