Accounting records are written when one of the following occurs:
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.