Unit of Work

A unit of work (UOW) is the basic unit of recovery in CICS. It is a set of changes that must all succeed together or all be undone together - the classic 'all or nothing' rule.

What a unit of work is

• A unit of work is a sequence of changes to recoverable resources that CICS treats as one atomic operation.
• In many cases one CICS transaction equals one unit of work, but a transaction can contain several units of work if it issues syncpoints.
• Each unit of work has a unique identifier (UOWID) that appears in messages, dumps and operator displays.
• Units of work cannot span transactions - a UOW always ends when its task ends.

Unit of work boundaries

• A unit of work begins when the task starts, or just after the previous syncpoint.
• It ends at an explicit EXEC CICS SYNCPOINT, at SYNCPOINT ROLLBACK, or implicitly when the task ends.
• Between the boundaries, CICS holds locks on every recoverable record the task updates, protecting them from other tasks.
• Example - one transaction doing two separate units of work:-
  *-- UOW 1 starts at task start
  EXEC CICS READ FILE('ORDMAS') ... UPDATE END-EXEC.
  EXEC CICS REWRITE FILE('ORDMAS') ... END-EXEC.
  EXEC CICS SYNCPOINT END-EXEC. *> UOW 1 ends here
  *-- UOW 2 starts here
  EXEC CICS WRITEQ TS ... END-EXEC.
  EXEC CICS RETURN END-EXEC. *> UOW 2 ends at task end

Units of work and locking

• While a unit of work is open, other tasks that try to update the same records are made to wait.
• Long units of work therefore cause lock contention, waits and even deadlocks - keep each UOW as short as the business logic allows.
• Conversational tasks hold their locks across terminal reads, which is why pseudo-conversational design is preferred.