RE: Externalizing I/O was RPG read loops

[Alan Campin <Alan.Campin@xxxxxxx>]

Simple, it is called database independence. Something we hardly ever think 
about on the AS/400. 

What we do on the AS/400 is bring the whole table into every program and the 
next thing we know we have five hundred programs referring that table and 
making the smallest change to the table becomes a nightmare so we create sub 
tables with a few more fields and then we get that table used in so many 
programs that we don't want to recompile everything so we create another sub 
table, so on and so forth. 

I have seen this scenario played out in so many systems, it is not funny. At my 
current company, they wanted to add one field to a table and we have Turnover 
but we had one programmer working for 3 weeks just making up compile lists to 
update one table and trying to get all the programs to recompile. What a mess! 

The whole concept of a database is that we can separate the physical and 
logical views of the database. Bringing the entire table defeats that. It, 
also, slows down I/O tremendously. 

Solutions:
1. Externalize the I/O. Put the I/O in one program.
        Advantages
                Only one place to recompile.
        Disadvantages
                Complex I/O programs and tons of them unless you write a 
general purpose program and that requires C.
                Cannot tell what files are being used in a program. 
2. Use field select logicals. 
        Advantages
                Brings in only what you need and allows complete data base 
independence.
                Big increases in I/O performance.
                Allows cross reference tools to see what files are being used.
        Disadvantages
                Tons of logicals. One per file per program. Pain to maintain 
and create. 
3. Use SQL
        Advantages
                Assuming you select your fields, brings in what you need.
                Allows easy joins. 
                Complete data base independence.
                See which files are used in a program. 
        Disadvantages
                Difficult to enter SQL into RPG programs. Hopefully this will 
vanish with free form SQL statements.
                Have to deal with precompiler which is a complete pain.
                Single table I/O is slower but only a fraction.

The solution, obviously at least to me, is for us to use SQL and that is the 
direction everything is going but most of the time, if we want to provide some 
kind of database independence, we externalize the I/O but that has it share of 
problems.

I keep waiting for free format SQL making it easy to enter SQL statements. Then 
maybe SQL will take off for I/O in RPG.

Anyway, my two cents, again. 
                
-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
Sent: Wednesday, February 02, 2005 9:11 AM
To: RPG programming on the AS400 / iSeries
Subject: Externalizing I/O was RPG read loops


Paul,

I think you're the first person that I heard of, that wasn't the person in 
charge of writing the access programs, that actually liked this scenario. 
Why an end developer would like to replace

chain(e) myfile;
// now actually do some real work with the fields

with
getFilename();
MyWorkField1=GetField(field1);
MyWorkField2=GetField(field2);
...
// now actually do some real work with the fields

rather escapes me.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Paul Morgan" <pmorgan@xxxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
02/02/2005 10:18 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
rpg400-l@xxxxxxxxxxxx
cc

Subject
Re: RPG read loops






Richard,

Great setup.  I once contracted at a shop that did this with OPM programs
even before ILE.  You never put a file into production without it's access
program.  Applications programs never referred to a file directly but did
all access through the IO program.  Even all the file logicals were in 
that
same program so you could select which logical to use with a parameter on
the call.

Paul

-- 
Paul Morgan
Senior Programmer Analyst - Retail
J. Jill Group
100 Birch Pond Drive, PO Box 2009
Tilton, NH 03276-2009
Phone: (603) 266-2117
Fax:   (603) 266-2333

"Richard ECUYER" wrote

> I did it.
>
> For each file (physical, logical, with ot without key), i build one 
source
> with some procedures :
>     Get_Filename          (CHAIN)
>     Set_filename            (SET, LL, GT)
>     Exists_filename        (SETLL without read)
>     Read_filename         (READ, readp, readE, READPE)
>     Insert_filename        (write)
>     Delete_filename       (delete)
>     Unlock_filename      (unlock)
>     Update_filename     (update)
>     dft_filename            (populate the exported datastructure with
defaul
> values)
> All "READ" procedures include a parm (*on/*off) to lock or not the 
record)
>
> Create a module and one service pgm by file
> a ds (io_filename) is exported.
>
> It is not done by hand, i create a little pgm that get file decription 
and
> create all sources needed (procedure interface, module...)
>
> When i use suche a procedure, i include 3 lines :
>
>     /copy of the bnddir (it is one with only IO service pgm)
>     /copy of procedure interface
>     an external DS (linked with the file) if i use data from the file.
>
> the only think (for me) to watch is in a loop that call a program that
read
> the same file i must make a setgt before the next read.
> all procedure return *off if request fald or *on if not.
>
> My loop are like this :
>
> Dow    Read_filename (*off : '*NEXT' : '*EQ' : Key1 : Key2 ...)
> do staff
> Enddo
>
> One cool thing is that i can change the file (add new fields at the end)
> without getting level error (new field will not be usable until i
recompile)
> I have a performance gain, and all IO for a file are in ONE source.
> It is new for us, but all find it easy and pretty to use.
>
> My little piece of 0,1 euro.



-- 
This is the RPG programming on the AS400 / 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.