Minutes from the 11/12/04 LCLS SLC-Aware Design Review: 
	SLC Database Service

(1) Could we have dbstop and dbinit messages which result in tasks not 
    stopping but instead clearing their dblists and reinitializing and 
    DBS to redownload the database?  No impact on the message service or 
    error logging.
(2) Comment for yesterday's review - another thread that receives error 
    messages sent from all the other tasks and sends them on to cmlog daemon.
    Don't need a cmlog handle per thread then.  Could maybe be combined with 
    EPICS errlog listener hook.
(3) If DB version was somehow part of the list created by dblist, then a 
    check on valid version number could be done in the dblget/put calls.
(4) The problem where the Alpha has to wait after a dblput is still with us.  
    There is no acknowledgement from DBEX back to the processes that do 
    dblput of ST2 data so a wait is done instead.  There is nothing in the 
    SLC IOC design that makes a difference (other than the IOC acknowledging 
    back to DBEX if requested).  Tony mentions that we could think about 
    using a mechanism involving special secondaries in the database (ie, 
    with timestamps) which the Alpha could check.   More discussion is needed.
(5) When the source for the SLC micro code changes, there is no auto-update 
    of the equivalent source for the IOC.  It would be nice if comments were 
    added to the micro and IOC code to indicate where to change the other side.
(6) Same comment about copies as for the message service design review.
(7) Using the EPICS standard gphash means locking and unlocking a mutex which 
    is not needed for our read-only usage.  Should we copy the gphash source 
    to our own area and change it for our own usage?  There may be memory 
    usage issues that require changes too.  Or we could see if we could 
    change the collaboration's gphash to add these new features.
(8) Debbie asked if her idea for using extra memory in the dictionary to 
    allow for faster accesses for the ALL* case is OK.  No one thought it 
    was a problem.
(9) If we add data width to the dblist calls, then we wouldn't need 
    primary.map though we'd give up dbdump, dbedit, etc from ioc shell.  
    Pretty strong vote for keeping primary.map.
(10) Perhaps need to resurrect the idea of dbCtrl thread that waits on the 
     CTL socket and sends acks to dbSend that is waiting for them.  Then 
     select is not needed though that's not a big issue in this case.
(11) Acknowledgements are for pieces of the dbhilo table and so pieces need 
     to be cleared instead of the whole table being cleared at the very end.
(12) It's possible that someday, units could be 5 characters.  No one thought 
     it likely but may want to think about it in the hash table and db i/o 
     routines.
(13) What job number will we use for cstrAsync?  What job number will we use 
     for IOC shell?  Probably the one for "TEST".
(14) dblput figures out job number from the thread information.
(15) Ed points out that because of the conversions, writing a float into the 
     database and then reading it back again will not match the original 
     value.  No one thought this should be a problem.
(16) Should "filename" sometimes be required for some IOC shell db calls?  
     In particular, ones that use "ALL*" (or whatever) for primary.  There is 
     no ctrl-C handling in IOC shell (I think).
(17) Should have dbgettype to get data type, dbgetwidth to get the width, and 
     dbgetcount to get the number of elements for the secondary.   Also be 
     nice to get all the information as a string like "23A4" from IOC shell.
(18) Is dbdumpdatabase the same as dbdump with no args (except filename)?  
     Or is more information than the data dumped out?
(19) Should dbedit be restricted on what it can change?  Should we output a 
     warning when ST1 data is changed?  dbedit should be cmlogged.
(20) Maximum size of messages to and from DBEX is 8K.  If we decide to send
     up a whole superblock (2 or 3), it must be sent in pieces.
(21) The contiguous ordering of data in the supertype blocks is 
     administratively managed.  The ordering is dependant upon the database 
     text file processing during the DBGEN.  We can attempt to promote the 
     contiguity of the supertype data, but we cannot guarantee it.
(22) Perhaps we should add "primary secondary" to the dictionary for the 
     dblist (list_p, primary, ALL*, secondary) case. It'll speed up dblist for
     ALL* and secondary name checking but will increase the collision count
     and requires more memory.