SQL code -805 sur un UNLOAD de table

Bonjour à tous,

J'ai un soucis sur un UNLOAD de table DB2 avec un SQL CODE -805, qui correspond à :

Code:

---

1 2	Tentative d'exécution du programme d'application 'nom-programme' avec un DBRM non "bindé" avec le plan 'nom-plan'.

---

Cependant, je ne vois pas ou et comment intégrer un bind avec le code JCL suivant :

Code:

---

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

//UNLOAD EXEC PGM=IKJEFT01,DYNAMNBR=20 //STEPLIB DD DSN=DSNA10.SDSNLOAD,DISP=SHR //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DBNA) RUN PROGRAM(DSNTIAUL) PLAN(MATERTD) - PARMS('SQL'),LIB('DSNA10.DBNA.RUNLIB.LOAD') //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //* //SYSREC00 DD DSN=MATERT.COB.UNLOAD,DISP=SHR //* //SYSPUNCH DD DSN=MATERT.SYSPUNCH,DISP=SHR //SYSIN DD *   SELECT * FROM MATERT.TABLE;

---

Auriez vous une réponse à me donner ?

Merci d'avance.

Bonsoir

Lors de la précompilation, les instructions SQL sont isolées dans le DBRM, le source programme (COBOL, RPG ou autre) est compilé séparément puis link-édité pour former l'exécutable le DBRM est tranformé en Package bindé dans le plan.
DBRM comme source programme se voient affecter d'un time stamp appelé "consistency token" ou "contoken" si ces deux time stamp sont différents, alors c'est là que ce produit le code SQL -805.

Ce faisant, si vous avez ce code, c'est que load module et le package ne portent pas le même "contoken" et donc n'ont pas été pré-compilés en même temps, en conséquence, ils sont incohérents.

La raison est que soit vous utilisez une mauvaise LOADLIB, soit vous n'utilisez pas le bon plan DB2, soit encore, vous n'avez pas bindé le package ou alors bindé le package d'une mauvaise DBRMLIB.

Comme la DBRMLIB et la LOADLIB sont dépendants du site sur lequel vous intervenez et du stage (test, recette, pré-prod, prod) il faut voir avec vos collègues quelles sont les librairies de LOAD et de DBRM à utiliser dans votre cas.

Merci escartefigue pour ces informations très précise, on voit que tu es un professionnel du domaine.
Quand à moi j'essaie d'analyser ta réponse.

Si j'arrive comprendre ce que tu me dit, je dois :

1 _ Précompiler
2 _ Binder
3 _ et ensuite faire mon UNLOAD

Je pensais, car je n'ai vu aucun code complet qui utilise ces trois étapes, qu'il ne suffisait que d'écrire l'étape avec le UNLOAD, donc d’après ce que tu m'écris ça ne risquait pas de fonctionner.

Je vais essayer de construire mon JCL avec ces trois étapes, mais peut tu me confirmer que je suis dans le vrai, juste que je ne parte pas sur une mauvais piste.

Pas moyen d'extraire mes données, j'ai toujours un SQL -805.

Avec la précompile et le BIND, j'ai bien mes fichiers compilé dans la LOADLIB et la DBRMLIB.
Mais toujours cet SQL CODE.

Dans mon UNLOAD, dois je rajouter dans la STEPLIB un accès à la LOADLIB et/ou DBRMLIB ?

voici la partie du JCL correspondant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

//DBPREC EXEC DB2COBCL, // COPYLIB=MATERT.SOURCE.COPY, <= COPYBOOK LIBRARY // DCLGLIB=MATERT.SOURCE.DCLGEN, <= DCLGEN LIBRARY // DBRMLIB=MATERT.SOURCE.DBRMLIB, <= DBRM LIBRARY // LOADLIB=MATERT.LOADLIB, <= LOAD LIBRARY // SRCLIB=MATERT.EXOCGI, <= SOURCE LIBRARY // MEMBER=EXOCOB <= SOURCE MEMBER //* //BIND EXEC PGM=IKJEFT01 //STEPLIB DD DISP=SHR,DSN=DSNA10.DBAG.SDSNEXIT // DD DISP=SHR,DSN=DSNA10.SDSNLOAD //DBRMLIB DD DSN=MATERT.SOURCE.DBRMLIB,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD *   DSN SYSTEM (DBAG )   BIND MEMBER (EXOCOB) -   PLAN (MATERTA ) -   ACTION (REP) -   ISOLATION (CS) -   VALIDATE (BIND) -   RELEASE (COMMIT) -   OWNER (MATERT ) -   QUALIFIER (MATERT ) -   ENCODING (1047)   END /* //UNLOAD EXEC PGM=IKJEFT01,DYNAMNBR=20 //STEPLIB DD DSN=DSNA10.DBAG.SDSNEXIT,DISP=SHR // DD DSN=DSNA10.SDSNLOAD,DISP=SHR //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DBAG) RUN PROGRAM(DSNTIAUL) PLAN(MATEATA) -   LIB('DSNA10.DBAG.RUNLIB.LOAD') //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //* //SYSREC00 DD DSN=MATEAT.COB.ULTABTIE,DISP=SHR //* //SYSPUNCH DD DSN=MATEAT.SYSPUNCH,DISP=SHR //SYSIN DD *   SELECT * FROM DBMATE1.TSMATEAT.TABTIE;

