Minutes from the 8/18/04 LCLS SLC IOC meetings.

No Meeting:   8/25/04
Next Meeting: 9/01/04, 9:30am,  in B5, Rm 211.

(1) Meetings will be at 9:30am starting Sept 1.

(2) CMLOG - LCLS will have its own copy of CMLOG in the LCLS CVS repository.
    Dayle will build it like she did for BaBar (gnu compiler).  Steph will
    build for RTEMS.

ACTION: Dayle and Steph		Due: Oct

(3) Specific changes to existing SLC CMLOG-related processes are required for
    the IOC.  This list is at the end of this file.  Ron will review and
    assign people to do the work.

ACTION: Ron to assign people	Due: Sep 1

(4) Provide an LCLS EPICS setup script (/afs/slac/g/lcls/epics/script).  
    Provide LCLS EDM config files (/afs/slac/g/lcls/epics/edm/config).

ACTION: Dayle			Due: Done

(5) All linux work will be on RHEL 3 for now.  RHEL3 SLAC public machines
    are called "noric-new".  When possible, prototypers should use linux
    instead of solaris since LCLS will be all linux.

(6) The SLC database will be kept in VMS format on the IOC except for
    supertype 0 offsets.  These offsets will be converted to proper endianness
    at database download time  Conversion of data to VMS format will be done 
    in dbget/dbput calls on the SLC IOC.

(7) No big "computer science" project will be done to create conversion 
    routines for each message between VMS and SLC IOC.  These routines will
    be created manually and updated manually whenever message structures
    change (rarely) or a new SLC IOC platform is added.  However, big 
    comments should be added to each message structure include file to 
    remind maintainers to also change the conversion routines.  We may want 
    to keep the conversion routines in both the VMS CMS repository and the 
    LCLS and EPICS CVS repositories (if that will help maintainance).  It is
    recommended that all conversion routines reside in the same directory.
     
(8) Prototyping continues.  The main goals are to get a database download 
    from DBEX and to get a start on conversions.  Also, common code in DBS 
    and MSG will be split out into utilities.

ACTION: Debbie and Diane      Due: Sep 1

(9) Items that will not be prototyped right now but need to be revisited at
    some future time include dblget/dblput calls using database pointers for 
    more efficient database access and efficient update of supertype 3 data 
    (data updated by the IOC such as readbacks) over the network 
    (ie, using watermarks).


Stephanie

CMLOG Tasks:

For the SLC IOC tasks (handlers, receivers, senders), we plan to use the 
C interface "cmlog_logmsg" routine instead of the SLC "err_send*" and 
"err_tmail*" routines for logging messages to the VMS SLC error handler.  

CMLOG is documented here: http://www.jlab.org/~chen/cmlog/cmlog-2-1-b/

The cmlog_logmsg routine allows the following arguments:

(1) cmlog client handle from cmlog_open called during program initialization
(2) verbosity:		0=fatal, 1=error, 2=warning, 3=informational, 4=success
(don't log if greater than the level set by cmlog_set_verbosity_threshold)
(3) severity: 		0=ok, info, or success, 1=warning, 
			2=alarm, error, or fatal, 3=invalid
(4) message code:  	same as existing SLC VMS message codes with the 
			optional "log_only" bit set
(5) facility string: 	"DBS", "MSG", "BPM", "MGNT", etc
(6) text string format (printf-style):	based on the SLC VMS message formats
(7+) arguments to (6)

CMLOG throttling will be used for metering messages as needed.  CMLOG 
verbosity level will be used for enabling/disabling logging as needed.  
Verbosity, severity, and facility can be derived from the SLC VMS message 
code.  We should plan on developing "slc_cmlog_logmsg" that takes as 
inputs (1), (4), (6), (7+) and calls "cmlog_logmsg" with the appropriate 
values.

Note that messages with the upper "log-only" bit set in the message code 
will result in logging only to the SLC error log with NO update on the 
SCP message display of all users.

In the last SLC IOC meeting, Ron asked me to provide a specific list of 
CMLOG-related work needed for the SLC IOC.  Here is the list.  (1) to (4) 
are assigned already.  (5) to (8) need assignment by Ron.  I do not think 
(5) to (8) are a lot of work.

(1) Put CMLOG into LCLS CVS repository:			Steph
(2) Build CMLOG for vxWorks, solaris, and linux:	Dayle
(3) Build CMLOG for RTEMS:				Steph and Dayle
(4) Convert cmlogVxLogMsg to cmlogIOCLogMsg*:		Steph
     (* install in EPICS 3.14.6 site, and build for all IOC platforms)

(5) Develop slc_cmlog_logmsg utility (see description above).

(6) Change the unix SLC CMLOG forward browser (the process that receives 
messages from the cmlogServer and forwards them to the SLC error log), so 
that if a message code is provided, it sends it instead of CAU_EPICS_ERROR 
to the receiving process on VMS.

(7) Change the VMS process that receives the message from the forward 
browser to use the message code and respect the log-only bit.  Make sure 
that SLC IOC messages make it to all SCP displays if the log-only bit is 
not set.

(8) There is a VMS process that sends messages from non-IOC micros back 
to the cmlogServer via the unix SLC CMLOG forward client.  Change that 
VMS process so that it does NOT send any messages from SLC IOCs 
(regardless of message code).