Re: Generic RPG File Handler for File I/O using OA

 Thanks Nate

I did not mean to imply RPGers at any time need any "redoing and taking over all the work the compilers do for you" .
Externalisation of file definitions is one of the key points of why RPGILE is so easy to use.
I am saying that to have a Generic RPG File Handler one needs to code to retrieve the file layouts.
I believe C imports data structures into the program from the external file definitions, that need PRAGMA directives.
For RPGers it is so simple they hardly think of what the compilers did for them and they do not need to think of these things.

Compared to RPG RLA the very fact you wrote wrappers is an order of magnitude of complexity more than RLA.
I doubt what you did is within the perview of your average RPGer.
Using the _Rxxxxx functions from within RPG is IMO 2 orders of magnitude more complex then RLA.
And this is not even mentioning the complexities of NULL fields. Null fields broke me.
I am no longer working professionally , but to me sounds like OA I/O is something like SPECIAL file in RPG.
Never got into SPECIAL files.  Only time I used was on S/3 to print out OCL to a report.

There are many defininitions, of "lower lever", eg IRP, Intermediate Code generated by the compilers.  I dont mean that.
Regarding "lower level" I was mainly referring to Program Described file access and UDDS data streams.
In RPG one does not need to rely on external file descriptions. External descriptions brought in a standardisation of sorts for us S/3 coders.
On S/3 ,reading a program described db file meant you defined the file layout in the I specs, and it did not need to match the actual file layout. Many errors thus resulted.
So extending that to be able to read any file was not so difficult.
I doubt on Sys i ,anyone today uses Program Described db I/O, dont even know if this is possible in Free Form RPG.

fwiw on a S/3
    . almost every job needed a file sorted. ADDROUT sorts were like primitive LGL files.
    . a record lock caused an instant crash of the job. S/38 record lock waits were magic.


Regards
Frank

On 26/06/2022 2:06 pm, Nathan Andelin wrote:

Frank,

I appreciate your work and opinion. It seems that the participants in this
discussion may have different definitions for the meaning of "generic file
handlers". I'm not sure what they mean.

In regard to getting involved in "lower level" database access and "redoing
and taking over all the work the compilers do for you", you're only
referring to RPG. IBM i C programmers rely on the _Rxxxxx functions
exported from service program QC2IO in order to access IBM i database
files. At least, that's what IBM recommends. Of course, RPG has operation
codes. But the C routines are comparatively functional, and provide the
option of passing Library and File names as parameters, which are resolved
at runtime, which is more flexible than the traditional RPG interface. The
C functions pretty much mirror RPG operation codes. I wrote RPG wrappers
that streamline the API's to make it essentially equivalent to using RPG
operation codes.




On Sat, Jun 25, 2022 at 6:55 PM Frank Kolmann<Frank.Kolmann@xxxxxxxxx>
wrote:

Hi Nate

I dont know Mahammad goals.
My goal was to learn UDDS coding on S38. I did actually use UDDS once or
twice in production.
Plus I had a nice utility to view/update any file.

My later goals were to learn how to use IBM APIs, I did, but I never
used in production.
Later I wanted to learn C, which I did, after learning C what I really
gained was RPGILE was mostly a C based model.
After learning C many things became clearer, procedures , prototyping ,
pointers, modules and so on.

Lastly I wanted to transition my utility to the latest version of RPG.
SQL made the utility redundant, but it is a way to learn.
I failed because of the way NULL indicators are implemented, but learnt
more of Unix or is it C I/O functions to read SysI database.
Unix I/O is orders of magnitude more complex than RPG, not sure the
complexity is worth the results.

Here I must mention my mentor, Scott Klement, without whose work I would
never have progressed.
The S38 UDDS work was all mine own effort.

Finally my opinion on a Generic File Handler. Yes I believe it is
possible, but do you really want to get involved in the lower level
detail of database access?
You end up redoing and taking over all the work the compilers do for
you, and it is not really possible to do as well as the system
developers have already done.
fwiw

Cheers
Frank