This page applies to Multiple Resilience Configurations Only
The Network Layout table is called @NETWORK and contains the following fields:
| Field Name | Description |
|---|---|
network.number
|
Table number to which layout applies, or zero for the default layout. |
network.parent.numbernetwork.role.numbernetwork.old
|
Reserved: must be set to zero |
network.dtype
|
Not used |
network.machine
|
Array of server numbers to use |
network.local
|
Local/remote flag |
network.nr_machines
|
Number of entries used in server
array (network.machine)
|
network.vital_machines
|
Number of entries in server
array (network.machine) that refer to
servers that must be online when programs
try to update records on them.
|
network.nr_prefixes
|
Reserved : Must be set to zero |
network.machine should
have valid, different server numbers entered from the lowest
element upwards. Zero is a valid server number, meaning
'local'. AUXDISTR will consider as many
elements as the value of network.nr_machines. So, if the values in
network.machine are:
4 3 0 1 0 0 0 ...
if nr_machines is 2, the servers to
be accessed are 2 and 3;
if nr_machines is 3, the servers to be
accessed are 2, 3, and the local machine;
if nr_machines is 4 the
servers to be accessed are 2, 3, 1 and the local machine;
if
nr_machines is more than 4, there is an undefined effect from
supposedly accessing the local machine twice.
The vital_machines field sets an initial number of machines in network.machine which must be online when an application tries to update them. For example, if a program is set to update a table on server 1 and 2, so that nr_machines is 2, the update will normally succeed if either server is online. If vital_machines is set to 1, then assuming 1 is the entry in machine[0] an update will only succeed when server 1 is online (unless AUXDISTR has reverted to local mode because no servers are available).
The network.machine array is usually ignored if the local flag is set, in this case only the local database is accessed or updated, although the LOCN_OVERRIDE flag can override this. See How the 'local Flag is Used for full details of the local flag.
While multiple server resilience is in operation, fetches, posts and deletions on the @Network table do not go to the database, but operate on the internal layout data held within the AUXDISTR program. If there is more than one application program on a machine, each has its own entry in the AUXDISTR tables. Thus, each application program can be accessing different servers.
One entry will appear in this table for each table on the database, and also one extra entry (with key 0) representing the default layout. When a program starts up, the default layout is as specified by the command tails, and every table follows the default layout unless there is an overriding persistent entry in the local database (see below). (If the -nolocal command tail is in use then persistent entries will be read from whichever server(s) are used for accessing the @network table).
Posting an entry with a zero key to the @NETWORK table overrides the default layout. The layout for every table currently following the default will be changed.
Deleting an entry with a zero key from the @NETWORK table causes the default layout to revert to that specified by the command tails. The layout for every table currently following the default will be changed.
Posting an entry with a non-zero key to the @NETWORK table overrides the layout information for the specified table. The specified table will no longer follow the default or the information held on the database, but will use the posted layout instead.
Deleting an entry with a non-zero key from the @NETWORK table causes the specified table to follow the current default layout. Tables with a persistent overriding layout do not revert to that layout, but also revert to the current default layout.
Updates to the @NETWORK table take effect immediately, and are not postponed to the next commit()or checkpoint().
An application can fetch records in the @network table at any time to check how a particular table is accessed and updated. For example if you want to use the LOCN_OVERRIDE flag to temporarily switch how a table is accessed (for example by fetching remotely and posting locally, or vice versa) you could check the current setting of network.local to see whether to apply the LOCN_OVERRIDE flag to calls to rec_fetch() or calls to rec_post().
Records may exist in the @Network table on the database to set the default layout for tables; these must be posted while the system is in non-resilient mode. In order to do this you need to know the table numbers for which records are required. You can use BROWSER -BASEDICT to do this (but you will need to run outside the DP4 menu and set your access levels to 255 255 with DFSETUP), or you can write a simple application program to create the required records.
The 'local' field in persistent records is ignored as this information is set up using MAKEDB −expert and held in the @RELDATA table. See How the 'local' Flag is Used for details.
You should not create a permanent record with a zero key in an attempt to override the default layout - any such record will always be ignored. Permanent records for the @reldata and @network tables will also be ignored, because reading them would involve an endless recursion.