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.
Connections is one that I would want to move to use the LOCKING code. Connections must be removed from the table if a SMBD process crashed.
Cleaning out the connection file was one of the pains while debugging the 2.0.6 file.
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.
That would be one approach, and probably the most efficient for coding. As long as there is someone to track the changes to the external API in the UNIX SAMBA code.
The other approach would be to put a wrapper around the lock manager to make it look like the tdb. But that assumes that the tdb interface is stable.
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.
I think that there is a way to have more bytes than that associated with a lock. It would take some research. Possibly sublocks.
I would not want to use global sections as a supplement since they can not be shared between cluster nodes as locks can.
-John [EMAIL PROTECTED] Personal Opinion Only
PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING:
http://www.catb.org/~esr/faqs/smart-questions.html
