Application behavior when replication state is BLOCKED

SQL application behavior when the replication state is BLOCKED

SQL applications that run on the secondary node should be coded to handle a failure when the Db2 Mirror replication state is BLOCKED.

SQL statements that encounter a blocked condition in Db2 Mirror can fail with either SQLCODE = -7061 and SQLSTATE = '55019' or SQLCODE = -918 and SQLSTATE = '51021'.

• Any SQL statement that attempts to modify a replicated database object from the secondary node could return SQLCODE = -7061 with reason code 71.
  • 71 -- Replication has been interrupted and mirroring is currently blocked.

  In the corresponding application joblog, the SQL7061 escape message will appear, with 71 as the reason code.

• SQL applications using a commitment control isolation level other than *NONE or *NC could fail with SQLCODE = -918.

  The SQLCODE = -918 indicates that not only did the attempt to modify the replicated database object from the secondary node fail, but also that the job in question is in a state where the transaction is required to rollback.

  The requirement to rollback on the secondary node when a transaction encounters a failure related to BLOCKING protects replicated objects from getting out of sync.

RPG behavior when the replication state is BLOCKED

No new RPG status codes are associated with application failures due to running on the secondary node when the replication state is BLOCKED.

When a blocked node failure occurs during an open operation for a file defined to be output-capable, update-capable, or delete-capable, the RPG status code will be either 1216 for an implicit open or 1217 for an explicit open. When a failure occurs during a write, update, or delete I/O operation, the RPG status code will be 1299.

For an error during an explicit open operation or an I/O operation, the subfield in positions 46 to 52 in the File Information Data Structure (INFDS) for the file will contain the message ID causing the error. RPG programs can check that subfield for CPF411F to determine whether the error was due to a DML failure.

RPG exception messages (RNX1216, RNX1217, or RNX1299 for ILE RPG) or inquiry messages (RNQ1216, RNQ1217, or RNQ1299 for ILE RPG or RPG1216, RPG1217, or RPG1299 for OPM RPG) will show the error message causing the error.

In addition, the CPF411F failure message will remain in the job log.

COBOL behavior when the replication state is BLOCKED

ILE COBOL and OPM COBOL have different handling for application failures due to running on the secondary node when the replication state is BLOCKED.

For ILE COBOL, a new COBOL file status key value is associated with failures related to running on the secondary node when the replication state is BLOCKED. When a blocked node failure occurs during a file open or I/O operation, file status 9Z will be set if the FILE STATUS clause was specified for the file.

For OPM COBOL/400, no new COBOL file status code is associated with blocked node failures. Rather, when a blocked node failure occurs during a file open or I/O operation, file status 90 will be set if the FILE STATUS clause was specified for the file.

If you don't have a FILE STATUS clause or a USE PROCEDURE to handle the error, then in ILE COBOL you will get an error such as LNR7057, LNR7200, or LNR7207, and in OPM COBOL you will get an error such as LBE7200 or LBE7207.

In addition, the CPF411F failure message will remain in the joblog.

C behavior when the replication state is BLOCKED

When a blocked node failure causes an I/O error in a C program, it will surface as a normal I/O error with errno 3101.

CL command behavior when the replication state is BLOCKED

IBM® i CL commands that try to create or change replicated objects will fail when the replication state is BLOCKED. The CPFC901, CPF4ACF, or CPF4ADB escape messages can be returned for these failures. The message contains details about the failure.