Procedure Definition Language Statements › Exclusive Control › Secondary Exclusive Control

Secondary Exclusive Control

Secondary exclusive control gives the application control over when the update of a group of dependent records is committed.

For instance, you might need to update a master record with totals from three different detail records. The processing requires that the three detail records and the master record either all be updated or all backed out. Data integrity is lost if two of the detail records were updated and an error was discovered on the third detail record. In this case, the update of the first two detail records should be backed out, an appropriate error message issued to the terminal operator, and the master record update never attempted.

When the record is updated just before the ENDFOR, primary exclusive control ends and secondary exclusive control begins. Thus, as each record is processed and updated, it is added to the group of records the task holds under secondary exclusive control.

In the above example, if the URT specifies TXNUNDO=YES and the MUF master list specifies LOGGING=YES, secondary exclusive control is in effect, in addition to primary exclusive control.

The important points to note about secondary exclusive control in the example are:

• A task can have many records under secondary exclusive control at one time.
• As the records that meet the FOR/WHERE/ORDERED BY criteria in the set are processed and updated, they are added to the group of records held under secondary exclusive control. When the first record of the set is read with primary exclusive control, no records of the set are held under secondary exclusive control. When the last record of the set is updated, all the records of the set are held under secondary exclusive control. See the next point for an exception.
• Secondary exclusive lasts until the task terminates, until a TRANSMIT is issued, until a CHECKPOINT is issued, or until a CICS SYNCPOINT is issued.
• While a record is held under secondary exclusive control, no other task can read that record with update intent. Therefore, another task cannot simultaneously delete or update the record.
• Generally, if a record is under primary exclusive control, it is not under secondary exclusive control. However, it is possible for a task to hold the same record under both primary and secondary exclusive control.

This can occur if the task reads the record with update intent (through the CA Datacom/DB commands RDUKY, SELFR, or SELNR), updates the record (UPDAT), and reads the record again with update intent (RDUKY, RDUID, SELSM, SELFR, and so on). This occurs in CA Ideal in the following situation:

FOR DVW‑UPDATE
             WHERE num‑value = 'nnnnn'
             MOVE ...   to DVW‑update‑field
             MOVE ...   to DVW‑update‑field
ENDFOR
FOR DVW‑UPDATE
        WHERE num‑value = 'nnnnn'
             ...
ENDFOR

If the value for num‑value were the same for both FOR statements, the record is read for update and updated by the first FOR construct. It is then read again (using the SELFR DB command) for update. At this point, it is held under both primary and secondary control.

FOR EACH DVW1
         FOR EACH DVW2
                  SET ...
                  SET ...
         ENDFOR
         SET ...
         SET ...
ENDFOR

In this example, the FOR statement for dataview DVW2 is nested in the boundaries of the FOR statement for dataview DVW1. Once the FOR statement for DVW2 is encountered, two records are held under primary exclusive control at the same time, one record from DVW1 and one record from DVW2. As the two sets of records are processed, records from both sets are added to the records held under secondary exclusive control by this task.

FOR EACH DVW
         CHECKPOINT
         SET ...
         SET ...
ENDFOR

In this example, a CHECKPOINT is issued in the boundary of the FOR/ENDFOR construct. A CHECKPOINT applies to all records held under secondary exclusive control.

This means that, because each record is held under primary exclusive control while it is being read, the CHECKPOINT does not commit the record while it is read. Not until the next iteration of the FOR, when the next record is read, does the previous record come under secondary exclusive control and become committed.

The important points to note here are:

• When the CHECKPOINT statement is encountered, all updated records currently under secondary exclusive control are committed. That means that if the task abends, these updates are not backed out.
• As a result of the CHECKPOINT command, other tasks can update all records committed by the CHECKPOINT statement.
• If there are multiple FOR statements preceding the CHECKPOINT command, the CHECKPOINT command releases all records held under secondary exclusive control by those FOR statements.

  FOR EACH DVW1
           CHECKPOINT
           FOR EACH DVW2
                    SET ...
                    SET ...
           ENDFOR
           SET ...
           SET ...
  ENDFOR
  

This FOR construct illustrates the example of the master record (dataview DVW1) and its corresponding detail records (dataview DBW2) committed if all are successfully updated. If the update of the detail records proceeds normally and the master record is also updated successfully, a CHECKPOINT command is issued to commit the successful updating of the dependent records. The master and detail records are released from secondary exclusive control making them available for updating by other tasks.

FOR EACH DVW
         SET ...
         SET ...
         TRANSMIT panel
         SET ...
         SET ...
ENDFOR

In this example, a TRANSMIT statement is issued in the scope of the FOR construct. The TRANSMIT releases both primary and secondary exclusive control. If a record is held under secondary exclusive control, it is checkpointed. If a record is held under primary exclusive control, it is released.

When the run continues normally, the update logic detects at the ENDFOR that the record was released due to a TRANSMIT, rereads the record to re‑establish primary exclusive control, and updates it. If another user task read and updated the record between the TRANSMIT and the update of the record, a CA Ideal run‑time error with a $ERROR‑DVW‑STATUS of I3 is issued. If another user task deleted the record between the TRANSMIT and the update of the record, an CA Ideal run‑time error with a $ERROR‑DVW‑STATUS of I2 is issued.

If the task abends after the TRANSMIT, the records that were updated and held under secondary exclusive control are not backed out because the TRANSMIT checkpoints them.

The important points to note here are:

• A TRANSMIT releases all records currently held under either primary or secondary exclusive control by the task.
• If the TRANSMIT is in the scope of a FOR construct, CA Ideal ensures the integrity of data for records read for update across transaction boundaries (that is, those that were held with primary exclusive control at the time of the TRANSMIT).