DB2 Z/OS - Problem of host variables

[troop]

In a context DB2 Z/OS V8, we must codify a clause with 300 posts in a COBOL program. Not too eager to codify

ZONE IN (:HV1, :HV2, ..., :HV300)

Or try a type definition:

01 TABLE
05 TAB PIC X(5) OCCURS 300.

We fill TAB zones with a small loop and then we write

ZONE IN (:TABLE)

It does not compile. Someone over there have an idea? Is there some problem with my host variables?

[Katty]

And what is the compile error that you have? I do not think it is possible to do this. But you could try using a sub-select.

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

[troop]

In fact at the pre-compiles I get an error:

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

The array variable is well defined, so it is UNUSABLE

[Katty]

Someone may disagree with me if I say something stupid but I think what you're trying to do is not possible. It is better to use sub-select as said in my first answer. But I am not an expert in development,

For this kind of thing, I advise to go through a Declared Temporary Table. We need the TEMP database to be created with suitable TS. But, COBOL, I do not encode the DGT.

[Praetor]

I do not know but under DB2 V8 but under DB2/400 which is very close to SQL, I populate the program cobol table containing only the values and then I compare my master table of this new table by a join on values of the table.

It joined the suggestion of the global temporary table.

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

You do not seem to be in one of these cases.

[troop]

Thank you all for your responses. This unfortunately confirms the impossibility of a host structure in a general clause.

When the table is completely in tune with you in a general case. The 300 positions in the clause are also supplied with a table setting that could well take join in the request. But given that entry, there is a table of 250 million lines, we just want to avoid having to make 250 million readings in a small table, where the IN clause is to be used instead of a joint.