On 06-Nov 07:05 -0800, Buck Calabro wrote:
On 10/31/2013 3:37 PM, CRPence wrote:
On 10/30/13 7:21 AM, Charles MARTIN wrote:
I wish i could do some reflection using RPGLe.
By reflection, I mean :
'The process or mechanism of determining the capabilities of an
object at run-time.'
-snip-
Have you looked at what of that the Dump Module Variables
(QteDumpModuleVariables) API could provide?
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/QTEDMPMV.htm
I just finished a proof of concept. I developed and tested it when
NOT in debug mode. That is, the sole debugger API I used was
QteDumpModuleVariables. Using that, I was able to get a list of the
variable names and types for both *PGM and *SRVPGM objects.
The variable definition is elusive. Some variables are reported
fine: Indicators, floats, integers and unsigned integers all
implicitly return their sizes. For example, there is a variable type
for 64 bit float. Alpha, zoned and packed only return their type, not
their size or precision. The API has space set aside to report
decimal positions, precision and scale, but they are always zero. So
I can infer the size of a 64 bit float or 128 bit pointer from the
variable type, but I can't do the same for alpha, etc.
For the purpose of the OP, although size information was alluded as
desirable, I am unsure if there would be an actual requirement for
anything but the formatted value.?
I have never used that API, merely knew such an API existed, so I can
not comment with actual experience. But the described effect would seem
to be a problem... No? Seems reasonable to report that as a defect.?
If invoking defect support is a concern for some reason, then using the
_send feedback_ link on the documentation, a message could be composed
implying the apparent defect, asking that the documentation should
clarify expectations; that feedback mechanism has a process that
mandates a reply to the originator [given the message is not apparent
spam, because there are no bot preventives implemented].
Even so... Some [approximate] size information should be able to be
inferred from the "Length of hexadecimal value" when that information is
requested, at least for the BCD numeric types.? The packed BCD size
would require a guess, given two precisions fit in the same storage.
I need to see if the situation changes if I combine this API with
other debugger APIs. Maybe if I get the program in active debug the
API will return more information about the variables.
I recall once, long ago, successfully getting the detailed variable
information with an OPM program debug API, the Retrieve Program Variable
(QTERTVPV) API. At first I was thinking of that API because I knew it
worked, but I recalled both that the API was OPM-only and that there was
something similar for non-debug. So after searching and finding that
API, I mentioned it only _assuming_ it would be sufficient. Having to
defer to the active-debug APIs is not as desirable an option... because
the ability to debug more generally is impacted; great care in how debug
is established [and re-established if necessary] within the program that
will get the information from the other program [e.g. the caller] can
ameliorate the obvious potential conflict *except* being serviced which
is likely to be a showstopper.
I have long and often used the debug commands in CLP and CLLE, mostly
to display specific variables within a program instead of using
DMPCLPGM; often simpler to recompile those programs than having a
breakpoint exit program do the work. Using the DSPPGMVAR has the same
requirements\restrictions of that Retrieve PgmVar API; i.e. STRDBG
within the job and that active program added under debug. I never took
the effort to deal with the issues like debug already active, the
program having been removed from debug, or restarting debug if it was
ended... which I allude might be desirable if a program were used to
debug itself or debug a caller to obtain its variables and values.... to
reduce potential interference with other debugging.
A very interesting suggestion Chuck. Thanks for posting. I was
always fixated on getting the entire symbol table, cross reference
included, and so totally disregarded the debugger APIs. Lesson
learnt!
Given compilers typically [can optionally] produce some predictable
output in that regard, parsing the output to achieve some tasks can
sometimes be worthwhile. Because a[n ancient monolithic coded] product
I worked on was coded with some effective global storage spanning many
programs, we generated a cumulative cross-reference across every program
in the product, from the information in each individual compiled
program's listing.
midrange.com
