On Sun, Sep 17, 2017 at 12:33 AM, D*B <dieter.bender@xxxxxxxxxxxx> wrote:
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.
Thanks for the feedback.
In the case of rlaColGet(), you WANT other programs to reference the same
open data path for improved performance. The only purpose of the function
is to return a data value. The file is opened for input only. Each
invocation of the function is stateless.
If another program in the call stack were to need to access the same file
in a stateful way (opened for update), that program can itself invoke the
rlaOpen() function, which returns a unique reference to another open data
path.
The service program that encapsulates the procedure names that begin with
"d1" is designed to interface with only one particular application that
exposes CRUD functionality. The interface that it exposes via data exports
is a custom implementation, specifically for one application.
The procedure that retrieves a record from the FRD001 file, is designed to
fetch and return other values from other files through foreign key
relationships, using the rlaColGet() function.
The reason for encapsulating the "d1" procedures in a separate service
program is for the purpose of readability, modularity, and scope isolation.
That makes the code more easily maintainable.
The service program that binds to these "d1" procedures, also binds to
procedures in a different service program that exposes an SQL CLI
interface, which is used for dynamically generating cursors. This is a nice
way of integrating SQL and RLA into an application.
midrange.com
