Issue 2.1 made on 24th July 1998
by Guy Rixon, RGO
The message-logging system collects progress and error messages from all over the observing system and stores them in a central location on the system computer. The messages are displayed to the users in real time, and the display is sensitive to the priority of messages.
The logging sub-system consists in
Logging of observations done by the ING Data Manager which is a separate system.
The message-logging facility is distributed between processes and processors of the observing system. The flow of data between processes in the system is best shown in a data-flow diagram.
Of the processes in the DFD:
There is one copy of syslogd each for the system computer, the DAS computer and the TCS computer; the autoguider computer does not run syslogd. Process 1 in the DFD is the system-computer syslogd, which logs messages to file; process 2 represents the other syslogd which forward messages to the system computer. The autoguider application sends to syslogd on the system computer via the LAN.
Syslogd for Solaris and logger are provided with the operating system. Syslogd for VMS is a third-party product not normally supplied with VMS. Talker, jabber and the applications are specific to ING.
The Stamped_msg item, which is defined in the data-dictionary below, is the main unit of exchange. It is a line of text in roughly the standard format imposed by syslogd with the constraint that there must be a Priority_keyword at the start of the text of the message. The keywords drive the special handling in talker.
Syslogd, ERS and talker all have a concept of priority of messages. ERS understands alarms, "highlighted" messages and normal messages, which it distinguishes by associating a flag word with each message. The current system adds a flag for debug priority. See the DDE Priority_flag, below, for details. Syslogd uses integer codes, declared in syslog.h and described in the DDE Priority_code, below. The library code compiled into the applications converts between these representations.
The two types of messages passing between processes differ in the priority encoding. A Prioritized_msg has a Priority_code on the front. When syslogd logs the message, it strips the Priority_code, turning the message into a Stamped_msg in the notation of this document.
Because talker never sees the Priority_codes it has to rely on Priority_keywords inserted in the middle of the message. The keywords are added by the library code in the applications; syslogd treats the keywords are part of the text and ignores them. This arrangement is unsatisfactory, but is forced by the fixed interfaces to syslogd.
The store Syslog_log_file stands for a set of three log-files:
In the current version of the system, interfaces are provided only for DRAMA programs and for scripts. When the need arises, packaged interfaces for other programs can easily be added. In the meantime, a Stamped_msg sent to any participating syslogd at UDP port 514 will be handled correctly.
Syslogd is a standard part of Solaris. Please refer to the Unix manual pages for syslogd(1M), syslog.cong(4) and syslog(3). OBS-TALK-4 [1] has details of how to configure syslogd and of the third-party implementation for VMS. Stevens [2] also has a description of syslogd.
Logger is a standard part of Solaris. Please refer to the manual page logger(1M).
Jabber is an extremely simple shell-script. Please inspect the single source-file jabber.sh for details.
Talker is a Tk program that uses only the facilities of Tcl v7.6 and Tk v4.2. It does not need or use any part of DRAMA, or any other Tcl extensions.
The Talker is built from a set of Tcl components:
talker_main.tcl contains code that is executed when the Talker is started. The other components contain Tcl procedures called from talker_main.tcl or as callbacks triggered by GUI control or timers.
Brief descriptions of the procedures are available, and the prologue comments of the source components contain more detail.
The component talker_main.tcl refers to the other components with source statements. These staments are resolved at build-time by the tool tcl-include to give a stand-alone program talker which is executable and specifies its interprteter on the first line. See talker.mk for details.
The Tcl interpreter is wish4.2 from Tk v4.2p2. The talker package (specifically talker.mk) requires this to installed in $OBSSYS/bin.
The only extra file needed at run-time is $OBSSYS/etc/talker.icon which is the bitmap for the icon of the Talker and Alarm windows. If this is not installed, Talker uses X11's default bitmap.
The widget hierarchy for Talker is shown in a structure chart. The highest box on the chart is the root widget, named "." by Tk.
Talker is driven mainly by GUI events which makes its structure fairly simple. There are three real-time aspects that complicate things.
DRAMA programs produced for ING can access the system through one of two interfaces: servers use the standard component srvTalk.c and transient clients use APIs in libcia.
In both classes of programs, messages may either be transmitted directly or stores in ERS [3] and passes into the syslog system when the ERS table is flushed. Here are the structure charts for the client and server components.
The client and server arrangements are almost identical. These are the main differences:
SrvTalk.c has almost no dependence on DRAMA. It would be easily possible to make a version that would would work both in DRAMA and non-DRAMA programs; a compile-time flag would control the different behaviours.
The dictionary defines formally some of the terms used in the diagrams above.
