Re: LVLCHK *NO

[pytel@xxxxxxxxxx]

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