DFHTD0002 F68F in DFHTDRM during a restart of CICS

With a DFHTD0002 F68F message, often the problem is a corrupted keypoint record that has been restored from the system log during restart.

If that is the case, a delete and redefine of the DFHINTRA dataset followed by a COLD start of CICS should resolve the problem.

Otherwise, an INITIAL start generally resolves the problem.

But I have also seen a problem where a CICS job was restarted using system logs that were written from a different release of CICS. For instance, a CICS TS 4.1 region is restarted with logs that were written from a CICS TS 5.1 run.

You can see proof of this in the log data from the DFHTD0002 dump. The address of the log data can be found in the CICS exception trace entry that is written at the time of the error. (You can format the CICS trace entries with VERBX DFHPDxxx 'TR=2' where xxx is your release level of CICS like 690 for CICS TS 5.2).

The exception entry for DFHTD0002 F68F will look something like this:

 AP F68F TDRM EXC - Unrecognised_keypoint_record - FUNCTION(DELIVER_RECOVERY)  FORWARD_DATA(NO)  BACKWARD_DATA(NO)  KEYPOINT(YES) UOW(NO) DATA(2BFDDD05 , 00000240)  

The address of the log data is in the DATA parameter. In this example, DATA(2BFDDD05 , 00000240) shows that 2BFDDD05 is the address of the log data, and x'240' is the length of the data.

If you select option 1 from from the IPCS primary option menu to browse the address of the log data, you might see something like this:

Within the log data, following the >TDQUEUE header, is the release of CICS that wrote the records to the log. In this example, the release shows "680" which is CICS TS 5.1, but the release of CICS that is being brought up is CICS TS 4.1.

If the release of CICS shown in the log data is not correct, then you would need to investigate why CICS is being brought up using a release that is different than the release that wrote the keypoint records to the log.