The LOGPR command is used internally by CA Datacom during the two-phase commit processing which is controlled by Resource Recovery Services (RRS). RRS is invoked when a transaction updates multiple database systems (e.g. Datacom and DB2). During phase 1 of the two-phase commit process a LOGPR command is issued to indicate Datacom is waiting on another resource manager to confirm the transaction can be committed.
If the task is waiting a long time in LOGPR it indicates something went wrong in the two-phase commit process.
For CICS tasks, if CICS is down, do a normal CICS start.
Datacom CICS Services has code to perform resynchronisation and will detect units of work that have not been committed and notify the MUF. This will then cause the waiting task in the MUF to be cleared. It needs to be a normal CICS start not a COLD START. Doing a COLD START you will cause a loss of synchronization data so no resynchronisation is possible.
If CICS is already up, perform the following:
- Find the number of the MUF in question by issuing a DBEC I,MUF(??),SYSID(*)
- Issue a DBEC PERFORM,IMMEDIATE,MUF(nn) this will terminate the connection to the MUF and then automatically reconnect. A DBOC SHUTDOWN followed by a DBOC STARTUP will also have the same effect.
Depending on the status the LOGPR task may not clear up automatically after it reconnects, in this case you need to commit or rollback the LOGPR task using REQCOMIT or REQROLBK commands.
Doing a CICS CEMT SET TASK FORCEPURGE of the task involved in the two-phase commit can cause problems with resynchronisation and cause the MUF task to remain in LOGPR wait status, in this case a CICS restart may be the only option.
For a batch job, you need to investigate what happened to the job then determine if you need to commit or rollback the LOGPR task using REQCOMIT or REQROLBK commands.
REQCOMIT and REQROLBK are Datacom console commands. The format is:
Where nnnnn is the sequence number of the request to be committed or rolled back.