RE: Externalizing I/O was RPG read loops -- RPG400-L

-1)Speeding up I/O does not apply to updates. The database does a single 
records read and places a lock on the record and so forth. Speed up comes in 
input files. There are several levels of buffers on the AS/400 I/O. Each buffer 
only has a certain amount of space. If you bring in all the fields from a file 
and that is, say 1000 bytes vs. bringing, say two field, the item number for 15 
bytes and the description for 30 bytes for 45 bytes. If you have a X sized 
buffer, divide by 1000 then try dividing by 45. How many records are in the 
buffer? I have seen huge increases in speed in programs because the next record 
is more likely to be in the buffer. 

1) True if you change an field like an item number or something but my 
experience is that is rare. If another field is changed, what is the chance 
that field is going to be brought into every program? Again, if only the fields 
you need are brought in, the lower the chances this is true. 

2) Program logicals. Don't know any other way to do it given each program has 
different requirements but it is difficult. 

My two cents, only. 

-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
Sent: Wednesday, February 02, 2005 12:29 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Externalizing I/O was RPG read loops


-1) I don't see how it would speed I/O.  Does your I/O routine do a some
sort of update... %fields(...)?  Or what?

1)  Only one place to recompile.  When changing existing field sizes and
data types this quickly becomes a myth.

2)  Logicals.  Bear some strong merit.  In fact, I've see a vendor package
do this.  They changed all the physicals to a new name.  A logical doing
some mapping, etc to have the same record level format was created.  And
this had the old file name.  Your existing programs worked without change.
Deciding on a separate logical for each program is a bit extreme.

3)  SQL.  Mostly what I disagree is a matter of opinion so I'll let that
drop.  The precompiler, while it still has room for improvement, saw vast
improvements in V5R3.

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





Alan Campin <Alan.Campin@xxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
02/02/2005 01:05 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: Externalizing I/O was RPG read loops






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.






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