Accounting records are written when one of the following occurs:
The SQLHX command causes a rollback, which causes an accounting record to be written for the work done to that point. If no additional database work is done, and the application exits, COMMIT WORK or ROLLBACK WORK processing occurs, and a second accounting record is written. Because no work is done on the database for the second accounting record, the following fields may be empty:
For example, suppose user ID USER1 uses ISQL to implicitly connect to the database manager, does some work, and then explicitly connects as authorization ID SQLDBA to do tasks requiring DBA authority. When USER1 changes authorization IDs, the database manager writes an accounting record for authorization ID USER1 and begins a new session for authorization ID SQLDBA, even though USER1 did not explicitly release the first connection.
For example, suppose USER1 uses ISQL with AUTOCOMMIT ON, and never issues a COMMIT or ROLLBACK WORK RELEASE. The session therefore lasts until this user reconnects or leaves ISQL. If this user works on ISQL for hours and processes many logical units of work during this long session, he or she exceeds the resource threshold a number of times. Every time this happens, an accounting record is written. Now suppose the database manager abends. The only accounting information lost is for work that USER1 did after last exceeding the threshold. If the internal threshold were not used, all accounting information about USER1's session would have been lost, which represents a significant amount of work.
The database manager does not write an accounting record for every logical unit of work, because too many records would be generated, resulting in high system overhead. Because most ISQL users use AUTOCOMMIT ON, practically every SQL statement issued would cause a new LUW.
If your users are using DRDA protocol, the database manager also generates accounting records for them in addition to the CMS user record. For a description of the accounting records, see Remote User Records.
If you have VSE guest sharing, the database manager also generates accounting records for VSE guest users. These records are similar in format to the accounting records for DB2 Server for VM users on VM. The VSE guest user records are generated on the database machine. For a description of the records, see VSE Guest User Records.
The database manager processes batch/ICCF users on VSE as individual users. All CICS users are processed as one user, and are identified by the user ID that CICS uses.