Que faire avec SQLCODE= -144

Bonjour,

En voulant passer la création de mes objets DB2 dans un batch, je suis confronté à l'erreur SQL -144 qui me laisse bien perplexe, malgré mes recherches sur Internet. J'ai en effet le message suivant :

Citation:

---

DSNTIAD - SAMPLE DYNAMIC SQL PROGRAM 2.0

CREATE STOGROUP PGSG001
VOLUMES (FAN003)
VCAT PG8997
SQL ERROR DURING EXECUTE IMMEDIATE
DSNT408I SQLCODE = -144, ERROR: INVALID SECTION NUMBER 1
DSNT418I SQLSTATE = 58003 SQLSTATE RETURN CODE
DSNT415I SQLERRP = DSNXERT SQL PROCEDURE DETECTING ERROR
DSNT416I SQLERRD = -215 0 0 -1 0 0 SQL DIAGNOSTIC INFORMATION
DSNT416I SQLERRD = X'FFFFFF29' X'00000000' X'00000000' X'FFFFFFFF' X'000 00000' SQL DIAGNOSTIC
INFORMATION

---

avec le JCL suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

006500 //PH01S01 EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(4,LT) 006600 //SYSTSPRT DD SYSOUT=* 006700 //SYSTSIN DD * 006800 DSN SYSTEM(XXXX) 006900 RUN PROGRAM(DSNTIAD) PLAN(DSNTIA81) - 007000 LIB('DSN810.RUNLIB.LOAD') 007100 //SYSPRINT DD SYSOUT=* 007200 //SYSUDUMP DD SYSOUT=* 007300 //SYSIN DD * 007400 007410 CREATE STOGROUP PGSG001 007420 VOLUMES (FAN003) 007430 VCAT PG8997;

---

Merci de votre aide.

J'ai déjà eu des -144, type de sqlcode incompréhensible. En général, c'est dû à une disphase entre le load et le package, si tu te sers des options de précompile qui empêche le -805. Il suffit alors de rebinder avec le bon dbrm et ça roule.

Dans ton cas, c'est sur un DSNTIAD, pas un programme applicatif. En conséquence, tu devrais vérifier que le plan DSNTIA81 est le bon et/ou que le bon LOAD de DSNTIAD est bien dans la DSN810.RUNLIB.LOAD.

Oui, mais comment savoir que le plan DSNTIA81 est le bon ?

J'ai çà sous DB2 Admin pour le plan DSNTIA81 :

Citation:

---

DB2 Admin --------- DB8G Interpretation of an Object in SYSPLAN --------- 05:5
Option ===>

---

Details for application plan : DSNTIA81
More: +

Citation:

---

Authorization ID of owner : XXXXX
Authorization ID of creator : XXXXX
Qualifier for unqualified SQL : XXXXX
Date of latest BIND of plan : 080511 (yymmdd)
Time of latest BIND of plan : 09364510 (hhmmssth)
Time when the plan was bound : 2008-05-11-09.36.45.105644
Version under which plan bound : V8
SQL rules specified at BIND : D - DB2
Cache size for auth IDs in bytes : 3072
Operative status of plan : Plan is valid and operative
Resource and authorization check : At plan allocation time
Plan base section size (bytes) : 2240 (in EDM pool during execution)
Average DML section size (bytes) : 0 (loaded when needed during exec)
Plan bound with EXPLAIN option : NO
Plan bound with DEFER(PREPARE) : No - DEFER(PREPARE) not specified
Number of PACKAGE list entries : 0
Number of enabled/disabled sys : 0
Current server :
Disconnect option used : E - explicit. Release locations at commit

---

En général, des programmes internes DB2, tel DSNTIAD, DSNTIAUL, DSNTEP2, c'est l'ingénieur système qui se charge de les binder, lors de toute nouvelle version de DB2. Plan DSNTIA81, cela signifierait que tu es en V8 de DB2. Est-ce la bonne version ? Gaffe, c'est toujours dangereux de mettre un nom de plan précisant la version de DB2, car lors d'une montée de version, il faut modifier tous les jcls concernés !

Bref, vois avec ton ingénieur système quelle est la version de DB2 et ce qu'il a fait pour les programmes ci-dessus, lors de sa dernière installation. Quel plan, quel bib de LOAD ?

Oui, je crois que tu as raison. Je vais demander à l'ingénieur système de me fournir les bons paramètres.

Tu peux vérifier ta version DB2 avec la commande DB2 suivante :

Code:

---

-DIS GROUP DETAIL

---

Résultat :

Code:

---

1 2	*** BEGIN DISPLAY OF GROUP(........) CATALOG LEVEL(810) MODE(N ) PROTOCOL LEVEL(2) GROUP ATTACH NAME(....)

---

Dans cet exemple : DB2 v8 NFM

Si tu as un FallBack en v8 ("retour arrière" de v9) cela peut en être la raison

.

Bonjour,

Apparemment je suis bien en version 810, votre commande me le confirme.