Version imprimable
Bonjour,
Dans un contexte DB2 ZOS V8, nous devons codifier une clause IN avec 300 postes dans un programme COBOL. Pas trop envie de codifier
ZONE IN (:HV1, :HV2, ..., :HV300)
Or en essayant une définition du type :
01 TABLEAU
05 TAB PIC X(5) OCCURS 300.
On remplit les zones TAB avec une petite boucle et on écrit ensuite
ZONE IN (:TABLEAU)
Ca ne passe pas à la compile.
Quelqu'un a t'il une idée.
Merci davance et bonne journée.
Bonjour,
Et tu as quoi comme erreur à la compile? Je ne pense pas que ce soit possible de faire cela. Par contre tu pourrais essayer d'utiliser un sub-select.
++Code:
2
3
4
C'est en fait au niveau de la pré-compile qu'il y a une erreur :
La variable tableau est bien définie, donc elle est UNUSABLECitation:
DSNH312I E DSNHSMUD LINE 137 COL 31 UNDEFINED OR UNUSABLE HOST VARIABLE "TABLEAU"
Re,
Quelqu'un pourra me contredire si je dis une bêtise mais à mon avis, ce que tu essayes de faire n'est pas possible.
Il vaut mieux utiliser les sub-select comme dit dans ma première réponse.
Bonjour
Impossible, je pense. Mais je ne suis pas spécialiste devellopement,
Pour ce genre de truc, je conseillerai de passer par un Declared Temporary Table. Il faut que la database TEMP soit créée avec des TS adéquats.
Par contre, en cobol, je ne sais pas coder les DGT.
B59
J'ai cru comprendre dans l' "Application programming & SQL guide" que les host-variables array n'étaient utilisables que dans les 3 conditions suivantes :
SourceCitation:
“Retrieving multiple rows of data into host variable arrays”
“Inserting multiple rows of data from host variable arrays”
“Using indicator variable arrays with host variable arrays”
Tu ne sembles pas être dans l'un de ces cas.
.
Je ne sais pas sous DB2 V8 mais sous DB2/400 dont le SQL est très proche, j'alimenterais dans le programme cobol une table qui ne contiendrait que les valeurs et je rapprocherais ensuite ma table maître de cette nouvelle table par un JOIN sur les valeurs de la nouvelle table.
Cela rejoint la suggestion de la table globale temporaire (Global Temporary Table).
Merci à tous pour vos réponses. Cela confirme malheureusement l'impossibilité d'une host structure générale dans une clause IN.
Quand à la table, totalement en phase avec vous dans un cas général. Les 300 postes de la clause IN sont d'ailleurs alimentés avec une table paramètre qu'on pourrait tout à fait prendre en jointure dans la requête. Mais vu qu'en entrée, on a une table de 250 millions de lignes, on veut justement éviter de devoir faire 250 millions de lectures dans une petite table, d'où la clause IN plutôt qu'une jointure.
Encore merci à tous.
Bonne journée.
Mais sauf erreur, même avec la clause IN(), SQL va faire un Table Scan et passer les 250 millions de lignes en revue ?Citation:
Envoyé par pdz74
Je regarderais plutôt du côté des EVIs (Encoded Vector Index) car je pense qu'ils représentent une solution intéressante pour améliorer notablement les perf globales.
Si le prédicat de jointure est indexé, qui te dit que DB2 z/OS va pas faire l'inverse et lire la petite table en premier et accéder à la grosse table via l'index surtout si ce dernier est assez filtrant ?Citation:
Envoyé par pdz74
Sous DB2 z/OS, n'avez-vous pas un logiciel (je suis sûr que si) qui vous indique sous forme de graphique la façon et la méthode avec laquelle SQL va traiter les records d'une requête ? On a ce type d'aide sur IBM i (ex AS400) depuis longtemps déjà.
S'il n'y a pas déjà un index qui pointe sur la grosse table vers la zone de rapprochement en question, je créerais un index EVI, puis une requête "SELECT JOIN" et verrais ensuite ce que m'indique le logiciel. AMHA on doit éviter ainsi le table scan.
Il y plein d'outils qui font ça ... certains graphiques, comme Visual EXPLAIN d'IBM, d'autres "classiques" (i.e en 3270) comme Plan Analyser de CA ou Administration Tool d'IBM ... mais le DBA DB2 z/OS, qui est souvent un vieux de la vieille (expérimenté quoi) n'a que faire de ces "habillages" destinés aux petits jeunes ... il préfere souvent faire l'analyse directe de la requête via la fonction EXPLAIN sous SPUFI et lire brut de fonderie le résulat dans la PLAN TABLE ... en plus ça va souvent beaucoup plus vite pour une seule requête ...Citation:
Envoyé par Mercure
La notion d'index EVI n'existe pas en DB2 z/OS.Citation:
S'il n'y a pas déjà un index qui pointe sur la grosse table vers la zone de rapprochement en question, je créerais un index EVI, puis une requête "SELECT JOIN" et verrais ensuite ce que m'indique le logiciel. AMHA on doit éviter ainsi le table scan.
Ce n'est pas pertinent du tout de créer un index sur la colonne de jointure dans la table de 250 millions de lignes. Colonne peu discriminante (quelques centaines de valeurs différentes) et le besoin est unique.
Avec une jointure et en admettant que l'index existe, DB2 lirait en premier la table de codif puis la grosse table par l'index. Espérons que DB2 déciderait de faire du list prefetch car l'index ne serait pas du tout cluster (si pas de list prefetch, bonjour les I/O datas..). Quoi qu'il en soit, ce type d'accès finirait par nous renvoyer sur toutes les pages de la table. Donc autant la scanner une bonne fois pour toute avec du sequential prefetch, plutôt que d'y accéder par un index inutile.
De plus cet index, pour un besoin mensuel, nous couterait des I/O lors de toute insertion dans cette table (1 million par jour).
Bref, on en restera à un scan global, beaucoup plus performant qu'un accès index qui renvoie sur toutes les pages de la table.
Merci à tous.
Et c'est là que l'index EVI pourrait intervenir, d'autant plus que, tu le dis, il y a peu de valeurs discriminantes sur la colonne de jointure, mais bon, comme ce n'est pas supporté sur ce système, c'est juste de l'info.