Re: MIDRANGE-L Digest V4 #345 -- MIDRANGE-L

True.

Now go 2 years down the line, when this file is no longer on your AS/400.
Now it's sitting on some other machine somewhere else.  You are going to
have to rewrite all your programs or modify each and every one of them.

But, if you were using the externalized I/O, you would change the library,
specifically the ChainProc procedure, recompile that, test, and off you
go.  Perhaps ChainProc will be grabbing the records using TCP/IP, or 
ODBC, or SQL or...  who cares?  Your program doesn't, it just knows that
the procedure returns your record.

This actually happened once, again on a different platform on a different
machine, all the files and indexes were home grown and worked.  Then TPTB
found a better way of doing things, that used a totally different method
of doing things, and came to me to convert all the files to this new method,
while keeping the current system running.

So, I spend a while going through every program and externalizing all the
I/O.  Every program was modified so it called library calls for all input,
output, opens, closes, etc...  Each program was tested as completed and
put back into production.

After every program was modified, I built additional calls in the library
to access the external databases (Novel BTrieve if anyone is curious) file
by file. Tested them, worked fine.  Wrote a little program to convert the 
old database to the new format.  Then went into the library and changed the
calls to point to the new procedures.  Recompiled.  Ran the conversion 
program.  Ran the programs and... they were now using the new file structure.

We create new distribution floppies (this was for a commercial software
product) and distribute it with maybe 1/10th of the files converted.  With
all the upgrade programs to convert the files.  As time goes by, we are 
converting files until all files are in the new format, while working on
other programs improvements and custom programming, etc...

That is what made me a believer in external file I/O by  having to do this,
since I had to come up with the idea on my own and it worked.  After that
file i/o modifications became so simple it was laughable.  If external
file I/O was done from the beginning (impossible in this particular case,
this was from a legacy system even back then) it would of been so much
simpler.

If you've never found a need for external file I/O you will not see the
benefit, until someone comes up to you and says, oh, we need to change
the way/the system we are storing the files on.  When can you have it done?
And we need to keep making modifications to the programs at the same time,
so you can't take a snapshot of the system and modify that.

Regards,

Jim Langston

Date: Tue, 10 Apr 2001 03:26:44 -0500 (CDT)
From: Scott Klement <klemscot@klements.com>
Subject: Re: Externalize DB/IO (was What Counts as Technically Slick?)

<SNIP>

What I'm arguing against is adding unnecessary layers of complexity to
programs that accomplish nothing.

Replacing code like this:

C     KeyList       Chain     MyFile
C                   if        not %found
C                   endif

With this:  (plus the appropriate prototypes, service programs, etc)

C                   if        Not ChainProc('MYFILE': KeyList: Record_ds)
C                   endif


Is what I'm saying is a bad idea.   The reason is because the added
complexity of having the extra service program, etc, is buying you nothing
if all the "ChainProc" does is CHAIN to the file, just like the RPG
op-code does.

<SNIP>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---