× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.