Datasheet

Release Notes - New Features included in Release 2.4.0
Page 77 of 89
The first of these provides the means to force an instance to shut down after a specified period of
time even if something, e.g. a child process that doesn’t exit, prevents the instance from shutting
down normally within that time. This forced shut down can be achieved by using a new Operator
Interface command parameter, -force, when shutting down an instance. This parameter can be used
with either the down –system –shutdown or the shutdown command. The required period of time
for the forced shutdown is specified as a value with the –force parameter. This value defines the
number of minutes for which the instance must wait for a normal shut down to complete before it
will force any remaining child processes to exit and shut itself down. If no value is specified the
instance will use a default period of 5 minutes.
The second new feature is the introduction of instance ‘health checking’, which allows an instance
to check its own configuration and to restart any child processes that should be running but are not.
This checking is carried out automatically at regular intervals while an instance is running. The
interval between each check is calculated from the same parameters used in the automatic Online
Server start/stop algorithm. For use with the configuration checking the interval is the number of
checks multiplied by the interval between checks, e.g. if the number of Online Server checks is
defined as 10 and the interval between them is defined as 30 seconds, the configuration check will
be performed every 5 minutes. It is also possible to perform a manual configuration check at any
time by using the new Operator Interface command check, which must be used in control mode and
takes no parameters.
4.3.5.18 pbzhist file (SR4450)
When performing software upgrades, details of each mandatory run are written to a sequential text
file. There are no details written to the database of which mandatory has been run against that
database. This poses no problems until a backup of the database is restored into its own or a
different database slot. This can result in software failures due to a mismatch between the database
and software.
To prevent this being a problem, details of mandatories that affect the database are written to a new
database table. Those mandatories that affect the environment (non-schema) will continue to be
written to the sequential text file.
The TROPOS software version is also now written to a database table.
Thus if a database is restored into an environment having a later software release; the schema
mandatories need to be run; the non-schema ones don't.
If a database is restored into an environment having an earlier software release; it will not work
without installing a version of software matching or greater than the database and then updating the
environment and database.
The processor monitor will compare the two version numbers and, in a production environment, it
will refuse to run if these are un-equal.
The new table may be accessed and changed using the pbzhist program. This will work either in a
command line mode or an interactive mode. The command line mode is reserved for use by
updatedb.
Please refer to the TROPOS Navigator for more information on scripts and subroutines.