RE: Separate program for File retrieval

What Justin says is true. You can write the SQL to be immune to field
additions. If your team still wants the "externalized" trophy, embedded
SQL is actually a call to an external program.




From: Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
To: "RPG programming on the IBM i (AS/400 and iSeries)"
<rpg400-l@xxxxxxxxxxxx>
Date: 06/30/2017 11:14 AM
Subject: RE: Separate program for File retrieval
Sent by: "RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx>



"when a new field is added to the file, you shouldn't have to recompile
existing programs"

FWIW, SQL does that without externalizing your I/O.



-----Original Message-----
From: Vinay Gavankar [mailto:vinaygav@xxxxxxxxx]
Sent: Friday, June 30, 2017 8:33 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
<rpg400-l@xxxxxxxxxxxx>
Subject: Separate program for File retrieval

At my client, people are kicking around the idea of having a separate
program (module) that will do any required I/O. Existing files already
have tons of programs using them, so it would be done only for new files
that get created.

The idea is that by doing that, if and when a new field is added to the
file, you shouldn't have to recompile existing programs, unless they
require the new field.

Nobody of knows what would be the performance implications of doing it.

Client does not allow compiling files with *lvlchk(*no) and any new fields
are not necessarily added at the end of the file (they want keep the Audit
Stamp fields always at the end of file).

Questions I have is:
1. Is it feasible
2. Is it worth it from performance enhancement/degradation standpoint 3.
If yes, how would you actually code it (in RPGLE) so that all programs
need not be recompiled.

Thanks in advance for any advise.
Vinay