OpenTP1 Version 7 Description
The IST service allows information from all nodes in a group to be shared among the nodes and to be accessed from any node in the group. The information is stored in special tables called internode shared tables (ISTs). The IST service stores internode shared tables in shared memory, and enables UAPs to reference and update the tables without knowing the actual physical locations of the information that makes up the tables.
To use internode shared tables, TP1/Shared Table Access must be installed on each node.
As an example of how internode shared tables can be used, you could place job-status information from various nodes into internode shared tables. This would allow you to check the job status of all nodes from any node. This shared access to job-status information simplifies the management of jobs.
Figure 4-21 illustrates the configuration of the IST service.
Figure 4-21 IST service configuration
To use the IST service, make sure that all the nodes have the same IST table definition.
In Figure 4-21, different table names are specified in the IST table definitions of nodes A, B, and C. Thus, nodes A and B continue to output the KFCA25533-W message periodically until OpenTP1 terminates. This message notifies you that invalid table information was received.
The IST service is not recommended, however, for the following cases when distributing data to multiple nodes:
Internode shared tables exist in memory shared by each node. No actual file, such as TAM, DAM, or ISAM, stores an internode shared table. UAPs can access internode shared tables during online processing only; the tables cannot be accessed offline.
An internode shared table consists of multiple records. When a UAP references or updates an internode shared table, the table data is accessed in units of records, and one request from a UAP can access one record or access multiple records.
For details on how to access an internode shared table from a UAP, see the OpenTP1 Programming Guide. Transaction functions cannot be used for commit or rollback operations when accessing an internode shared table.
An internode shared table is locked for each function called from the UAP. Access to an internode shared table is not monopolized during the period from input to changing of data, so no deadlock will occur even if multiple UAPs access one table.
Figure 4-22 shows an example of effective use of the IST service.
Figure 4-22 Example of effective use of the IST service
In Figure 4-22, only node A updates IST table A, and only node B updates IST table B. When data is updated at any node, the IST service reports and applies the change to other nodes. Thus, any node can reference up-to-date IST tables. This configuration is effective in that only one specific node can update a specific IST table.
For example, suppose that node A writes its status information to IST table A, and node B writes its status information to IST table B. In this case, if you create IST table C in which node C can write and update its status information, each node can reference the other nodes' status information. Note that there is a delay due to communication with other nodes for applying the change to their IST tables. Before the change is applied, other nodes reference the old information.
When multiple nodes use the IST service, make sure that there is no time difference among the nodes. If there is a time difference, updates at a node might not be correctly applied to other nodes. The following figure illustrates how the IST service updates IST records (records in the IST tables) on multiple nodes.
Figure 4-23 How IST records are updated
As described above, the IST service uses the timestamp to decide whether to update the IST record. Note, however, the IST service may be unable to apply the latest data in the following cases:
All Rights Reserved. Copyright (C) 2006, 2010, Hitachi, Ltd.