SE R VE R

MA NUA L

ma cs
®

management administration communication system

System Manual Vol. 3

Files and Software Modules

Innovation. Experience. Flexibility. Quality.

 Server Manual Vol. 3 - Files & Software Modules

Table of Contents
4. SYSTEM FACILITIES....................................................................................................................................... 3
4.1. Save / Recovery................................................................................................................................................... 3
4.2. Message logging................................................................................................................................................. 3
4.3. History logging.................................................................................................................................................... 3
5. THE INTERNAL INTERPRETER....................................................................................................................... 4
5.1. Operators........................................................................................................................................................... 4
5.2. Operands............................................................................................................................................................ 5
6. HOT-STANDBY / MULTI-COMPUTER CONFIGURATION............................................................................... 7
6.1. The software concept............................................................................................................................................ 7
6.2. Task distribution in the network.............................................................................................................................. 7
6.2.1. Master computer..................................................................................................................................... 8
6.2.2. Standby computers.................................................................................................................................. 8
6.2.3. Information server................................................................................................................................... 8

Page 2 ServerManual-Vol3_content_1.0063_rev00
 Server Manual Vol. 3 - Files & Software Modules

4. SYSTEM FACILITIES
In addition to the standard processing functions in the FIDS/Linux system, there are a few
special facilities which cannot be grouped with other components of the system. These are
explained in the following chapters.

4.1. Save / Recovery

In the FIDS/Linux system, this is virtually a realtime application in which almost all system-
related data are memory-resident during operation. To minimize data losses in the event of
system crashes (power failure or similar), system tables and the actual database write backup
copies to a permanent data carrier (a hard disc, directory /app/sint2/save).
For the actual database, there are arr.sav backup files for arrivals and dep.sav backup files for
departures. Backup files for system tables have the name format t9999.sav where ‚9999’ is the
number of the table under which this file is stored in the system table (sys.tab). The system table
(sys.tab) also has a code beside each table which indicates whether it can be changed and
whether a recovery file should be stored in the event of changes.
Backup files are stored by the time scheduler (TIMSCH). This re-schedules itself at regular
intervals set by time parameter ATT _ TIMSCH (time parameter number 1) and it checks the
actual database and all system tables for changes. Changes to data are designated by a
special internal flag set by the responsible handlers (flight table and system table handlers).
When the time scheduler notices a change, it produces a backup copy. In practical terms, this
mechanism means that, in the worst case scenario, data may have been lost, although this is
restricted to the time period which the time scheduler requires for re-scheduling itself.
This time interval (usually 1 minute or 30 secs) constitutes the smallest unit of time in the FIDS/
Linux system because all other time-controlled activities in the system are initiated by the
time scheduler and are therefore dependent on this interval of time. Theoretically, every time
parameter in the FIDS/Linux system could be based on a number of seconds. This is not always
advisable due to the sheer volume of data traffic and the power of computer and scale of
application should also be taken into account.
If the FIDS/Linux system is to be powered up, there is the option of deciding whether the actual
database or the system tables should be „recovered“. It is also possible to make a complete
recovery start (actual database + system tables), or to make a cold start. These variants are
influenced by parameters in the start command ‚fids’.

4.2. Message logging

For every message, there is an option in the FIDS/Linux system of activating a logging function.
This is set in the message table (msg.tab) in which all system messages are defined. If this is
the case, the message handler (msh) can also write messages in a so-called „message logging
file“.
At a conceptual level, files can be organized as they are in history logging files, in sequential
manner, or in sequentially-indexed manner. In the case of sequential organization, a text file is
created daily with a date suffix (YYMMDD). These files can be consulted, for instance using the
command ‚m’ to see the whole file or ‚t’ to see the last messages in the file.
The delete mechanism for old messages is configurable. The relevant time parameter is
ATT _ MLOGG (5). This is listed in the time parameter table (at.tab) and can be adjusted
accordingly.

4.3. History logging

Data records deleted from the actual database can be placed in the so-called „history logging
tables“. This option is particularly appropriate for downstream systems (e.g. invoicing, statistics
etc.).
The history logging files are created by the HISLOG process. When a data record is deleted
from the flight table handler (fth), this transfers the deleted data record to the action scheduler
ACTSCH. The action scheduler checks in the action scheduler table (as.tab) to establish the
processes for which this deletion is important. If the HISLOG process has been entered here, it

ServerManual-Vol3_1.0063_rev00 Page 3
 Server Manual Vol. 3 - Files & Software Modules

receives the deleted data record and can, after first preparing it in accordance with a defined
record format (record description), insert it in the history logging table.
The maximum service life for history logging tables is specified by time parameter ATT _
HFADEL (6) for arrivals and ATT _ HFDDEL (7) for departures.
If the data record is to be added and there is no space left in the table, the oldest data record is
deleted to make room.
If the size of history table is not enough to save all history files for the configured number of
days, the FIDS/postgresql database must be used to save the history records.

