RE: Populating fixed-length fields from IBM DB2 Services

[Michael Quigley <MichaelQuigley@xxxxxxxxxx>]

This sounds to me like an excellent case for an RFE.

Michael Quigley
Computer Services
The Way international
www.TheWay.org
> -----Original Message-----
> date: Mon, 8 Mar 2021 15:43:50 -0600
> from: Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
> subject: Populating fixed-length fields from IBM DB2 Services
> 	OBJECT_STATISTICS
>
> Hit my head against a wall for three hours today, so thought I'd bring it to
> the list to try to save someone else time.
>
> I have a physical file with (among others) fields OZLIB and OZOBJ.?
> These are the library name and object name, and both are defined as 10A.?
> Declaring a cursor like this: SELECT OBJLIB, OBJNAME from
> TABLE(OBJECT_STATISTICS('MYLIB', 'ALL')) works wonderfully as long as I do
> FETCH NEXT FROM C INTO :OZLIB, :OZOBJ.? But as soon as I stick those two
> fields (OZLIB amd OZOBJ) into a data structure, I get the dreaded
> "unusable" message telling me that a subfield doesn't match.
>
> Well, after a whole lot of hair-pulling, I figured it out.? The fields in
> OBJECT_STATISTICS are defined as VARCHAR, and while embedded SQL will
> convert VARCHAR to fixed-length if you specify individual fields (albeit with
> a warning at runtime about potentially poor performance), it won't do so on
> a data structure.? The matching rules are much stricter, probably because it
> assembles the data from SQL and then moves it as a single block of memory
> into the data structure (although I'm guessing there).
>
> Anyway, since I don't plan to standardize on VARCHAR fields in my databse,
> my workaround is to do all the fields individually.? When I have time I'll try
> defining the fields with the same name but with VARCHAR in a qualified DS
> and then try an EVAL-CORR.