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

In a word, yes.  You would be better off having "Higher-Level" routines.
And I had done that too.  I seem to recall there were something like
4 levels of indirection between the program that made a call for the
record and the actual function that did the I/O.  A lot of it was for
networking (I had written my own record locking routines), checking array
values to see if the file was open or not, if it wasn't open, it would
open it, if it was open check for exclusive file locks, set the array 
as the file being open and so on.

It seems very complicated, but it came out of a natural progression,
and programs were bullet proof as far as file I/O was concerned.  I had
gotten tired of updating various screens for file add/change/delete etc..
and so my customer change program looked something like this:

#include 'PUBLIC.INC'
#include 'CONSTANTS.INC'

     CustNumber = GetCustomerNumber(0, TRUE, TRUE)
     if CustNumber <> NULL
         ChangeCustomerRecord(0, TRUE)
     End IF


The 0, TRUE, TRUE came from different versions of the GetCustomerNumber
function.  At one time I would have to pass it the file number of the
CUSTFILE file.  Then I moved that into the GetCustomerNumber function,
which kept track of all open files in a public array.  So if this file
number was 0, I would check the array, otherwise I would read the the
file number.

The first TRUE was whether or not to lock the record on the read.

The reason I had done most of this was because I got tired of going through
so many different programs every time I changed anything in a record
format.  In fact, I remember having to change from 5 digit numeric zip codes to
allow up to 10 digit alpha/numeric zip codes (We got canadian customers) and
it took me all of an hour complete testing.

Externalizing File I/O is the first step.  You remove the file I/O one step
away from the programs and the rest comes naturally as you realize how much
easier your life just became.

Regards,

Jim Langston

Date: Tue, 10 Apr 2001 14:09:05 -0500 (CDT)
From: Scott Klement <klemscot@klements.com>
Subject: Re: MIDRANGE-L Digest V4 #345

On Tue, 10 Apr 2001, Jim Langston wrote:

> 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.

[snipped lots of good stuff]

I both agree and disagree with you.   Your situation solves the problem of
a single file with the same fields being moved from one computer to
another, but doesn't solve much else.

Wouldn't you be better off having "higher-level" routines, (as I
previously suggested) instead of mimicking the RPG Chain op-code?

In other words, wouldn't you be better off having a "CreateOrder"
procedure rather than "ChainOrderRec, WriteOrderRec, UpdateOrderRec"??
So that the actual business logic is contained in the same place?

You'd still only have one place to change the file location, layout, etc,
but it'd be more abstract.  Rather than dealing with records, fields,
values, etc, you'd be dealing with Orders, customers, products and
services?
+---
| 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
+---