RE: LVLCHK *NO -- RPG400-L

Jim, I don't think that having the ability to retrieve the file format at
run time would gain you much. You would have the same format as you did at
compile time. You would have the ability to resolve the current locations
but you would have no access to joins or any data transformation. You would
still have to create logicals if you where not just reading the file
straight. What I am suggesting is half way between Native I/O and SQL. 

At the time you are building the program, you would have the ability to
create a data access map, which files and which fields and maybe even data
transformation that you want to do on existing tables and indexes.
Essentially a logical file layout that you would have to specify an index or
just let the AS/400 find the best one.  

When you compiled the program, that data access map would be converted into
field mapping object(my term. If don't know what Rochester calls it) that is
stored in the program, essentially a logical file compile. You would, also,
store the record format id's for the tables.

At run time, the open would get one additional piece of information. A
pointer to the field mapping object in the program. Thus the AS/400 would
use the field mapping object in the program instead of the file which is
pretty close to what you suggesting. This is pretty close to what the AS/400
does for SQL. If it is dynamic, the AS/400 compiles the field mapping
object. If compiled, the object gets included in the program. 

Of course, that is kicker. The AS/400 has to receive its format from the
program instead of from the table. That would probably require data base
changes, although we might be surprised to find out that the capability
already exists. For example, how does the AS/400 do it for SQL in a compiled
program? Obviously the data access map exists somewhere because the AS/400
does not recompile the SQL at open if it static.

The AS/400 would then just need to check the record format id's. If they are
the same, the AS/400 would proceed as normal. If they were different, the
AS/400 would need to check the type, size and location of the fields in the
field mapping object i.e., a mini compile. At this point, it gets a little
murky. If everything checks, does the AS/400 update the program with the new
record format id and the locations of data in field mapping object or do you
have some kind of command to update all programs using a table or both? I
would think the latter but there might be issues with that. I can't imagine
this process taking more than a few seconds and only the first time the
program is opened and obviously if type, size and locations did not match,
the AS/400 would throw an error. 

Well, that is my thoughts. Have thought about this a lot and this seems the
only way you could do it and, of course, I am making this too simple. I am
sure there are other issues but the net result would be data base
independence. The tables could change but all the updates to the program
would be done in the I/O manager at run time. Of course, if we just got the
ability to look at the format at open time and do the mapping, that would
sure be a lot better than today but that begs the question of what it would
cost to do this with every open. I have talked to Rochester about that and
they indicated to me that they had looked at it but it decided it was too
costly at open.

With the method above, in probably 99.9% of the time, the opens would
proceed normally. Everything else would occur only if the under laying table
as changed. 

Thanks for your feedback.  

-----Original Message-----
From: Jim Langston [mailto:jlangston@conexfreight.com]
Sent: Monday, October 04, 1999 8:49 AM
To: RPG400-L@midrange.com
Subject: Re: LVLCHK *NO


Okay, lets look at dBase, Clipper, Foxpro, BTrieve, Access, am I leaving
any out?

I seem to recall that if I changed the layout of a database in any of those
languages I would not have to recompile unless I removed a field that was
being used in one of those programs.

The distinction is: those programming languages (and the underlying database
architecture) get the file layout from the file itself, not from an internal
declaration.
Which is how I was hoping RPG would do it.  RPG already has access to the
layout of the file at run time, does it not?  Yes, I understand it would
take longer

at program initialization for RPG to retrieve the layout from the data base
file.
And I understand that RPG is not doing that now, because it didn't in the
past.
But, what is stopping it now?

Regards,

Jim Langston


pytel@us.ibm.com wrote:

> 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
> OS/400 SQL for comparison.

<SNIP>

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