Commitment control & journaling

Commitment control groups eligible changes into a unit of work that can be committed or rolled back. Its purpose is to preserve business consistency across multiple operations, such as reducing inventory and recording an order.

The application must establish the relevant commitment definition, open/access resources under the intended rules, and choose commit boundaries. Adding a COMMIT statement after unrelated nonparticipating operations does not retroactively make them atomic.

Journaling records changes and supports recovery capabilities. Database updates under commitment control require the appropriate journaling setup. Journaling alone does not mean every application operation is inside a transaction.

Verify the files or tables, journal configuration, SQL commitment options, and native-I/O settings used by the real job. A table can be journaled while an application accesses it without commitment control. Explain both the recovery mechanism and the application’s transaction policy.

A commitment definition can be scoped to a job or to an activation group, subject to the platform rules. Scope determines which participating work shares the definition. It is distinct from simply placing files in the same library.

When two procedures must succeed or fail together, confirm that they operate under the same intended definition. Test a failure in the second procedure and verify the first procedure’s changes roll back. A diagram of calls is insufficient without the runtime scope.

The component that knows the complete business unit should normally coordinate the transaction. Lower-level reusable routines should document participation and avoid silently committing their caller’s unrelated changes.

For example, a posting coordinator can call debit, credit, and audit routines, then commit only after all succeed. If each helper commits independently, the coordinator cannot guarantee atomicity. Define error propagation and rollback ownership in the procedure contracts.

Rollback covers participating transactional changes. It does not generally retract an email, unsend a network request, undo arbitrary IFS output, or reverse ordinary queue operations simply because they happened between database statements.

Inventory external side effects and design a recovery protocol. Use durable intent, idempotent consumers, or compensating business actions as appropriate. Never promise atomic behavior across independent systems without a mechanism that actually coordinates those systems.

Capture the original error, stop further business updates, and roll back the intended unit if the transaction outcome is known and rollback is appropriate. Report a result that distinguishes business rejection from technical failure.

If the connection disappears during COMMIT, the outcome may be ambiguous to the caller. Query a durable operation identifier before retrying. Repeating the entire request blindly can duplicate a transaction that committed successfully even though its response was lost.