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

1. A user application program (UAP) creates an update of IST record 1, in IST table A on node A.
2. The UAP acquires the current machine time at microsecond accuracy, and assigns the time to the record's update as a timestamp.
3. OpenTP1 compares the assigned timestamp with the timestamp of the corresponding IST record in the shared memory on node A.
   If the timestamp of the record's update is newer, OpenTP1 updates the IST record in the shared memory. If the timestamp of the record's update is older, OpenTP1 does not update the IST record in the shared memory. The dc_ist_write function returns normally even when it does not update any IST records.
   
4. If an IST record in the shared memory is updated, the IST service on node A notifies the IST service on node B that an IST record was updated on node A. At this time, the updated IST record and its timestamp are also reported.
5. Upon reception of the updated IST record and its timestamp, the IST service on node B compares the timestamp of the received IST record with the timestamp of the corresponding IST record on node B.
6. If the timestamp of the received IST record is newer, the corresponding IST record on node B is replaced with the received one.

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:

• When node A's machine time is ahead of node B's
  If an IST record is updated on node A and then the same IST record is updated on node B, the timestamp assigned on node A may be newer. In this case, if the timestamp assigned on node A is newer, the record updated on node B is not applied to node A.
  Also, when the IST record updated on node A is reported to node B, the IST service assumes that the reported IST record is the latest one. In this case, the reported IST record replaces the one that was actually updated later.
  
• When node A's machine time is behind node B's
  
  • When an IST record was updated on node B and the updated IST record has already been reported to node A
    After the IST record update on node B, even if the same IST record is updated on node A, the dc_ist_write function returns normally without updating the record.
    
  • When an IST record was updated on node B but the updated IST record has not yet been reported to node A
    After an IST record is updated on node B, if the same IST record is updated on node A, the IST record updated on node A is at first applied to node B. However, because the IST service assumes that the timestamp of the IST record reported by node B is newer, the IST service then applies the older reported update to node A.