RE: Re[4]: LVLCHK *NO

I see a kind of confusion here:

     > Just about every other data base in the world does this but not the
AS/400.

AS/400 database is certainly doing this for you. Native I/O provides static
database independence - you only have to recompile the program if you change the
file. It also provides tools to improve this independence - logical files (more
about it later).
If you want dynamic database independence - AS/400 provides it via SQL
interface.
You should compare apples to apples - native Database Access should be compared
to native I/O for UNIX or NT - which is unformatted stream of bytes.
If you compare AS/400 to Oracle, for example, then to be fair you should use
AS/400 SQL for comparison.

     > The thing is we shouldn't have to do this. We should just be able to
select
     > the fields we need or the compiler does it for us, and it should be
handle
     > automatically. Then we wouldn't have to go through all this. The program
     > would just pass the format to use when the file is open and that format
is
     > how the program would see the data base.

This is exactly what you have with AS/400 native I/O model. You use logical
files (LF) to "select the fields we need"
and "the compiler does it for us" and it's all "handle automatically".

Other than that I agree with the rest of the note - using logical files to have
multiple views of the data. This is exactly what they are for. And of course,
always reading all of the fields in a file record is not the best idea, and not
only from performance point of view.

I would also like to note that creating logical files does not necessarily
require specifying key fields.
You may create logical file just to create new "format" - to subset fields from
a physical file.
Using such logical file incurs negligible overhead - both in time and space. In
fact, it can even somewhat improve performance, if you select small subset of
fields from a file with a very long record with hundreds of fields.

Best regards
    Alexei Pytel


Alan Campin <Alan.Campin@CaseLogic.com> on 10/01/99 03:40:50 PM

Please respond to RPG400-L@midrange.com

To:   "'RPG400-L@midrange.com'" <RPG400-L@midrange.com>
cc:
Subject:  RE: Re[4]: LVLCHK *NO




Some musing on LVLCHK.

What everyone is dealing with here is Data Base Independence. Data Base
Independence just means that you can change a table and as long as you don't
change the type or size of a field used in a program, the program is
unaffected. Just about every other data base in the world does this but not
the AS/400.

Another way to put this is that the physical view of a table does not have
to equal the logical. The whole purpose of a data base is the ability to do
just that. For example, if a table of customers has a hundred fields but
your program only needs the customer number (key) and the current balance,
Data Base Independence would allow you to simply specify the you want only
the customer number and the current balance. To the program, the data base
looks like the logical view, i.e. the table has nothing except the customer
number and current balance. So if you change the customer table and add a
new or change the type and size of some other field you are not using in the
logical view, the program is unaffected. The only time the program would
need to change if you changed a type or size of a field in the logical view.


Unless you use SQL on the AS/400 or one other technique I will describe
below, on the AS/400, you do not have Data Base Independence. If we were to
add up all the hours that programmers have spent dealing with this problem,
the time would be astronomical. The irritating thing is that it would be a
relatively simple thing for IBM to correct.

The other technique for Data Base Independence on the AS/400 consists of
creating a field select logical (another term I use is a application
logical) for each time you access a table. I know that can be a pain but the
payback can be tremendous. All our new development is now being done this
way. Using the example above of a customer table and needing only the
customer number (key) and the current balance, you would create the logical
as follows:

File name CM0001_L01. Program CM0001, logical view 01.

  A                                      UNIQUE
  A          R R0001_L01                 PFILE(CUSTOMER)
  A            CMNUMBER
  A            CMCUSBAL
  A          K CMNUMBER

This example assumes you have master key and the key is unique.

We, also use this technique a lot to create join logicals where possible to
avoid Logical I/O to improve performance.

Now, no matter how many times you change the customer table, as long as you
don't change the type or size of the customer number or customer balance,
the program would never have to be touched. No matter how many times you
recompile the logical view, the record format ID never changes so the
program has no idea that the underlying physical file has changed and the
data base manager handles the mapping automatically.

One of the first things I always hear when I discuss this method is that you
are creating a whole bunch of new indexes which is not correct. As long as
the AS/400 has an existing index, no matter how many times you create
another logical view of the data base, the AS/400 will maintain one index
only unless you specially override it and tell it to create a separate
index.

The reason this is true, is because at the machine level, there is no such a
thing as a logical file or a physical file either. If you dump a logical
file, all you will see is bunch of pointers. One to the physical data, one
to the index, one to a format object, etc and the AS/400 will always try to
reuse an existing index.

It creates additional work when you are creating an application but pays
back over and over again. Of course, what you are doing is creating a data
base access plan. If you do this, you now have data base independence and
are now free to maintain the table as you need.

There are, also, performance improvements and the program object size
decreases. Interestingly, I have seen recommendations from IBM Rochester
suggesting we use this technique to improve performance of ILE RPG programs.
Because RPG ILE is a "C" type language and files are always global, the
larger the record formats, the more static storage the RPG ILE has to try to
manage, thus the slower the program will run. It has been suggested that we
use these application logicals(my term) to reduce static storage and, also,
to use application join logicals wherever possible.

There is one other solution to this problem that would be better and could
only be done using ILE language. That would be to create a file I/O Service
Program. A technique for doing this using a data mediator appeared in
Midrange recently. It could, also, be written in "C" and you would be able
to have one program to do all the I/O. In either case, you should be able to
define logical view of the data and have the file I/O Service Program do the
mapping/

The service program would just have a set of functions like, OpenFile,
Position File, ReadRecord, ReadNextRecord, etc. I would love to write this
thing but haven't had the time. If anyone else has an interest in this,
please let me know.

The thing is we shouldn't have to do this. We should just be able to select
the fields we need or the compiler does it for us, and it should be handle
automatically. Then we wouldn't have to go through all this. The program
would just pass the format to use when the file is open and that format is
how the program would see the data base.

Sorry to be so windy. Look forward to your comments.

Alan Campin
Sr. Programmer Analyst
Case Logic, Inc.
alan.campin@caselogic.com

-----Original Message-----
From: pcunnane@learningco.com [mailto:pcunnane@learningco.com]
Sent: Friday, October 01, 1999 3:28 PM
To: 'RPG400-L@midrange.com'
Subject: Re[4]: LVLCHK *NO


     All the more reason to recompile all the programs.

     If a file is used by 200/300 programs, I think anybody should think
     twice about arbitrarily changing the layout.  And if, on mature
     reflection, the change is necessary, then by all means all the
     programs should be recompiled.

     ____________
     Paul Cunnane
     The Learning Company


______________________________ Reply Separator
_________________________________
Subject: RE: Re[2]: LVLCHK *NO
Author:  Colin Williams <Williamsc@technocrats.co.uk> at InterNet
Date:    01-10-99 4:06 pm


What if that change involves 200/300 programs or even more?

>-----Original Message-----
>From: pcunnane@learningco.com [mailto:pcunnane@learningco.com]
>Sent: Friday, October 01, 1999 7:17 PM
>To: 'RPG400-L@midrange.com'
>Subject: Re[2]: LVLCHK *NO
>
>
>     In my last job, which was in a software house, LVLCHK(*NO) was
>     strictly verboten.  If a file had to be changed - even to tack a
>     single field on the end - all relevant programs were
>tracked down and
>     recompiled.  All such programs then became part of the fix to be
>     delivered.
>
>     ____________
>     Paul Cunnane
>     The Learning Company
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---



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