A SNAplus2 configuration file is an ASCII text file with information stored
in readable text format. You can set up or check your configuration
using a standard ASCII text editor.
Although you can modify configuration files using a text editor,
you can do this only when the SNAplus2 software is not running.
It is recommended that you not modify the files in this way except
when setting up the initial configuration (before starting the SNAplus2 software).
To modify the configuration while the SNAplus2 software is running,
use the command-line administration program or the Motif administration
program. If you need to modify a node's configuration file using
a text editor, the SNAplus2 software must not be running on the node
or on the server for that node.If you need to modify the domain configuration
file using a text editor, you must first stop the SNAplus2 software
on all servers, modify the file on the master server, and then restart
the SNAplus2 software on the master server before restarting it on
any other servers.
 |
| |
|
 | NOTE: Both SNAplus2 configuration files are regenerated by
the owning server when a configuration command is issued, configuration
is changed using the Motif interface, or a configuration command
is issued. In these cases, any comments inserted into such files
are lost and the sequence of fields in the file may be changed. |
|
| |
|
A configuration file consists of a [define_node_config_file] or [define_domain_config_file] header
record followed by a series of [define_*] and [set_*] administration
records. Each administration record contains the parameters for
a SNAplus2 administration command. Header records and administration
records are used as follows:
The header record contains information
such as the SNAplus2 version number.
The [define_*] administration
records define the available resources: a local node and its resources
(node resources), or resources not associated with a specific node
(domain resources).
The [set_*] administration records
set parameters that determine how SNAplus2 operates, such as the
locations of diagnostics files and the types of diagnostics information
to record.
A node configuration file consists of a [define_node_config_file] header
record, a [define_node] record defining the node,
and a series of [define_*] and [set_*] records
defining the node's resources. The domain configuration file consists
of a [define_domain_config_file] header record
and a series of [define_*] records and [set_*] records defining
the domain resources.
The other types of administration commands (such as start_*, stop_*, and delete_*) are not used in a configuration file; those commands
are used only when administering a running SNAplus2 system.
For information about the order of these records within the
file, see “Record Ordering in
a Configuration File”.
Record Ordering in
a Configuration File |
|
In a node configuration file, the first record is the [define_node_config_file] header
record, which defines the SNAplus2 version number and the file's
revision level. The header record must be followed by a [define_node] record,
and then by [define_*] and [set_*] records
for all the resources associated with the node. The [define_node_config_file] record
is set up automatically by SNAplus2 when the configuration file
is created; you cannot access this record using the snapadmin program, and must not attempt to modify it when editing
the file.
In the domain configuration file, the first record is the [define_domain_config_file] header
record, which defines the SNAplus2 version number and the file's
revision level (and optionally includes a comment string describing
the contents of the file). The header record must be followed by [define_*] records
for domain resources. There is no restriction on the ordering of
domain resource records.
Record Format |
|
Each record is defined in the following format:
[command_name]
parameter_name = value
parameter_name = value
.
.
.
parameter_name = value
|
The command_name must be enclosed in square brackets. It is followed
by a series of parameter entries, each on a separate line. A backslash character
(\) at the end of a line indicates that
the entry continues on the next line.
All the parameters associated with a particular record must
be listed after the command_name for that record, and before the command_name for the next record in the file. However, the order
of individual parameters within a record is not important (except
where this is indicated in the command descriptions). Also, SNAplus2
provides defaults for many parameters, so you do not need to specify
every parameter explicitly. For more information, see “Parameter Syntax Used for Administration Commands”.
The following example shows one way the [define_lu_0_to_3] record can
be specified. For full details of the parameters associated with
this command, see “define_lu_0_to_3”.
Because the priority parameter is not included, SNAplus2 uses the default
value of MEDIUM. The optional parameters
description and pool_name are also not included.
[define_lu_0_to_3]
lu_name = LU$01
nau_address = 1
pu_name = PU2
lu_model = 3270_DISPLAY_MODEL_2 |
Subrecord Format |
|
Some configuration records include data whose format can vary
between instances of that record type. For example, the [define_cos] record includes
a variable number of node rows and TG rows. To handle this variability,
the variable data is specified in optional subrecords. This means
that a record consists of a series of parameters common to all instances
of that record type, followed by subrecords containing the variable
data.
A record that contains one or more subrecords is defined as
follows:
[command_name]
parameter_name = value
.
.
parameter_name = value
{subrecord_name}
parameter_name = value
.
.
parameter_name = value
{subrecord_name}
parameter_name = value
.
.
parameter_name = value
|
The subrecord_name must be enclosed in braces. It is followed by a series
of parameter entries associated with this subrecord, each on a separate
line.
All the parameters associated with the command_name (and not with a subrecord) must be listed after the command_name and before the first subrecord_name; all the parameters associated with a particular subrecord_name must be listed after that subrecord_name and before the next subrecord_name, if any, or the next command_name. However, the order of individual parameters within
a subrecord is not important. For more information, see “Parameter Syntax Used for Administration Commands”.
Printable version
