Updating Techniques, SYNCPOINT, and Logging › Special Logging Commands Considerations › Examples of SYNCPOINT and LOG Commands in a Multiple MUFs Environment

Examples of SYNCPOINT and LOG Commands in a Multiple MUFs Environment

All of the examples that follow show only the process for the CA Datacom/DB log request.

Example 1

An application program issues updates to DB2, VSAM, MUF1, MUF2, and MUF5 followed by a CA Datacom/DB COMIT. The updates to DB2 and VSAM do not prevent CA Datacom CICS Services from converting this request into a SYNCPOINT. CICS in turn issues a two-phase commit because multiple resource managers have update type resources involved.

Example 2

An application program has issued updates to DB2, VSAM, MUF1, MUF2, and MUF5 and has RDUxx (outstanding read-for-update without the update), then it issues a LOGCP. The LOGCP causes a SYNCPOINT and because multiple resources are being updated (or have update intent), a two-phase SYNCPOINT occurs. However, all update-intent records in CA Datacom/DB remain locked and ready for an update after the LOGCP/SYNCPOINT was issued.

CA Datacom CICS Services then returns to the user application that issued the LOGCP. The user can then issue updates on records previously held with exclusive control even though a COMIT was issued.