Re: RDS vs. I4GL (was: How to read Flat files from 4gl)

Joel Schumacher writes: -> ->Cathy Kipp (ckipp@vth1.vth.colostate.edu) wrote: ->: Charles Francis writes: ->: -> ->: ->Well Informix SQL may be called a variety of 4GL. But it is ->: ->really a different product as is RDS. The 4GL product compiles ->: ->using a C compiler to create object modules that are linked to ->: ->create executables. RDS like SQL is run by an interpreter. ->: ->RDS may be a "variety"; But; RDS is RDS not 4GL. The ->: ->question was "How to read Flat files from 4GL?" not ->: ->"How to read Flat files from RDS?." -> ->: Informix SQL is not 4gl. RDS (also r4gl) is a flavor of INFORMIX-4GL ->: as is compiled 4gl (or i4gl). RDS and compiled 4gl use the same 4gl code, ->: they are just compiled and interpreted differently. -> ^^^^^^^^^^ -> ->This is the one you have to watch out for though. It's been my ->experience, (although long ago), that RDS-4GL and i4gl don't always ->behave the same. Same code, maybe, but not always the same results. The same 4gl code should theoretically produce the same runtime behavior in either r4gl or i4gl. When we switched from r4gl to i4gl we did find that the versions we were working with were not bug for bug compatible. Ignoring bugs, r4gl initializes your variables for you and i4gl doesn't, so this is defintely something to look out for. ->This is something to watch out for if you're used to doing your ->development under RDS, then compiling using i4gl for release. You ->develop, test, develop, test, until it's right. Now you compile with ->i4gl and release and it doesn't work right. Now you look like you've ->got no quality control because of some r4gl/i4gl difference that you ->didn't notice because you were developing in RDS, not your target ->compiler. I agree. We currently do all of our development and production under i4gl. We switched from r4gl because for the number of users and the size of the programs we have, the startup (loading programs into memory took too long). Since our machines all are binary compatible, this works well for us. I could certainly see sticking with r4gl though if you had several platforms that could not run binary compatible code. Plus the compiling in r4gl is a lot faster. On the other hand, the r4gl runner is a pain to maintain if you link in C code. This is a lot easier in i4gl. Regards, - Cathy -------------------------------------------------------------------------------- Cathy Kipp e-mail: ckipp@vth1.vth.colostate.edu Phone: (970) 491-1294 Colorado State University Veterinary Teaching Hospital Fax: (970) 491-1205