RE: LVLCHK *NO

I think it's an interesting question, regardless of your belief system.

Seems like RPG Classic programs got the file layout a compile time because
all fields had to be defined at compile time so they could get memory
locations.  Would it be a big deal, now that RPG has more flexible memory
management, to make it pick up the file layout dynamically?  I can see some
unpleasant ramifications for externally defined data structures with
overlays, but I remember fondly the ability to add fields to files in d-Base
and Clipper.    

> -----Original Message-----
> From: pytel@us.ibm.com [mailto:pytel@us.ibm.com]
> Sent: Monday, October 04, 1999 9:32 AM
> To: RPG400-L@midrange.com
> Subject: Re: LVLCHK *NO
> 
> 
> 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
+---