RE: User space examples using List APIs

Colin & Scott,

>>The problem with this example is that it is a little bit confusing.
You need to look at the layout of the data returned in the user space.
Look at member QUSLMBR in QSYSINC/QRPGSRC  (Lib/File).
Look at the header(QUSBY) and the MBRL0100 format(QUSBZ), and then the
program should make more sense.
Have you looked at the documentation for this in the API manuals?<<

Yeah, IBM's example is confusing; it wouldn't even compile as shown in the
softcopy.  For the most part, I understand the API concept, and have used
several extensively that do not produce information in a user space.  It's the
user space and pointer concepts that I am unfamiliar with.

Scott, wow!!!  That was a beautiful piece of work you did in that last email, I
really appreciate the effort you made to explain everything.  I'm still trying
to get a handle on the pointer thingy, but that will take some practice, I'm
sure.

>>I'm not really sure ... why you've got the initial size of the user space set
so high!<<
You and me both; this was IBM's crude example code, and I modified it as little
as possible to get the thing running.  Once I did, I've been trying to clean it
up and make it more usable.  Actually, I need to use the MBRL0200 format, and so
I modified the code to handle that as well.  However, I'm stuck on how to define
the subfields for this format directly.  In IBM's example, format MBRL0100 was
used, which defines just the member name.  MbrARR, as defined below, is the
source for which the MBRL0x00 information is retrieved.  If I tried to change
this to a data structure, I got errors.  So I ended up using "Eval  MbrARRds =
MbrARR(index)" where MbrARRds is a data structure in which the MBRL0200
subfields are defined; not very elegant.  (I probably missed something really
simple here, so feel free to point it out.)

d MbrARR          s            100    Based(MbrPtr) Dim(32767)
d MbrARRds        ds           100
d  MBName                 1     10
d  MBSeu2                11     20
d  MBCreateDtTm          21     33
d  MBCCen                21     21s 0
d  MBCDat                22     27s 0
d  MBCTim                28     33s 0
d  MBChangeDtTm          34     46
d  MBUpdC                34     34s 0
d  MBUpdD                35     40s 0
d  MBUpdT                41     46s 0
d  MBMTxt                47     96

Also, I've never used your technique for the prototyped program calls.  The ILE
RPG reference says that these are dynamic calls.  Isn't there a performance hit
for that (vs. static calls, i.e. CALL 'QUSCRTUS'  ParmList)?  IBM doesn't let on
why, but the ILE RPG reference also states "The recommended way to call a
program or procedure (written in any language) is to code a prototyped call."
The ILE RPG Programmer's Guide states, "You can also write ILE applications that
can interrelate with faster static calls. Static calls involve calls between
procedures.  A procedure is a self-contained set of code that performs a task
and then returns to the caller.  An ILE RPG module consists of an optional main
procedure followed by zero or more subprocedures. Because the procedure names
are resolved at bind time (that is, when you create the program), static calls
are faster than dynamic calls."  Does this imply that called program objects
must always be dynamically called, no matter the method used to code the call?
This is not how I remember it from the RPG-III CALL op code.  I think I've got
some reading to do.

- Dan Bale





* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *