vms_tdb.c modifications

[Jan-erik Söderholm (QAC)]

OK. To be clear, *I* don't want or need another
version/kit/distrubution/site/whatever. As I have
said to Jean-Yves directly, I will probably
continue to get my SAMBA kits from his site, since
they have proved to be working "out-of-the-box".

And, as I also said to Jean-Yves, as a long time
user of the OSU server I have the greatest
respect for your programming skills, Dave. That is
not the issue here, it's the coordination between
what you are doing and Jean-Yves current kit. And
the *risk* of having another source for download
of the SAMBA/VMS kit.

And thanks for the "internals" of your current work,
I'm sure that they whould make SAMBA/VMS better and
I understand at least *some* of it :-)

Jan-Erik.







-----Original Message-----
From: Dave Jones [mailto:JONESD at er6s1.eng.ohio-state.edu]
Sent: den 26 juni 2003 17:22
To: Jan-erik Söderholm (QAC);
"'samba-vms at lists.samba.org'"@er6s1.eng.ohio-state.edu
Cc: JONESD at er6s1.eng.ohio-state.edu
Subject: RE: RE : vms_tdb.c modifications


>You say that you are "working on a fresh port of 2.2.8",
>how will this "port" be different from the current 2.2.8
>port at the pi-net site ? Is that port "un-fresh" ?

The port will be different in the approach taken to resolve incompatibilities
the Samba code has with the VMS environment.  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 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.

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?).

I wouldn't call what I'm doing a 'version' yet.  I've got running code, but it
is a lot of work package it as a distribution that a significant portion of
people can build.