Die Situation: Ein Anwendungs-Programm bricht mit -805 (Package-Fehler) oder -818 (DBRM-Fehler, bis DB2 for z/OS V9.1) ab! Die folgende Beschreibung soll Dich bei der Analyse des Fehler unterstützen  und Dir mögliche Ursachen aufzeigen.

Vorgehensweise:

1. Aus dem Text der DSNTIAR-Meldung die voneinander abweichenden Timestamps bzw den Timestamp des Consistency Tokens notieren. Steht keine DSNTIAR-Meldung zur Verfügung, ggf. Monitor/Trace Information nutzen.
2. Per QMF, DSNTEP2 oder SPUFI aus SYSDBRM bzw SYSPACKAGE den TIMESTAMP bzw CONTOKEN hexadezimal ausgeben lassen. Unter der Spalte PDSNAME findet man die DBRM Source-Library. Ist das DBRM oder Package nicht vorhanden, dann muss der BIND wiederholt werden.
3. Im DBRM-Source des BIND PLAN oder BIND PACKAGE den Timestamp per Editor („FIND X’tstamp'“) suchen. Wird der Timestamp nicht gefunden, mus der BIND wiederholt werden.
4. Im Load Module per Browse Mode des Editors den Timestamp suchen. Aufgepasst: Die ‚Vollworte‘ des Timestamp sind hier umgedreht verzeichnet – der DBRM-Timestamp XXXXYYYY steht im Load-Module YYYYXXXX! Wird der Timestamp nicht gefunden, muss das Programm von einer anderen Load Library aus gestartet worden sein.

Häufige Ursachen eines SQL Codes -805 (bzw -818 bei älteren DB2 Systemen):

• Precompile, Compile und Link wurden ohne Bind ausgeführt
• Bind bezog sich auf eine inkorrekte DBRM Source-Library
• Precompile, Compile und Bind wurden ohne Link ausgeführt
• Ein altes Load Module kam zur Ausführung
• PACKAGESET-Register fehlerhaft und Package nicht gefunden oder nach Package statt DBRM gesucht
• SERVER-Register fehlerhaft u/o Package nicht auf Server gefunden