Discussion :

[pdz74]

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.

[Lemmings1406]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
SELECT COLx, COLy FROM TABLE1 WHERE COLz IN (
SELECT :WH-VARx FROM SYSIBM.SYSDUMMY1
)

++

[pdz74]

C'est en fait au niveau de la pré-compile qu'il y a une erreur :

DSNH312I E DSNHSMUD LINE 137 COL 31 UNDEFINED OR UNUSABLE HOST VARIABLE "TABLEAU"

La variable tableau est bien définie, donc elle est UNUSABLE

[Lemmings1406]

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.

[bernard59139]

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

[Peut-êtreUneRéponse]

J'ai cru comprendre dans l' "Application programming & SQL guide" que les host-variables array n'étaient utilisables que dans les 3 conditions suivantes :

“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”

Source

Tu ne sembles pas être dans l'un de ces cas.

.

[pdz74]

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.

[Mercure]

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.