4.13 CONFIGURATION

The section Installation of the LCC User Manual [2] describes the possible configuration parameters and gives some hints how to configure the system. Additionally one should consider what is described below.

4.13.1.1 Process Priorities

LCC processes has the following default priorities (a low value = high priority):

Processes running with priority higher than 80 should only execute during a short time (less than 1 millisecond). Processes which needs to execute without interruption and are critical to the system shall have a high priority. Exceptionally they can execute longer time if this is required. This must still be limited to the order of a few milliseconds. One has also to take care that the system is not disturbed, e.g. the network is served, messages are handled in time etc.

Processes executing during longer time than a few milliseconds must have lower priority than 100. The general rule is that the longer the execution time, the lower the priority.

LCC has a watchdog which is a process running with low priority, updating a hardware watchdog. When the watchdog process is starved, e.g. gets no CPU time, the hardware watchdog is not updated and times out and reboots the LCU. The timeout is 13 seconds.
If you have a process running longer than 13 seconds without releasing the CPU, then it must have a lower priority than the watchdog task. Otherwise your LCU will reboot.

Some VxWorks tasks uses global variables to define their priority. If you need to change the priority of any of these tasks, you can do it by changing the value of this global variable. The variables are:

Changing the priority of system tasks must be done with care because it will affect the behavior of your system. In particular this is true for the netTask.

4.13.1.2 Stack Size

Processes using the message system extensively needs at least 40 kBytes of stack to work properly. This is also the default stack size if you have installed VxWorks according to the VLT Installation Manual [14].

When running a function directly under the VxWorks shell, the function uses the stack of the shell.

In case the function calls ccsInit, make sure that the shell has a stack big enough, e.g. at least 40 kB.

The configuration of VxWorks must be done properly. See the VLT Installation Manual [14] for configuration of VxWorks.

Try also to avoid using too much stack in functions. The goal must be to reduce the use of the stack as much as possible. For example do not use too big arrays of data.

In VxWorks there is no protection against stack overflow. When starting a task, VxWorks fills the stack with 0xee. You can check if a stack overrun has occurred or how much stack the task has used with the utility checkStack. The filling of the stack can be disabled with the task option VX_NO_STACK_FILL.

When developing a new application, set the stack size to a large value, e.g. 100 kB or more. When the development has finished check the stack usage and reduce the stack size accordingly. To be safe always leave a big enough margin.

4.13.1.3 NFS Configuration

LCC accesses several files on the host workstation through NFS. Files accessed through NFS are, CDT and CIT when they are loaded, database definition files when the database is loaded and database backup/restore files. Also some of the files in the BOOT directory are accessed through NFS. They are normally all located in the VLTDATA directory. Make sure that this is properly configured to enable LCC to start properly. VLTDATA must be NFS mounted on the LCU. This can be checked with the VxWorks utility devs.

Be careful with links to other directories on the workstation. If for example your VLTDATA is the directory /vlt/data, which in turn is a link to another directory, e.g /diskb/vltsw, then it is not enough to mount /diskb/vltsw. You must also mount the directory /vlt or /vlt/data.

Also make sure that the directory is exported on the workstation (file /etc/exports).

Disks which are NFS mounted from another workstation on your host, cannot be NFS mounted to the LCU from your host. They must be mounted directly from the workstation where they are located.

4.13.1.4 Device Timeout

When the LCC Management module sends commands to software devices, see [9], it uses a time-out when waiting for the reply. This time-out is configurable by setting the global variable lccDeviceTimeOut. Default value is 20 seconds.

4.13.2 CCS configuration.

4.13.3 Environment concept

An environment on WS, is defined as "A combination of RtapScheduler, other Rtap processes, and applications, together with the communication channels and other resources which they share."

The environment concept applies also, with some restrictions or differences in the implementation to LCU environments, and in a very restrictive way to CCS-lite environments on WS

The communication channels used by the message system inside the environment, and the communication port for communicating with other environments.

LCU environments obviously don't have an RtapScheduler, and CCS functionality is provided by LCC.

CCS-lite environments provide only the communication channels to be used for simple tests when Rtap is not available.

Most of this is already described in the CCS user manual, and comes partly configured with the software delivery. However, key points are repeated hereafter.

4.13.3.1 Making environments known to each others.

1. editing an entry for each environment in the /usr/rtap/etc/RtapEnvList file associating the environment name with the place where the declaration of the environment can be found:

2. declaring in the /etc/services file a tcp port number for each environment name. If environments are located on different hosts, the port number can be the same, otherwise two different environments must have different port numbers.

4.13.3.2 Describing the environment

The complete environment is described in the environment directory by the following elements:

1. The RtapEnvTable specifying all processes known within the environment together with some of their characteristics. These elements are described in detail in the Rtap documentation. Only important points, or peculiarities required by CCS are listed hereafter.

a. Rtap process number: Some numbers are assigned to key processes and must not be changed since this may be misleading for the filtering mechanism used by Rtap. Normal utilities should not be allocated a number. If several copies of a single process are allowed to run at the same time, they should be assigned a value 0 to let RtapScheduler grant free numbers.

b. Autostart phase: Processes can be automatically started when the environment starts up. This field allows to configure several phases to start processes in a given sequence. Rtap core processes and some CCS utilities are started in phase 1, other Rtap and CCS background tasks (like the scan system tasks) are started later on in phase 2. Utilities not requiring to be started, but directly scheduled by users should be assigned to phase 0.

c. Autostart as user "rtap". For normal applications, this field should always be set to "N", letting them run with privileges of the user starting them.

e. Multiple copies allowed. Normally set to "N". When set to "Y" multiple copies of the process can run concurrently. In this case, the field "process number" shall be set to "0". Special care shall be taken when designing applications supporting multiple copies. In particular, since the message system uses a process name when sending commands, or setting a filter on replies, ambiguities could occur if several processes running in the same environment have the same name. On the other hand, since command messages transport the process number of the requester, there is no risk of ambiguity if configuration utilities (usually sending a command to a server, and waiting for an answer), for example have the field set to "Y"

f. Cleanup on termination.This field is used to control generation of "obituary messages" signalling termination of processes. Since obituary messages are broadcasted to all processes having registered for such a notification (see next field), normal applications should have this field set to "N".

g. Care about process terminations. This field controls if the process shall receive "obituary messages" signalling termination of other processes. See Rtap documentation for the different possibilities. This can be used by a process to stop servicing a request for periodic replies when the requester terminates abnormally. A process requesting reception of termination notices should be prepared to receive them not only from the process it is mainly interested in, but also from all other processes according to the selected option.

In order to benefit from features provided by Rtap, all processes potentially running in an environment should be declared in the corresponding RtapEnvTable with the proper configuration.

2. A valid set of database snapshots (run time images of the database) and a literal description of the database (like the one produced by the dbl) allowing to load it from scratch. The literal description is used the first time a new database is loaded, or after structural changes. The snapshots, authorizing a faster loading are used for subsequent environment startups.