|
On Jun 26, 2022, at 10:09 AM, Mohammad Tanveer <surgum@xxxxxxxxx> wrote:
There is nothing special about generic programs to do CRUD operations.
This concept was always there in some old RPG ERP softwares. We used to
call them IO programs. One program was created for each file based on the
key fields and an external file based DS.
It's more like a concept of repository in the OO world (java/.net). For
each table there is a repository. All updates to the table will be done
using this repository/service program. Program A, B ,C will call this
service program procedures to create/read/update/delete on a record using a
key field or different key fields.
I developed a program to do all this using JSON request/response avoiding
dependency on a file structure. This way If my RFID changes on a file my
RPG programs will not give level checks :)
I thought IBM file handlers can give me some better options, so that I can
pass control to my service program. So far I haven't found an
example where I can see how to use them for SQL CRUD operations. It looks
like it works great for RPG file operation codes.
Regards
On Sat, Jun 25, 2022 at 9:06 PM Nathan Andelin <nandelin@xxxxxxxxx> 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 Nateare
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
On 26/06/2022 9:31 am, Nathan Andelin wrote:
Mohammad,the
I don't really understand your goal, nor the problem you may have with
traditional RPG operation codes for DB I/O. But you could review the C
procedures, which are documented in the IBM i Knowledge Center, which
andexported from service program QC2IO. You could do a search on functionoperation
_Ropen, for example.
The C routines are functionally comparable to the traditional RPG
codes, except Library and File names are passed as parameters, so theycan
be resolved at runtime, as opposed to the RPG method, which requiresthat
Library and File names to be hard coded and resolved at compile time.
Given the C routines, you could write utility procedures that resolve
Library and File at runtime. For example, I wrote a generic procedure
checks for the existence of any record in any file, given a File name
--Key value.
The C routines perform a little faster than the RPG RLA alternatives.
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.