× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.