Minutes from the 7/21/04 LCLS SLC IOC meeting.  

Next Meeting: 7/28/04 in B5, Rm 211.

(1) People availability:

Ron:     7/19 to 8/13
Dayle:   7/27 to 8/11
Diane:   8/2  to 8/13
Ken:     8/9  to 8/13

(2) Test Database:  Ken created a second SLC IOC micro.  He added 
    sample XCOR and YCOR units to each one.  XL01 being similar to
    LI28 and XL02 being similar to LI29.  He initialized secondaries
    (fields) of these units but zeroed out the camac control words.

(3) SCP IPL of SLC IOC: Ken is studying the 40(!) pages of SCP IPL 
    code to identify areas that will need change for the SLC IOC. 

ACTION:  Ken		        DUE: Aug ??

(4) Prototype: SLC message service on the IOC.  Test messages sent OK.
    4 thread/tasks involved:
    (1) MsgExec:  interface with iocsh - starts/stops everything in
                  the proper order
    (2) MsgRecv:  binds to socket and receives messages from SCP/Proxy,
                  places message in request queue, stops when requested
    (3) MsgHndlr: takes message out of request queue and puts a reply
                  into the reply queue, stops when requested
    (4) MsgSend:  takes message out of reply queue and sends back to 
                  Proxy/SCP, stops when requested
    It is anticipated that there will be one MsgHndlr-type task for every
    "micro job".  Before looking into DBMAIN, Diane will try things out
    on a VME mv2700 (ppc604_long) with Debbie's help.

ACTION:  Diane and Debbie	DUE: July 21

(5) Endian Issue:  What is the best way to handle endianness?  
    Should we limit the number of platforms that will run SLC IOCs to 
    solaris, linux, and motorola?  Does each task that deals with 
    messages convert its message before using it based on platform.
    Is there a better, more general, way?

ACTION:  RonC			DUE: Aug ??

(6) SLC Database API: Needs to be defined before work starts.
    Ken asks if we want the full API or if we can get by with a subset.  
    Do we need to do database lists (which allows for more efficient 
    SLC database update (required for older x86, maybe not important for 
    PPC and Unix).  Ken mentions that the database utilities are 
    structured with a C layer on top of a FORTRAN layer on top of an 
    Assemler layer.  He says it'll be more of a rewrite than a port for 
    these utilities.

ACTION: RonC			DUE: Aug ??

(7) Update of the Alpha Database:  In general, EPICS IOCs update their 
    readbacks and other fields faster than SLC micros. It's OK for the
    SLC database on the IOC to be updated frequently, but the rate that
    these updates make it back up to the Alpha needs to be considered.
    The issues include both network traffic and that some VMS apps 
    don't expect updates so frequently and may break something or 
    confuse operators.  We should consider using MDELs to 
    determine if an Alpha update is necessary (vs Ken's significant
    change algorithm).  We should consider updating only at the async 
    periods defined in the IOC CSTR record (along with any manual 
    update requests).  Consideration needs to be given to how the
    correct blocks of data are sent (ie, do we use the existing logic
    for high and low water marks or develop something else).

ACTION: RonC			DUE: Aug ??

(8) Magnet Functional Requirements:  Dayle introduced us to the magnet
    job and has broken out the main functions.  Before starting the 
    design, she will list all the functions, what the request and reply 
    messages consist of, and some more detail about each function.
    At that point, she will consider what will be in the magnet message
    handling task and what will be in the EPICS database or EPICS 
    sequence.

ACTION: Dayle			DUE: Aug 27


Stephanie