ADA742 ABEND=S000 U0253 REASON=00000000

Our production database abended with

15:12:07 ADAN42 00214 2006-12-16 15:12:06 Function accepted 15:27:18 ADAI29 Oper cmd: SYNCC 15:27:18 ADAN41 00214 2006-12-16 15:27:17 Function completed 20:15:00 ADAI29 Oper cmd: SYNCC 20:15:00 ADAN41 00214 2006-12-16 20:15:00 Function completed 20:15:02 ADAI29 Oper cmd: FEOFPL 20:15:03 ADANR1 00214 Smart Management handling condition 84878000 20:15:03 ADANRT 00214 Condition is a SYS error 20:15:03 ADAH50 00214 Dump format called

ABEND CODE 84878000 PSW 070C1000 8131BFB2

After the restart, it seems that the nucleus did repair the checkpoint file (19):

20:38:36 ADAN21 00214 Protection log PLOGR1 started 20:38:36 ADAN02 00214 Nucleus run with protection log 01802 20:38:36 ADAL02 00214 2006-12-16 20:38:36 CLOGRS is active 20:38:36 ADAI64 File DDRLOGR1 is being opened in ECKD mode - RABN size 27990 20:38:36 ADANI2 00214 SMGT abend handler active 20:38:36 ADAN03 00214 ADABAS coming up 20:38:36 ADAN55 00214 Recovery data found on Work dataset(s) 20:38:37 ADAN56 00214 Backward repair done 20:38:37 ADAN56 00214 Forward repair done 20:38:37 ADAN56 00214 Autobackout done 20:38:37 ADAN5A 00214 Files modified during autorestart: 20:38:37 ADAN5A 00214 00019

We had problems with the checkpoint file before, applied all available zaps and created the checkpoint file from scratch.
Highest ZAP numbers AI742078, AN742463, AO742063, AU742190
The CP problem has been reported under #585201 (Aug 2005). Maybe this abend has nothing to do with CP file.

Did anyone experience this or a similar problem?

By the way, LA Times is no longer a customer but a user. And a solution might help others.

Dieter Storr
prod.db2.server.log.G0634V00.txt (69.2 KB)

Please open a support request. That is the appropriate way to ensure that a solution can help others, hopefully by preventing it from happening to others.


As I pointed out, we are no longer a customer and therefore, we cannot open a request.

Dieter Storr, LA Times