Capture all error SQL Codes regardless of where it was generated

According to the manual

Query Monitor operates ‘inline’ with SQL related execution that takes place on the host. Certain database processing activities engage ‘off-host’ components, which are called ‘distributed’ or DRDA applications. Once a transaction moves ‘off-host’, Query Monitor will be unable to correlate the end of a transaction to the start until the transaction returns to the host. For example, when an accelerator takes over the transaction, it appears to Db2 z/OS as being remote or not part of the engine. In such cases,

∙ SQLCODE may be returned to the originating transaction, but only after the remote process (and not Db2) has populated the SQLCA of the application.

∙ Query Monitor is not posted about the success or failure of the transaction, so it appears to ‘lose’ the SQLCODE and not be inline with the second part of the transaction.

There is no definitive list of the SQLCODE that falls into this category. But users should be aware that any discrepancies between the codes presented on the appliance ‘console’ and in Query Monitor may fall directly into this category.

We have seen SQL statements being cancelled within IDAA because of resource constraints. In the output from ACCEL_GET_QUERIES2, it shows the SQLCODE. Sometimes we see a -904, other times, we see -952. Regardless, we would like to be able to report on this activity and create exceptions if we so desire. But we need to have the SQLCODE captured first.

Case TS019129028 is what we opened that ended up bringing light to this situation.