Possible TDB/Samba optimizations.

[COLLOT Jean-Yves]

> I had not determined if the better approach to be would be to have
> routines that used the TDB API, so that the UNIX SAMBA code would not
> need to be changed, or if it would be better just to replace the UNIX
> routines with OpenVMS specific routines.

I think that the current TDB processing is OK for most usages (CONNECTIONS,
PRINTING, etc...). Only the locking processing would be far better with the
distributed lock manager. 
If we want to minimize the changes and the specifics in the standard Samba
code, my opinion is that the best way to do that would be to completely
rewrite the LOCKING.C and BRLOCK.C modules, keeping their current external
API specs.
One the main issues, I think, would be to define how the lock manager will
be used, because the amount of information currently kept in the TDB file is
far bigger than the available 16 bytes of the lock value block.

> Moving the sharing and locking TDB functions to the distributed lock
> manager would eliminate one of the known bugs in SAMBA from the OpenVMS
> platform.
> If a SMBD process crashes at the wrong time, those TDB databases have
> stale data, and need to be manually repaired.  

That's true, but I think that the main advantage would be in the performance
area, for example when you right-click "Properties" in the explorer. This
action remains extremely long with Samba/VMS, and approximately 20% of this
time is due to the locking TDB processing.