5. THE INTERNAL INTERPRETER

The internal interpreter is a software module in the FIDS/Linux system which has similar
functionality to the selection interpreter described in the User’s Guide. The internal interpreter
assesses logical expressions in a similar manner, comprising operands and operators, to
establish whether they are TRUE or FALSE. In contrast to the selection interpreter, which is only
used for user’s selections, the internal interpreter is used for the assessment of configuration-
dependent expressions (e.g. in the connection or selection table). The wide variety of usable
operators and operands is more comprehensive with the internal interpreter module than it is
with the selection interpreter. In contrast to the selection interpreter, the internal interpreter also
permits assignments. This means that changes can even be made to the contents in fields. Also,
the operands have a completely different syntax from the selection interpreter.
Whenever a specified expression is interpreted and assessed, this occurs in conjunction with a
data record for which, in turn, a record description must exist, to enable reference to be made
to individual fields.
An expression such as

[N80]==[>DL]
is described as TRUE if the field bearing field number 80 contains the leading string ‚DL’.
The following section now lists and describes all operators and operands used here.

5.1. Operators
The operators used are a sub-set of the range of operators in the C language.
== equal to
!= not equal to
> greater than
>= greater than or equal to
< less than
<= less than or equal to
|| logical OR
&& logical AND
= assignment
| OR bit operation
& AND bit operation
^ EXCLUSIVE OR bit operation
+ addition
- subtraction
% division rest
/ division
* multiplication

Page 4 ServerManual-Vol3_1.0063_rev00
 Server Manual Vol. 3 - Files & Software Modules

?: conditional assessment
@= Frequency equal to
Operators and operands can, though they do not have to, be separated by one or more
spaces. This is irrelevant to the assessment function.

5.2. Operands
All operands are placed in square brackets to identify them clearly. The first symbol in the
brackets indicates the type of operands, i.e. the type and nature of interpretation by the internal
interpreter. The following types of operand are designated by a designation line with the
following structure:

Operand designation, format, examples

Field Number,[N99],[N6] for field number 6

One field of the data record, for which a record description must exist, is addressed with field
number ‚99’.

Field data Length,[N99L],[N6L] for length of field number 6

The actual number of characters of the field data.

Field Number,[I99],[I6] for field number 6

This is the same as N99, but it can be used only for CHAR fields where the result should be
interpreted as INTEGER.

Field Number,[C99],[C6] for field number 6

This is the same as N99, but it can be used only for INTEGER fields where the result should be
interpreted as CHAR.

Field Number,[E99],[E15] for field number 15

This is the same as N99, but it can be used only for TIME fields where the result should be
interpreted as DATE.

Time of time chain,[F9],[F1] for time chain 1

The time of a data record in an actual database is assessed in accordance with a specified time
chain number. The distinction for assessment of a fixed time field possessing a conventional
field number is the option of re-routing to the field number of a smaller time chain number if
the primary time field in the time chain does not contain a time. This point can be clarified with
an example: there are usually 3 standard time chains 1 = scheduled time, 2 = estimated time
and 3 = actual time. Now if, for example, assessment is based on time chain 2, this means
that I want to have the estimated time of a data record. However, if there is no entry in the
field for estimated time, assessment moves to the scheduled time, i.e. the time chain number
immediately preceding the one I consulted.

Time parameter,[T99],[T15] for time parameter 15 in minutes

Time parameter ‘99’ assessed in minutes. This time parameter must exist in the time parameter
table (at.tab). Otherwise the operand is assessed as zero.

Time parameter,[S99],[S12] for time parameter 12 in seconds

Time parameter ‘99’ assessed in seconds. This time parameter must exist in the time parameter
table (at.tab). Otherwise the operand is assessed as zero.

Hexadecimal character block, [Xhhhh...],[X1b20]

Variable length of time chain constant in hexadecimal form.

ServerManual-Vol3_1.0063_rev00 Page 5
 Server Manual Vol. 3 - Files & Software Modules

Character string,[>XXX],[>Hong Kong] for text „Hong Kong“

Variable length of text constant in ASCII form. As with all text strings in the FIDS/Linux system, it
is also true here that any symbol in octal form can be integrated in the string with a backslash
symbol, e.g. [>\033J] for ESC and the symbol ‚J’.

UniCode Character string,[UXXX],[U ] for text ‘ ’

Variable length of text constant in Unicode form.

ASCII date, [DDDMMYY],[D241191] for 24 Nov 1991

Date in ASCII form.

ASCII minutes,[MHHMM],[M1045] for 10:45

Hours and minutes in ASCII form.

ASCII time actual database,[AHHMM+-D],[A1215+1]

