This article provides descriptions of the information contained in a displayed Informix APAR.
Resolving The Problem
Search for Informix APARs.
An APAR (Authorized Program Analysis Report) represents a formal report to IBM development of a problem caused by a suspected defect in a current unaltered release of an IBM program. After the report is filed, the IBM development team reviews the suspected defect to determine the appropriate disposition of the APAR, taking action to resolve those confirmed as actual defects in the IBM program.
IBM customers can obtain information regarding reported APARs from any of the IBM Product Support Centers. To access one of the Informix Product Support Centers, visit the Informix Product Family Support page.
Important: To access APAR information on the web, you must sign in using an IBM Registration ID. Your free ID is your single point of access to IBM web applications that use IBM Registration. If you are not currently registered, you can register now.
APAR Field information
|Indication of the APAR state.
|Description of the symptoms seen as a result of this problem, including
|Summary of users affected by this problem and how
|Description of where/how the problem was fixed
|A summary listing of the APAR information
APAR Closing Codes
|The record was cancelled, probably because it was created mistakenly or a customer requested that the record be cancelled.
|The problem was caused by an error in an IBM publication.
|The record was closed as a duplicate of an open record.
|Fixed If Next release. There is an intention to fix the deficiency if there is another release of the product. This is not a commitment, but expresses intention. 'Next release' is not defined.
|A programming error was found and will be corrected in a future release.
|A programming error was found but will not be corrected. It is a permanent restriction.
|The problem was caused by a user error.
When querying the sysmaster database syssqlstat table, the sqs_statement column shows an incorrect sql statement for the session
As workaround, instead of using column syssqlstat.sqs_statement, we can get correct results (sql statement) if retrieving column syssqexplain.sqx_sqlstatement. This other SMI table (syssqexplain) can be joined to syssessions by the session id (sqx_sessionid).
The sysmaster:syssqlstat column displayed the wrong sql statement for the sqs_statement column, and this was corrected.
Fixed in 9.40.xC9
|Reported component name
|Reported component ID
|Last modified date
Was this topic helpful?
07 December 2020