First I did not follow the thread completely ... but
Modernizing Db and modernizing data access is not the question of using
either native I/O or SQL, it is finding the best mix.
I totally agree having different procedures (one for each file/table), one
that handles the INSERT and another one that handles the UPDATE and a third
one that handles the DELETE.
Within these procedures for example you can include additional checks,
setting default values etc. If a change occurs you only have to do the
modification in a single place.
Not everybody is allowed to add constraints or triggers to tables or
physical files.
But including those functionality in a single insert/update/delete function
may help to keep the data consistent.
There should be additional functions for Chaining a row with the relative
record no and/or the unique key.
The more modular your (program) design gets, the more often you need to
chain a single row (the alternate would be to pass all information with the
parameters ... and normally exactly what we need is not passed).
Chaining the row in a service program has the advantage, that it can be
chained once (the next chain will only occur when the key changes or when a
new chain is requested).
The function can be called multiple times with the same key information, and
only the requested data is returned.
You may even include "getter" functions, so you are able to return a single
column value.
Everything else should be handled with SQL and preferably with views.
Externalizing data access may also mean, group all the functions where you
access a view into service programs, and the best into the service programs
for the specific file/table.
If an existing procedure can be used, great. If an additional function is
needed, just add it.
In this way there will be no data access in your programs, but in your
service program and instead of calling a subroutine, you just call an
(encapsulated) procedure which handles the rest.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Montag, 11. September 2017 03:56
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Database I/O Modernization
Some people think externalizing I/O like this is the best.
I've actually used software like this 30+ years ago on a Wang 2200 running
TOM (The Office Manager) software. It worked pretty good.
However I don't think this is the way to go with a database system like Db2.
This implies that all access is limited to only from these APIs. I feel that
people will eventually fight their way around this. For example I need a
report that joins this file to that file and so on. Do I talk to the Db2
administrator and have him write an externalizer or do I just do my own
joiner? Or do I limit my code to RPG mentality which limits me to read this
file (call it's externalizer) then read this other file (call it's
externalizer) and so on.
Also, the externalizer crowd frowns on things like putting things into the
database itself such as check constraints, RI constraints and so on. They
normally feel that all this should be in the externalizer. This, I have a
real issue with. Again, people will find that they always have this excuse
to bypass the externalizer, such a mass conversion, etc. Or this "one shot"
deal which they could simply do with an SQL statement but now they have to
call a plethora of stored procedures.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: Nathan Andelin <nandelin@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 09/08/2017 05:40 PM
Subject: Database I/O Modernization
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
The following link shows the RPG for a service program that encapsulates
database I/O.
It's essentially a template provided by Tembo Technologies as part of
their
road-map and approach to application modernization. Tembo has promised an
open-source license.
https://rd.radile.com/rdweb/temp/cusmstio.txt
The interface is a single procedure call wherein the following parameters
may be passed:
Action code (e.g. I=Insert, U=Update, D=Delete, R=Read, etc.).
Buffer pointer (a reference to an externally defined data structure
located
in the calling program).
Key Data Structure (contains the record key(s)).
Tembo's road-map calls for using this interface for RLA access for every
table and logical view in Db2 for i.
Questions:
Is this type of interface familiar to you?
What are the pros and cons of replacing existing I/O op codes with such
procedure calls?
Is this as an effective form of application modernization?
Would you recommend a different type of interface?
Thanks,
Nathan Andelin.
midrange.com
