Jeg vil starte med at ønske alle mine læsere en god jul og et godt nytår. Det næste tip udkommer den 2. januar.
Merry Christmas and a happy new year to all of you. The next tip will be published on the 2nd of january.
En af de mest irriterende SQL-fejl er SQLCODE -805. Den har egentlig ikke noget med SQL-kaldet at gøre og kan opstå på de mest uventede tidspunkter. Jeg vil i det følgende efter bedste evne belyse, hvorfor du får SQLCODE -805, og hvordan du løser problemet. Allerførst skal vi se på, hvilke informationer DB2 stiller til rådighed på en -805. Hvis fejlhåndteringen på din installation formaterer indholdet af SQLCA arealet får du forhåbentlig en fejltekst i stil med denne:
Hvis SQLCA arealet ikke er formateret, så kan du finde oplysningerne location-name.collection-id.dbrm-name.consistency-token, plan-name og reason i feltet SQLERRMT. Heldigvis er især consistency-token let genkendeligt, og i de fleste tilfælde også den vigtigste information. Consistency-token er en formateret hexadecimal tegnstreng på 16 karakterer, som derfor repræsenterer 8 bytes.
Du har nu lokaliseret location-name, collection-id (som næsten altid er uudfyldt), dbrm-name (programnavn, der udstedte SQL-kaldet), consistency-token, plan-name og reason. Først og fremmest skal du undersøge om dbrm-name er med i pakke-listen til plan-name. Det gør du ved at undersøge værdien af reason. Hvis reason er 01 eller 02, så er dbrm-name ikke med i pakke-listen til plan-name. Du skal altså BIND'e planen om, så dbrm-name kommer med i pakke-listen.
Hvis reason hverken er 01 eller 02, så er din pakke-liste sandsynligvis OK og problemet er oftest, at det loadmodul, du eksekverer, indeholder et forkert consistency-token. Og her skal du være vågen. Det 16 bytes lange formaterede consistency-token stammer fra det loadmodul, der fik SQLCODE -805 og dermed ikke fra DB2. Der er nu to muligheder. Enten eksekverede du et andet loadmodul end det du troede (eksempelvis en nyere version eller et loadmodul fra et helt andet loadbibliotek), eller også findes dbrm-name i flere collections og den collection, som din plan er bundet med er den forkerte.
Den hyppigste årsag til SQLCODE -805 er, at du eksekverede et andet loadmodul end du troede. Du kan vha. consistency-token finde ud af hvilket loadmodul, du rent faktisk eksekverede. Gå i browse på det loadmodul, du tror, du eksekverede, da SQLCODE -805 opstod og lav en FIND X'consistency-token' FIRST. Hvis du ikke får noget hit, skal du bytte de første 8 tegn af consistency-token med de sidste 8 tegn og prøve igen. Hvis det stadig ikke giver resultat, så ved du med sikkerhed, at det var et andet loadmodul, der fik SQLCODE -805. Der er altså på en eller anden måde gået kuk i søgningen efter loadmoduler. I batch skal du undersøge din STEPLIB/JOBLIB concatenering, i TSO skal du undersøge din ISPLLIB/STEPLIB concatenering og i CICS skal du undersøge DFHRPL concateneringen.
Hvis du fandt consistency-token i loadmodulet, så er fejlen sandsynligvis, at BIND'en af den til programmet hørende package fejlede. Mange installationer har en uvane med at LINK'e loadmodulet før de BIND'er packagen. Hvis package BIND'en fejler, ja så har man straks risiko for at få en SQLCODE -805. Jeg kan derfor kun opfordrede til at BIND'e først og LINK'e bagefter. Hvis package BIND'en ikke fejlede, så kan SQLCODE -805 kun skyldes, at pakke-listen til plan-name ikke indeholder den collection, som dbrm-name blev BIND'et ind i.
Fejlsøgning af SQLCODE -805 er en kompliceret sag. Der er mere hjælp at hente ved at klikke her. Du har på nuværende tidspunkt nok et brændende spørgsmål: hvorfor i al verden skal jeg også søge med et consistency-token, hvor de første 8 bytes er byttet med de sidste 8 bytes. Det skyldes, at de 8 bytes et consistency-token i virkeligheden fylder, gemmes som to 4 bytes felter og afhængig af programmeringssprog lagres de to felter i forskellig rækkefølge. I COBOL byttes der rundt på rækkefølgen, mens PL/1 beholder den korrekte rækkefølge. Hvis du ved, at dit dbrm-name er et COBOL-program, så kan du starte med at bytte de første 8 bytes med de sidste og kun søge een gang. Jeg kender ikke rækkefølgen for andre programmeringssprog, så her må du prøve dig frem.