FWiW: To debug procedures like this, I often create a LOG_MSG
procedure that calls a CLLE that does a SNDPGMMSG of some text; sending
an impromptu message. Also add declarations of SQLCODE and SQLSTATE;
likely use the logging to record those in the joblog. I would generally
also put the result of any OUT parameter into a local variable [rather
than only\directly into that parameter], and then as the final statement
before the end of the compound statement, allowing me to be sure the
visibility should be available twice and in two-places:
SET DIV_LIB = LCL_DIV_LIB ;

I would remove the logging [probably by commenting-out the
statements] and possibly\optionally remove the local copy before
finalizing the code.

I have GETLIB in debug break on END P1
This works as I expect: EVAL *GETLIB.OUT_LOC:S
Returning: *GETLIB.OUT_LOC:S = "82 "

The last two should be revealing; i.e. mimicking the "works as I
expect" EVAL requests, in conjunction with knowing how to get the
dereferenced string:

EVAL GETLIB.DIV_LIB.LEN
EVAL *GETLIB.DIV_LIB.DAT:S

Of course, the first is already known from &localvars output.
However the .LEN value is possibly incorrect, being the maximum length
[so possibly not the expected trimmed\varying]; the query might want to
instead have selected the expression RTRIM(MAX(lclib)) to get a proper
varying length string from the LCLLIB which is quite probably CHAR(10).?

Thanks to Chuck for the hint about typing HELP on the debug cmd
line, but I did not see anything like VARCHAR - but apparently
DIV_LIB is NOT a 'string' type ? and GETLIB.DIV_LIB.DAT, using my
System/370 Reference Summary, does not decode into anything
meaningful to me.

The VARCHAR is split into a _structure_ [effectively an RPG DS] of
the string_LENgth and the string_DATa, and those individual components
are viewed separately. The C has [or at least had] no /varying/ data
type that matches both that RPG Alpha [varying] data type and the
VARCHAR SQL data type; thus the need to review the components
separately. However the GETLIB.DIV_LIB should exist, although not as a
C /string/ type, such that the following EVAL should be revealing:

EVAL GETLIB.DIV_LIB:X

After about 10 presses of F10 I return to my SQLRPGLE where,
surprisingly SQLCOD = 0, but, not surprisingly, the library name
returned is blank.

What was the value of the indicator variable specified for the second
argument of the SQL CALL requested from the SQLRPGLE?

The values of SQLCODE and SQLSTATE in the SQL routine [SQL PROCEDURE]
might be of interest; plus the value of the DIV_LIB at the break-point
for [the _final step_ of] the "END P1;"

This mailing list archive is Copyright 1997-2016 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 here. If you have questions about this, please contact