During the Subsystem CLIP Startup, a CLIP unprivileged (TU) Batch Job will start automatically and connect to the CLIP Subsystem, executing Batch Jobs with TSOS privileges.
Socket connection
The SOCKETS(BS2000) interface is one of the interfaces usable for network programming in BS2000. It can be used to develop communication applications based on the TCP/IP and OSI service definitions.
More information about sockets may be found in separate manuals.
Once FITC communication is established, CLIP will attempt to connect to the rsyslog server. Configuration is read from Parameter File: IP address, inbound port of rsyslog server and protocol used to transmission.
- IP address - must be a valid IPv4 address consisting of four numbers in the range of 0-255 and separated by dots, for example, "127.0.0.1". If the rsyslog server's address is not valid, both parts of CLIP will terminate. This parameter does not have a default value.
- Port - must be a valid number between 1 and 65535, representing a functional and open port in the rsyslog server that can be accessed by the BS2000 machine. The default port for rsyslog traffic is 514, as stated in the /etc/services file on the server.
- Protocol - only valid value for this parameter is "TCP". This parameter remains in the configuration as additional protocols may be implemented in future versions.
The CLIP Batch job will generate a SOCKETS(BS2000) socket and attempt to establish a connection. If successful, socket configuration is completed and CLIP Batch job start listening for incoming calls.
If the connection to the rsyslog server is lost, the batch job cyclically tries to reconnect, starting with the next event to be sent, which occurs at least one second after the connection loss. This repeats every second until a timeout occurs or the internal buffer is full.
Batch job waiting for upcoming calls
The batch job will now await upcoming calls. When the setup is complete, the CLIP batch job will go into a wait-state until a message appears from FITC. The job works synchronously to process one message at a time. The asynchronous mechanism in the CLIP Subsystem provides minimal time overhead on the TPR site, with no loss of consistency of data . Transmission occurs due to internal buffering and reasonable CPU effort on the TU site.
If a SATCP (or any other supported events in future) event occurs in the system, the CLIP subsystem will send messages to the CLIP batch job.
Error handling
Clip will inform the operator via the console of any warnings and errors originating from the subsystem as well as the batch program.
Additional diagnostic information that could assist in diagnosing issues (e.g. a connection problem with the rsyslog server) may be available in the syslog files under $TSOS user account:
- SYSLOG.CLIP.TU.<timestamp> - for batch job
- SYSLOG.CLIP.SUBS.<timestamp> - for subsystem
Size of these files in normal operation shouldn't exceed 100 PAM pages per CLIP session. In case of numerous errors this size could be insignificantly higher.