Minutes from the 11/11/04 LCLS SLC-Aware Design Review: 
	SLC Executive and Message Service

(1) KenU asked how we make sure that we have a use a unique micro name 
    in our startup file
(2) Steph made a note that destination SCP ID (4 char + null-terminator) 
    needs to be added to slcThreads.
(3) Do we need multiple cmlog client handles or can/should everyone use 
    the same one (whose comment was this)?
(4) Terri suggested that we implement some sort of security on the 
    channel access way to restart SLC.
(5) Greg suggested that for debugging, we may want to suspend tasks with 
    failures instead of exit.
(6) Steph made a note that functional requirements should list reasonable 
    timeouts for various waits.
(7) Diane said slcExec will not set dbExists to false, database service does.
(8) slcExec destroys receive sockets, receive tasks will return from socket 
    call and know to exit (without destroying the socket).
(9) Diane to add receiveFromMsgQ to message utilities
(10) No data integrity (ie, real CRC) is done on the messages.  The 
     functional requirements should mention that it is NOT a requirement 
     since the SLC micros don't do it either.
(11) Some confusion about the maximum size of any incoming message.  
     From ref_c_inc:netparm.hc:
       Alpha->Micro:  Max = 2K bytes
       Micro->Alpha, normal messages:  Max=8K bytes
       Micro->Alpha, long messages:  Max=64K bytes
     The func reqts should specify which SLC IOC jobs need long reply 
     messages.  
(12) Does anybody use the timestamp in the message header for anything other 
     than diagnostics?  Nancy Spencer thinks not.  The timestamp was used 
     long ago when the micro times were not well synchronized.
(13) When receiving the message from the Alpha, the following copies are done:
	(a) from socket to local space
	(b) from local space to unpacked local space (for conversion and 
	    unpacking of the message header)
	(c) from unpacked local space to message queue
	(d) from message queue to job local space
	(e) from job local space to job unpacked local space (for conversion 
	    and unpacking of the message)
     Can the number of copies be reduced?  This didn't get discussed in the 
     meeting but ....could we do something like:
	(a) checkout some memory from a pool (always 2K even though you 
	    don't use it all)
	(b) from socket to checked out memory
	(c) unpack and convert only the message header into local space
	(d) put the following information into the message queue: copy of 
	    converted message header and pointer to checked out memory
	(e) job gets message and converts/unpack into local space
	(f) job frees checked out memory
	(g) On shutdown, job has to read the queue and free any checked out 
	    memory before exitting
(14) Same comment about reducing copies for sending messages from a job back 
     to the Alpha.
(15) Greg has ideas on how the packing/unpacking/conversion can also be done.
(16) Kristi said that the part of the startup file that is used to start
     the SLC interface should be kept in one separate common file that all
     startup files invoke.