I can't come up with a problem that their solution solves. Can you provide any examples?




-----Original Message-----
From: Nathan Andelin [mailto:nandelin@xxxxxxxxx]
Sent: Sunday, October 23, 2016 9:19 PM
To: RPG programming on the IBM i (AS/400 and iSeries) <rpg400-l@xxxxxxxxxxxx>
Subject: Re: RPG redbook

Justin,

Regarding externalizing I/O, it may not be a panacea but I think the premise is valid. If an f-spec is defined in only one service program (which exports a procedural interface), that will have advantages over defining the f-spec in 800-900 programs. It gives you options for solving or mitigating the effects of changes to record formats.

It may not solve certain issues, but others it will. Nothing will address all issues. For example, SQL I/O wouldn't solve numeric overflows in program host variables after increasing numeric field lengths in DB tables.
It wouldn't solve orphaned fields, if I understand what you mean by that.

Externalizing I/O is congruent with the principle of creating software components which have high cohesion in and of themselves, and loose coupling with the DBMS. That's a valid architectural premise.













On Sat, Oct 22, 2016 at 12:03 PM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
wrote:

I just finished the Externalizing I/O section, and I'm not really sure
it helps with the "hack the DB one more time" mentioned at the start.

We're just finishing up what I imagine is a typical DB change issue.
We have a table with several columns that need to be lengthened. The
table is used in 800-900 programs, some still using I-specs. We of
course had no practical choice but to add new columns at the end and orphan the old ones.

The sample app exposes (via EXPORT/IMPORT) data structures defined off
PF record formats. How does that help with DB changes? If you change
the table and service program, the service program will be exposing a
different layout of the DS than calling programs expect which will cause errors.
--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.