Nathan,
it's not important to me, who's the Author of a programm, you've introduced
and asked for feedback.
From a technical perspective the Programm wrapper for a SRVPGM makes tight
coupling between the underlaying SRVPGM and application using this and you
will loose usability. Both effects are related to the fact, that the wrapper
uses an universal parameter interface, needing the summary of all
parameters, one of the exported procedure needs.
Further on: a SRVPGM as a replacement for RLA functions is useless, if it is
using RLA itself. This is related to the fact, that you can't win any
benefit, even making this a perfect one to one replacement. As the
introduced programm, we have been discussing about (I know, it's not your
programm, you just found it somewhere laying around) was not perfect, we
even lost performance, as you pointed out and Charles clearified how this
happened.
Third point is, that the interface itself is not correct, as it makes all
I/O sharing the open to the table the SRVPGM is responsable to. This is
related to the fact, that ILE doesn't give enough controll over programm
activation. The SRVPGM would have to use ACTGRP(*CALLER) resulting of commit
reasons and all programms in one transaction level (= ACTGRP) are sharing
the ODPs of all tables.
Now you are openeing a new discussion?
<Nathan>
I will however post a link to a DB I/O service program that does belong to
me.
Procedure names that begin with "rla" are exported from an RPG wrapper
around C APIs that are exported from IBM's QC2IO service program.
For example, rlaColGet("TABLE" : "COLUMN" : key) is a generic utility that
returns a value, given a table name, column name, and key. BTW, this
function is an implementation of Codd's Rule #2, quoted from Wikipedia as
follows:
"*Rule 2:* The *guaranteed access rule*: Each and every datum (atomic
value) in a relational data base is guaranteed to be logically accessible
by resorting to a combination of table name, primary key value and column
name."
Feel free to provide feedback.
</Nathan>
So I will try my very best:
The link is pointing to some rudiment of source of a SRVPGM. The copy Source
for the Prototypes is missing, but the Procedure intrefaces will show up the
same. Seems to be a autistic version: all Interfaces don't have any
parameter, giving back a Boolean or nothing.
The example of a procedure call "rlaColGet("TABLE" : "COLUMN" : key)" is
showing that this programms is sharing the last illness (see above) with the
programm, that's not yours: All programms in the call stack will share the
same open at ACTGRP level. This won't work as expected, as we've found out
before.
I didn't use QC2IO up to now, so I could not comment wether this could be
the right tool for the job, I'm only talking about topics I have some
knowledge.
It might be nice to have an implementation for codds second rule, but up to
now, I didn't need this in the pure form to get only a single column of a
table providing a primary key. Here I would prefer to get a little bit more
at one time, maybe a ResultSet providing an SQL statement, but this is
provided already.
Dieter
midrange.com
