Re: Database I/O Modernization

On 9/14/2017 4:44 PM, Nathan Andelin wrote:

On Thu, Sep 14, 2017 at 11:52 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

'Modern' for midrangers isn't about a particular I/O syntax. It's about
decoupling the logic from the database.

I agree that modernization isn't about I/O syntax. And that the I/O
interface in this particular case is regressive.

-thread drift begins here-

In regard to "decoupling the logic from the database", it's not clear what
type decoupling you may be referring to. Given the trend to deploy
applications one one server and databases on another, that could be viewed
as one form of decoupling - and often not an ideal type of decoupling.

Context might assist my attempt at clarifying. 'Non-standard
unit-record I/O with more compile-time overhead and more run-time
overhead is no way to modernise.' The coupling I'm referring to is the
incestuous binding of the F-specs, I-specs (external or not), C-specs,
and O-specs (external or not). All of those pieces need to be looked at
across many programs if we want to refactor the database - to modernise
it - simply because the file or one of its logicals appears on an
F-spec. That's a heavy workload, and is, in my opinion, the primary
reason so many of our systems are relegated to 'also-ran' status.

It's also not clear what type of logic you may be referring to. Shouldn't
data validation, referential integrity constraints, and other processing
(logic) that is incidental to I/O operations (read, write, update, delete)
remain tightly coupled with the database?

Program logic.

Of course, when applications reference logical views (whether logical files
or SQL views), that could be viewed as a form of decoupling.

It's been my experience that LFs are almost universally viewed (hee hee)
as a way to access/sequence via an alternate key. So CUSTMASTL1 might
be keyed by CUST, CUSTMASTL2 keyed by LASTNAME, CUSTMASTL3 keyed by
PHONE, etc. But each of those three LFs are the full set of columns.
This means that any RPG program with CUSTMASTL2 in an F-spec is going to
be coupled to the database layout just as if the underlying PF were on
the F-spec. So no decoupling at all in practise.

SQL is fundamentally different, not merely syntactically different.
With SQL, I /could/ do a SELECT * INTO an externally described DS, but I
think this is almost non-existent in the wild, and any time someone
suggests it, many voices pipe up to remind us that this sort of thing is
definitely Not Best Practise. Far more common in my experience is
SELECT NAME, AD1, AD2, CITY, STATE, ZIP FROM CUSTOMERS WHERE... This
way, if I need to refactor CUSTOMERS, I will only need to touch this
particular program if I change the referenced columns - this is the
decoupling of which I am speaking.