---

L'erreur dans SDSF est :

Code:

---

DSNT408I SQLCODE = -805, ERROR: DBRM OR PACKAGE NAME LOCRGNA..DSNTIAUL.18E154F9179F5506 NOT FOUND IN PLAN MATEATA.

---

Si personne n'a de solution avec DSNTIAUL, il y a t'il un autre moyen de faire un UNLOAD de table ?

Et si il y en a un, est ce possible d'avoir un exemple ?

V12 de DB2 :

il y a l'utilitaire UNLOAD.

DSNTIAUL ne fait plus partie des utilitaires, on le retrouve en tant que source compilable dans la doc "Application Programming and SQL Guide".

Merci fsmrel,

UNLOAD fonctionne sous DB2 10.1 ?

Si oui aurais tu un lien sur un exemple ?

UNLOAD est disponible avec la v10

https://www.ibm.com/docs/en/SSEPEK/p..._ugrefbook.pdf

Cela dit, je n'ai pas touché à DB2 depuis 25 ans !

Bonjour

ne pas confondre UNLOAD et DSNTIAUL

• UNLOAD est un utilitaire DB2, toujours fourni
• DSNTIAUL est un programme de service, très souvent (toujours?) fourni compilé.

pour utiliser DSNTIAUL, dans ton cas, il te faut demander à un administrateur. les parametres dépendent de la personnalisation de l'installation
en exemple, un exemple que j'ai utilisé pendant des années chez différents cllients

Code:

---

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

//jobname JOB .... //* //DSNTIAUL EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DB2) RUN PROGRAM(DSNTIAUL) PLAN(DSNTIAUL) PARMS('SQL') END /* //SYSPUNCH DD SYSOUT=* //SYSREC00 DD ..... //SYSIN DD *  SELECT ....... /*

---

pas de STEPLIB/JOBLIB, pas de LIB, mais tout dépend de l'environnement.

je ne fournirais pas d'enxemple d'UNLOAD, trop dangereux de lancer un utllitaire sans en apréhender les contraintes .

@Zoumzoum59 :
La syntaxe du bind communiqué me surprend, car le nom du package n'y est pas précisé, il me semble pourtant que ce paramètre est obligatoire.
Pour moi, la bonne syntaxe est plutôt BIND PACKAGE(mon_package) member(mon_membre_de_DBRM)...

Quoi qu'il en soit, ce n'est pas ça le problème, car là il s'agit visiblement de binder un package à partir d'un COBOL local sans rapport avec DSNTIAUL.

Votre job contient les instructions suivantes :

Code:

---

1 2 3 4

//SYSTSIN DD * DSN SYSTEM(DBAG) RUN PROGRAM(DSNTIAUL) PLAN(MATEATA) - LIB('DSNA10.DBAG.RUNLIB.LOAD')

---

Donc, le problème est que le package DSNTIAUL du plan MATEATA ne possède pas le même timestamp que le load module DSNTIAUL de la librairie 'DSNA10.DBAG.RUNLIB.LOAD'

Le plus souvent, DSNTIAUL est bindé dans un plan du même nom (DSNTIAUL donc) et les librairies sont automatiquement concaténées par défaut, sans qu'il y ait besoin de les préciser.

Du coup essayez en supprimant le paramètre LIB et avec le plan DSNTIAUL comme ceci :

Code:

---

1 2 3

//SYSTSIN DD * DSN SYSTEM(DBAG) RUN PROGRAM(DSNTIAUL) PLAN(DSNTIAUL)

---

Enfin, il n'y a aucun intérêt d'utiliser le paramètre PARM=SQL si c'est pour coder SELECT * from MA_TABLE...
PARM=SQL est intéressant si on veut appliquer des restrictions (WHERE) utiliser des fonctions, faire des jointures... là c'est à la fois inutile et dangereux : on ne répètera jamais assez que SELECT * est à proscrire !
Voyez ICI dans quels rares cas on peut utiliser select * et pourquoi il ne faut le plus souvent pas le faire.


EDIT

Concernant ceci :

Citation:

---

Envoyé par zoumzoum59

UNLOAD fonctionne sous DB2 10.1 ?

---

La version actuelle est la V13, je suis très surpris que votre site soit encore sur la V10 qui date de 2010 :weird:

Pour vous en assurer, vous pouvez exécuter cette requête :

Code:

---

1 2	select 'DB2 version : ' !! getvariable('SYSIBM.VERSION') from SYSIBM.SYSDUMMY1

---

je ne suis pas certain que getvariable fonctionne en v10.

pour connaitre la version de db2 en cours, j'ai toujours utiliseer la commande "-DIS GROUP"