Re: RPGle - i wish i could do some 'Reflection'

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.