In the actual database, all times in minutes are stored, ever since 1980. However, the date is
not shown on the display but is instead [presented with a one day-offset.

Frequency,[Z9999999],[Z145] or [Z--3---7]
Frequency of a data record in the scheduled database. Since this field only exists in the
scheduled database, it can also only be used in conjunction with data records from the
scheduled database.

Lookup table field reference,[L99;88],[L14;3]

Field number ‚88’ in the lookup table is addressed here and its reference is produced by field
number ‚99’. This field must always be a field in the „lookup table“ type because this is the
only way to determine the table number. If this is not a „lookup table“ field or if the „lookup
table key“ of the field with number ‚99’ cannot address a data record in the lookup table, the
contents of field #99’ are themselves used for assessment.

Current time (actual database format),[*]

Time of day in minutes since 1980.

Current minutes,[*M]
Minutes since midnight.

Current day,[*D]
Days since 1980 in minutes.

Current Frequency,[*Z]
Current day in frequency format: 1,2,3,4,5,6,7
For example, If the current day is Monday, the result of [*Z] is 1
If the current day is Sunday, the result of [*Z] is 7

Binary value,[%22222222],[%101] for the value 5

Numerical constants in binary form.

Octal value,[0888],[033] for ESC characters

Numerical constants in octal form.

Hexadecimal value,[$FF],[$1b] for ESC symbols

Numerical constants in hexadecimal form.

Page 6 ServerManual-Vol3_1.0063_rev00
 Server Manual Vol. 3 - Files & Software Modules

Decimal value,[999],[-17] or [+4] or [720]

Numerical constants in decimal form. Prefixes are permitted. In binary, octal or hexadecimal
forms, the prefix is implicit in the dual complement presentation form.

6. HOT-STANDBY / MULTI-COMPUTER
CONFIGURATION
An information system comprises a large number of programs operating in a network,
encompassing a wide range of duties. For more complex applications where it is necessary to
serve hundreds of display units and input devices as quickly as possible, operating with one
central single computer solution often encounters performance limit if there is a real need for
rapid response times.
The FIDS/Linux system is designed in such a way that the same software system is able to cover
all needs, from low-cost single-computer requirements right up to more extensive and complex
network systems.

6.1. The software concept

FIDS/Linux computers are connected together using the basic “Ethernet” network.
The basic concept underlying the network variant of the FIDS/Linux system is that the large
number of processes which go together to form one section of a system are not all required to
run on the same computer but can instead be distributed across a number of computers. Since
each process is responsible for a clearly delineated task in the overall system, there is a need,
when a request for this process appears, for it to be transmitted to that process, even if it is not
running on the local computer. This means that there is a need for a firmly defined interface
between computers in the network which can forward tasks of this kind. In addition, it must be
possible to identify the computer on which a given process is running. In the FIDS/Linux system,
this requirement is satisfied by the process table (pn.tab). This table maintains a list showing
which process is running on which computer.
Since every process in the system requires access to a wide range of globally available
information on its local computer, it is also necessary to ensure that these data records remain
up-to-date on all computers in the network, in other words all computers need identical and
up-to-date data records. This can also be achieved by the interface mentioned above which
links the computers.
With regard to the FIDS/Linux system, 3 additional processes are required (or 4 processes in
the case of the HOT-STANDBY configuration) which cover all requirements in the network. Direct
exchange of data between computers on the system is handled by the two processes ICGET and
ICPUT. These two processes must run on every computer with ICPUT transmitting data to one or
more computers and ICGET receiving these data and integrating them in the local system. The
third process required is ICINIS. This only runs on the MASTER computer and is responsible
for the initialization of SLAVE computers, i.e. for ensuring that all share the same data. If this
network is based on what is known as the HOT-STANDBY configuration, all computers also need
the WDOG process. A HOT-STANDBY configuration exists if one or more computers in the FIDS/
Linux network monitor other computers and if they stand in for these in the event of failures or
fatal error conditions. The WDOG process has different functions, depending on whether the local
computer is a STANDBY or a NON-STANDBY unit. If the local computer is a STANDBY unit, the
computers being monitored are polled at defined intervals (refer to time parameter table at.tab)
to establish whether or not the network link is still functioning properly. If this is not the case, or
if an assigned NON-STANDBY computer reports a fatal error on its local system, WDOG initiates a
handover. On NON-STANDBY units, WDOG simply has the task of checking the existing file systems
by comparing these against entries in the file table (fi.tab with file type ‚W ’).

6.2. Task distribution in the network

In basic terms, all processes involved on the FIDS/Linux system and entered in the process table
(pn.tab) can run on any computer. This operation is handled by entering the „target CPU“ in the
process table for the relevant process. However, there are a few exceptions to this rule relating
to the task performed by a computer in a network.

ServerManual-Vol3_1.0063_rev00 Page 7
 Server Manual Vol. 3 - Files & Software Modules

A FIDS/Linux network contains the following types of computer:

6.2.1. Master computer

A FIDS/Linux system operating in a computer network always has one and only one MASTER
computer (number 1 in the CPU table cpu.tab). The FIDS/Linux system is only able to operate
at all if the MASTER computer is in a state of operational readiness. All other computers, i.e. all
NON-MASTER or SLAVE computers can be initialized by the MASTER computer once they have
created their FIDS/Linux environment and have established contact with the MASTER computer.
If the MASTER computer is powered down, or if contact with it is interrupted for some other
reason, the SLAVE computers go into STANDBY mode. In this mode, SLAVE computers simply
wait for contact to be re-established with the MASTER, at which point they are re-initialized by
the MASTER.
With regard to the processes, some of them can only run on the MASTER computer and there
are others which must run on all computers connected to the network. ICINIS (computer
initialization) and INSFLT (actual database loading) are processes which can only run on
the MASTER computer. This is achieved by entering the logical CPU number of the MASTER
computer (normally 1) as the target CPU in the process table. If 0 is entered at this point, this
means that the process will be started on all computers in the FIDS/Linux network. Entering a 0
is necessary for the following processes BIGMAMA, SYSTRT, SYSDWN, ACTSCH, TIMSCH, OHDPRT,
ICGET, ICPUT and WDOG. These processes constitute the minimum environment for every
computer which is to operate in a FIDS/Linux network environment.
All other processes in the system can run on the MASTER computer, but are just as able to run
on INFORMATION SERVERS. The only restriction must be that all interface processes to external
systems must be running on the MASTER computer. The output handler processes can be
distributed to the INFORMATION SERVERS.

6.2.2. Standby computers

A STANDBY, or more precisely a HOT-STANDBY computer, has the task of monitoring one or
more computers in the FIDS/Linux network and, in the event of a crash, of standing in for the
affected computer and performing its tasks. Entries are made in the process table (pn.tab) to
indicate which STANDBY is monitoring which computer in the network. A STANDBY computer
behaves in a passive manner in the network. Only the WDOG process monitors the assigned
computers. In order to keep their data as up-to-date as all other computers in the network, all
changes to data made in the system are reported to the STANDBY computer ICGET process,
meaning that the local data records can be adapted accordingly.
A STANDBY computer is also able to monitor another STANDBY. If one fails, no handover takes
place: there would be no point in this because, usually, all STANDBY computers are identical
in terms of the data and processes they contain. Instead, the monitoring STANDBY unit simply
assumes the monitoring duties of the failed STANDBY unit, adding these to its own duties.
Theoretically, there is no upper limit to the number of STANDBY computers in the network.

6.2.3. Information server

The type of computer known as an INFORMATION SERVER really only relates to a sensible
grouping of output handler processes on separate computers. By decentralizing power in this
way, fast response times for information display can be achieved. In purely technical terms,
provided the aforementioned restrictions are taken into account, other processes can also run
on the INFORMATION SERVERS.
Theoretically, there is no upper limit to the number of INFORMATION SERVERS on the network.

Page 8 ServerManual-Vol3_1.0063_rev00
Head office & production:
CoNRAC GmbH Developed / Designed / Made in Germany
Lindenstrasse 8 · D-97990 Weikersheim · Germany
Tel.: +49-7934-101-0 · Fax: +49-7934-101-101
Specification subject to change without prior notice.
info@conrac.de · www.conrac.de
GM ServerManual-Vol3_1.0063_rev00
dAtA ModUL GRoUP

Subsidiaries & Sales Offices:

CoNRAC France - Paris
E-mail: info@conracfrance.fr
www.conrac.fr
Tel.: +33-3-44 54 96 99
CoNRAC MENA FZE - dubai CoNRAC Latin America - bogota CoNRAC Sales office Northern
E-mail: info@conrac.ae E-Mail: info@conrac.co Europe - Sweden
www.conrac.ae www.conrac.co E-mail: info@conrac.se
Tel.: +971-4-29 94 009 Tel./Fax: +57-1-34 65 338 www.conrac.se
Tel.: +46-42-21 29 39

CoNRAC Asia - Singapore
E-mail: sales@conrac-asia.com
www.conrac-asia.com
Tel.: +65-67 42 79 88
CoNRAC South Africa - CoNRAC Sales office Southern CoNRAC Sales office Northern
Johannesburg Europe - Rome Europe - Norway
E-Mail: info@conrac.co.za E-mail: info@conrac.it E-mail: info@conrac.no
www.conrac.co.za www.conrac.it www.conrac.no
Tel.: +27-83-63 50 369 Tel.: +39-06-45 43 92 02 Tel.: +47-52-77 63 85