Minutes from the 11/10/04 LCLS SLC-Aware Design Review: Functional Requirements: SLC Exec, Message and Database Services (1) Greg: How about killing the forward browser and using just CMLOG. That means no errdsp; start CMLOG with an appropriate filter and use that window instead of the SCP error pane. (2) Greg: Could the translation file be Oracle, and not NFS? That would help AIDA too. Ron: SBC has no ORACLE capability. Steph: Could use socket connection to oracle server. (3) DBEDIT has no effect on primary.map translation file. (4) Terri: Relative timing of DB update and reply message on completion? Later discussion led to trying to do better than the SLC micros, i.e. have a dbmicrosend status and different replies for good/bad. (5) Nancy & Terri: Supertype 1 questions Probably very rare; rely on SAIOC dbedit capability SAIOC-side dbedit needs logging (6) Is an extra proxy needed for LCLS? If so, may be big problem. Would require alpha messaging, dbex, etc. to look at two sockets. How about "cascading" proxy server processes, leading to only one talking to VMS? (7) If LCLS adds too many IOCs that need SLC interfaces, then we will run out of room in the "micro active mask". Making this mask bigger is a big deal since so many applications assume a maximum number of micros and we'll need to make some updates for resizing purposes. (8) What does the proxy do with a message when the forward header looks bad? When the "crc" is not 0x55 or the data length is wrong or whatever. From RonM: The proxy checks the following cases for the fwd header looking "bad": 7a) If there is a tcp/ip socket read error on the header, it logs an error and kills the child handling the connection. This would be an expected condition if the client closed the connection, or it could be an error. 7b) If the CRC is wrong, then, fwd_child.c logs an error and kills the child handling the connection. So the data is dropped. The client that sent the message would see the connection closed by the proxy if it hadn't already done so itself. (9) What does the proxy do when it gets a message from the micro to DBEX but the connection with DBEX is down? Does it queue any messages and then send them all when DBEX is back up? How about messages from DBEX to the micro? Are those queued or dropped if the connection to the micro is not there? From RonM: Background comment: The proxy knows nothing about who the data is from or to. DBEX is just another client. It handles it's messages just like any other client. There is no special purpose code based on who sent the message. Answer: It should dump the buffer. No, there is no queing and resending after DBEX is back up. It's the same in both directions. (10) Diagnostics data kept in "SLC Resources" need to get into EPICS - probably by an async task that periodically writes to soft records. (11) Concern that if we dbedit supertype 1 data on the IOC, it may no longer be in sync with the Alpha until the next IOC reboot. Concern that apps that use supertype 1 data only read them in at init time so changing supertype 1 data on-the-fly doesn't buy anything. (12) LCLS-specific requirement that the GNU suite of tools be used for builds.