RE: LVLCHK *NO

Alexei wrote:
>> Record format is independent object. Database file uses it, HLL program
uses it
>> (not only RPG - any other language).

My point actually. If the Record Format is an independent object, why can't
we create one and store in the program, then use that format to open the
file instead of the one stored in actual file? (See my previous post on how
data base independence could be implemented)

Alexei wrote:

>> If one wants to change physical file layout without recompiling programs,
you
>> have already answered your question - use logical files.

The problem here is obvious. Time to create logical files and the management
of them. For each table in a program, you are going to have to create a
logical file and get it into production. 
It gives me data base independence but is a very time consuming process. In
a large system, you could end up with thousands of logicals. It can be done
but it takes a lot of time. I have needed to write a tool to build the
logicals for me for some time but haven't had the time. I am leaning more
and more toward using the data mediator concept and externalizing the I/O.
Of course, this will only work with ILE programs but most of the old stuff
isn't going to changing anyway. 
 
-----Original Message-----
From: pytel@us.ibm.com [mailto:pytel@us.ibm.com]
Sent: Monday, October 04, 1999 5:29 PM
To: RPG400-L@midrange.com
Subject: Re: LVLCHK *NO


It's not a fault, it's different paradigm.
Record format is independent object. Database file uses it, HLL program uses
it
(not only RPG - any other language).
Level check is needed so that program could verify that it is using record
format it thinks is using.
If one wants to change physical file layout without recompiling programs,
you
have already answered your question - use logical files.
If one wants to be able to use the very same program to process any file if
only
it has fields NAME and SALARY - well, it maybe convenient, but I would
question
usefullness of such approach.

Advantages of "static linking" ?
1) consistency - the more checks are done at compile time, the less room for
unpleasant surprise at runtime
2) efficiency - nobody cares about runtime efficiency on single-user PC, but
this is still an issue on multi-user (multi-thousand user) systems

Look at it from another point of view - the buzzword of today is OO. Record
format is object class. C++ and Java do not allow to change class layout on
the
fly. Nobody complains ... Moreover, ability to make as much static checks as
possible at compile time are considered strong points (see p.1 above).

Best regards
    Alexei Pytel


Jim Langston <jlangston@conexfreight.com> on 10/04/99 01:36:16 PM

Please respond to RPG400-L@midrange.com

To:   RPG400-L@midrange.com
cc:
Subject:  Re: LVLCHK *NO




Well, all I'm saying is, the only reason we have to re-compile our RPG
programs
when we change the layout on a file is because RPG does not get it's
database
information from the file or OS itself, but instead from internal
declarations
which
are defined at compile time instead of run time.

And, OS/400  and RPG are the only database servers and languages that do
this,
although I am pretty sure it's also for any language written on the AS/400,
but
I
don't think it's the OS's fault but the compilers fault.

What advantage is there to static linking?

Regards,

Jim Langston

pytel@us.ibm.com wrote:

> Well, I think it's just another religious war - what is better - static or
> dynamic.
> Both have their advantages and disadvantages.
>
> Best regards
>     Alexei Pytel
>
> Jim Langston <jlangston@conexfreight.com> on 10/04/99 09:48:55 AM
>
> Please respond to RPG400-L@midrange.com
>
> To:   RPG400-L@midrange.com
> cc:
> 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
> +---
+---
| 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
+---