× 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.



You've obviously gone to the PTF lists, so now is the time to call IBM.

Good luck

At 06:41 PM 11/10/2005, you wrote:

Has anyone encountered this problem at V5R1?

When we try to run any 'SELECT * from FILE' over a remote non-iSeries
DB2 database using interactive SQL (STRSQL) we get the following error:

----------------------------------------------------------------------------
                         Additional Message Information



 Message ID . . . . . . :   SQL0804       Severity . . . . . . . :   30

 Message type . . . . . :   Information



 Message . . . . :   SQLDA not valid.

 Cause . . . . . :   If the error type is 2, 3 or 9, the entry in error
is 1,
   the value of SQLTYPE is 449, and the value of SQLLEN or SQLLONGLEN
is
   X'00000000'.  The specified SQLDA is not valid because of error type
3. A
   list of the error types follows:

     -- Error type 1 indicates that the value of SQLN is less than
zero, the
   value of SQLD is not between 0 and 8000, the value of SQLD is
greater than
   the value of SQLN, or that the value of SQLD has not been
initialized in
   REXX.

     -- Error type 2 indicates that the value of SQLTYPE is not valid
or that
   the value of SQLTYPE is not supported or has not been initialized in
REXX.
   The types that are not supported in REXX are NUL-terminated graphic
string,
   NUL-terminated character string, PASCAL L-string, sign leading
separate, and
   binary with precision and scale.

     -- Error type 3 indicates that the value of SQLLEN or SQLLONGLEN
is not
   valid or that the value of SQLLEN, SQLPRECISION, or SQLSCALE has not
been
   initialized in REXX. If REXX and SQLTYPE is decimal or numeric, then
either
   SQLPRECISION or SQLSCALE has not been initialized.  Otherwise,
SQLLEN has
   not been initialized.  If SQLTYPE is a LOB variable, then SQLLONGLEN
is not
   valid.

     -- Error type 4 indicates that size of the SQLDA area was not
large enough
   for the number of entries specified in SQLN statement.

     -- Error type 5 indicates that the SQLDA area was not on a 16-byte

   boundary.

     -- Error type 6 indicates that the value specified for SQLDABC is
not
   valid. The value is either not large enough for the number of
entries
   specified in SQLN or the value is greater than the maximum allowed.

     -- Error type 7 indicates that the value of SQLN was not at least
twice
   the size of SQLD and LOB host variables were found in the SQLDA.

     -- Error type 8 indicates that the seventh byte of SQLDAID was not
a '2',
   '3' or '4' and LOB host variables were found in the SQLDA.

     -- Error type 9 indicates that the SQLDATAL pointer was not null
for a
   DBCLOB host variable, but the length value referenced by the
SQLDATAL
   pointer had an odd value.

     -- Error type 10 indicates the SQLTYPE for a LOB locator did not
match the
   type associated with LOB locator.

 Recovery  . . . :   Correct the error in the SQLDA and try the request
again.
------------------------------------------------------------------------------

This only happens on our V5R1 machine, the same requests over the same
database from our V5R2 machine work correctly.  Also connecting to a
remote iSeries works correctly from both machines.

How does the SQLDA get initialized at V5R1?

We seem to have all the PTFs mentioned in the Knowledge Base for similar
errors.

--
Richard Rosenbluth
Rose Information Management Co
mailto:rose400@xxxxxxxxxxx



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.