RE: SQL and commitment control

<smith5646midrange>
That caused the STRSQL session to hang and eventually abend with a record in
use.

<snip>
multi user databases are needing record locks and timeouts to synchronize data access. This could cause problems for long lasting locks (record is locked longer than waitrecord). This could occur with and without commit controll. As a conclusion of this a user transaction must be shorter than a database transaction. In your case begin of transaction (first write operation after last commit) must not overlap any user transaction (EXFMT od READ of DSPF). So STRSQL will only wait millisecond and go on. It might be a good idea to adjust waitrecord of your files (60 seconds default are by far too much!!!)
</snip>

This can't be the answer because most of the other programs using the files
will not have any form of commitment control. I am only adding it to this
program so the users can cancel their changes and rollback.
</smith5646midrange>

You will see the same problem (hanging until record wait and abort), if you read for update, giving controll back to user, write the record some minutes or hours later on.
Commit is designed for writing multiple records in one transaction (e.g.: transfer of goods from one stock to another) Without commit it could happen seeing the goods twice or temporary disappearing. Doing it the right way, your application holds all changes internally and when the user decides to make the transaction happen, all changes are made without giving controll back to the user. In case of success of all updtaes the programm would issue a commit, in case of error rollback.

D*B