4GL on Linux ~ Answered: amber (solid confidence) — Jonathan Leffler (an Informix engineer) and Mike Jagdis give an authoritative, detailed answer: mixing an old SCO 4GL port's objects with the new Linux ESQL/C is technically possible for I4GL 4.12+ but risks memory corruption from mismatched libc internals, and a native Linux 4GL (I4GL, QueriX, aubit) is recommended instead; the thread then drifts into a 4GL-tools pricing/marketing debate and the original asker never confirms which path he took.

Advisory only.

You can now download for free Informix SE developer bundle from Informix web site. Then you get SE v7 + ESQL/C. One question remains. Can you use an old SCO Informix 4GL port on the Linux box to develop 4GL applications compiling and working with this new Informix for Linux stuff. Did anybody tried that? I remember that the compiling sequence for 4GL modules is : xxx.4gl (4GL source) | |------> xxx.ec (embedded SQL C source) | |-----> xxx.c (C source (SQL statements translated in C)) | |------> xxx.o (object file) So, in my mind, I wonder if the only thing to do is to stop the compiling sequence after having generated the .ec modules, and then give the hand to the Linux ESQL/C tools for the following steps. Thank you for answer. Pascal Ferrari

In article <01be409e$e3cc9ac0$28888aa4@none.wanadoo.fr>, Pascal Ferrari <pascal.ferrari@wanadoo.fr> writes >You can now download for free Informix SE developer bundle from Informix >web site. Then you get SE v7 + ESQL/C. > >One question remains. Can you use an old SCO Informix 4GL port on the Linux >box to develop 4GL applications compiling and working with this new >Informix for Linux stuff. > >Did anybody tried that? I remember that the compiling sequence for 4GL >modules is : > >xxx.4gl (4GL source) >| >|------> xxx.ec (embedded SQL C source) > | > |-----> xxx.c (C source (SQL statements translated in C)) > | > |------> xxx.o (object file) > >So, in my mind, I wonder if the only thing to do is to stop the compiling >sequence after having generated the .ec modules, and then give the hand to >the Linux ESQL/C tools for the following steps. > >Thank you for answer. > >Pascal Ferrari Yes, I had it working , check the FAQ at www.smooth1.demon.co.uk -- David Williams

Pascal Ferrari wrote: > You can now download for free Informix SE developer bundle from > Informix web site. Then you get SE v7 + ESQL/C. > > One question remains. Can you use an old SCO Informix 4GL port on > the Linux box to develop 4GL applications compiling and working > with this new Informix for Linux stuff. I suppose you could do that, but wouldn't it be better to get the Linux version of I4GL? > Did anybody tried that? I remember that the compiling sequence > for 4GL modules is : > > xxx.4gl (4GL source) > | > |------> xxx.ec (embedded SQL C source) > | > |-----> xxx.c (C source (SQL statements translated in C)) > | > |------> xxx.o (object file) That's the pre-4.12/6.00 sequence; from then on, there was an extra step, .4gl -> .4ec -> .ec -> ... The .4ec file contains I4GL-related extensions to ESQL/C; the .ec file contains pure ESQL/C. In the previous versions, the .ec file was only acceptable to the I4GL phase 2 compiler and not (in general) to the pure ESQL/C compiler. > So, in my mind, I wonder if the only thing to do is to stop the > compiling sequence after having generated the .ec modules, and > then give the hand to the Linux ESQL/C tools for the following steps. It depends on whether you are using a 4.12 or later version of I4GL. If yes, then you probably could rig the system to work. But I'd still prefer to use the Linux version of I4GL. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>

In article <36A11155.1007@earthlink.net>, Jonathan Leffler <jleffler@earthlink.net> writes >It depends on whether you are using a 4.12 or later version of I4GL. >If yes, then you probably could rig the system to work. > As I did in the FAQ at www.smooth.demon.co.uk! >But I'd still prefer to use the Linux version of I4GL. > Agreed, but I find I actually prefer D-4GL! we use 4js and it a) compiles much faster b) produces very small p-code files c) Does better syntax checking than c4gl e.g. {###}^L MAIN DISPLAY "x" END MAIN yes that is a control-L outside the comment!! ^^^^^^^ Compiles under I4GL but not 4js' Also 4js' checks the number of parameters passed at compile time rather than runtime!! I'd rather develop under 4js since the compile times are much less and it is stricter! -- David Williams

Pascal Ferrari said >You can now download for free Informix SE developer bundle from Informix >web site. Then you get SE v7 + ESQL/C. > >One question remains. Can you use an old SCO Informix 4GL port on the Linux >box to develop 4GL applications compiling and working with this new >Informix for Linux stuff. > > [...] > >So, in my mind, I wonder if the only thing to do is to stop the compiling >sequence after having generated the .ec modules, and then give the hand to >the Linux ESQL/C tools for the following steps. But then you end up with .o files compiled for Linux libc internals, 4GL libraries compiled for SCO libc internals and ESQL/C libraries that could come from either your SCO 4GL or your Linux ESQL/C depending how you installed things. The GNU linker used under Linux can link the different object formats but libc internals are system dependent so even if it links you may get random memory corruption because of, say, differing structure sizes... In short, if your goal is to combine SCO 4GL and Linux ESQL/C you can try it. But if your goal is to develop 4GL code under Linux don't waste your time. If you *do* want to develop 4GL under Linux you can get a Linux native 4GL compiler from QueriX (http://www.querix.co.uk) which does not require Informix libraries or tools and does run fine against the Linux releases of the SE and IDS engines. Mike -- A train stops at a train station, a bus stops at a bus station. On my desk I have a work station... .----------------------------------------------------------------------. | Mike Jagdis | Internet: mailto:mike@roan.co.uk |

David Williams said >In article <36A11155.1007@earthlink.net>, Jonathan Leffler ><jleffler@earthlink.net> writes > >>But I'd still prefer to use the Linux version of I4GL. Which hasn't yet been released as far as I am aware :-(. > Agreed, but I find I actually prefer D-4GL! Not everyone does... > we use 4js and it > > a) compiles much faster > b) produces very small p-code files > c) Does better syntax checking than c4gl > > e.g. > > {###}^L > MAIN > DISPLAY "x" > END MAIN > > yes that is a control-L outside the comment!! > ^^^^^^^ > Compiles under I4GL but not 4js' I'm not sure I care in this case. Pedantically it's an error but if it compiles, that's fine by me. If it *stops* compiling when I upgrade it just increases porting overheads. Bad example maybe :-). > Also 4js' checks the number of parameters passed at compile time > rather than runtime!! Yeah, but we sometimes do things in C that we *want* to take variable numbers of arguments :-). It breaks backwards compatibility without giving you a sane out. And why doesn't it use the same trick to enforce the number of return values? > I'd rather develop under 4js since the compile times are much less and > it is stricter! Compile times are not a major issue for us (make, libraries etc.). The stricter compiler breaks on code that, admittedly, was broken before - but _worked_. Unless you are writing completely new 4GL code (and how many shops choose 4GL if they aren't reusing a whole load of existing stuff?) this is annoying. More importantly for us, 4JS just looks _ugly_. Largely because it seems reliant on old versions of Tcl/Tk - because it uses an old object extension to Tcl/Tk which does not appear to have been maintained for quite a while. The first impression is that it was a techie's neat idea which has suffered from non-technical management pushing to sucker money out of Informix for it. Horses for courses I guess... (For the non-English that means swings and roundabouts :-) ) Mike -- A train stops at a train station, a bus stops at a bus station. On my desk I have a work station... .----------------------------------------------------------------------. | Mike Jagdis | Internet: mailto:mike@roan.co.uk |

Yeah but Mike, The pricing on QuerieX is way over the top for small developers and people using Linux machines, and very hard to sell to new-to-informix shops, especially the one I work in--even with deep pockets. What I'm seeing so far with the latest 4GL is a real mess of a marketing campaign. Wait a minute, there isn't a marketing campaign for 4GL. Informix - has "classic" 4GL but hasn't released it for Linux, the newest fastest growing segment of the software industry. - has D4GL which is messy to use and difficult to impossible to install. - no download for classic 4GL or D4GL, must be ordered from a sales office QuerieX - Sounds good, but way overpriced even for a big-money shop I work in. 4Js - Impossible to install on Linux. You'd think that there would be a race for market-share, but it ain't gonna happen with 4GL. I can't even demo it, much less convince anyone new to Informix that it's worth what I think it is. Classic 4GL should be bundled with EVERY engine as part of an engine sale. If folks want to try the fancy stuff like D4GL then it should be available via a download. D4GL should be the option, not standard/classic 4GL. Thanks, Tim Mike Jagdis wrote: > > Pascal Ferrari said > > >You can now download for free Informix SE developer bundle from Informix > >web site. Then you get SE v7 + ESQL/C. > > > >One question remains. Can you use an old SCO Informix 4GL port on the Linux > >box to develop 4GL applications compiling and working with this new > >Informix for Linux stuff. > > > > [...] > > > >So, in my mind, I wonder if the only thing to do is to stop the compiling > >sequence after having generated the .ec modules, and then give the hand to > >the Linux ESQL/C tools for the following steps. > > But then you end up with .o files compiled for Linux libc internals, > 4GL libraries compiled for SCO libc internals and ESQL/C libraries > that could come from either your SCO 4GL or your Linux ESQL/C > depending how you installed things. The GNU linker used under > Linux can link the different object formats but libc internals > are system dependent so even if it links you may get random memory > corruption because of, say, differing structure sizes... > > In short, if your goal is to combine SCO 4GL and Linux ESQL/C you > can try it. But if your goal is to develop 4GL code under Linux > don't waste your time. If you *do* want to develop 4GL under Linux > you can get a Linux native 4GL compiler from QueriX > (http://www.querix.co.uk) which does not require Informix libraries > or tools and does run fine against the Linux releases of the > SE and IDS engines. > > Mike > > -- > A train stops at a train station, a bus stops at a bus station. > On my desk I have a work station... > .----------------------------------------------------------------------. > | Mike Jagdis | Internet: mailto:mike@roan.co.uk | -- - -- --- Tim Schaefer ---- tschaefe@mindspring.com --- http://www.inxutil.com -- -

You could try aubit 4gl - its still very beta http://www.aubit.com Pascal Ferrari wrote in message <01be409e$e3cc9ac0$28888aa4@none.wanadoo.fr>... >You can now download for free Informix SE developer bundle from Informix >web site. Then you get SE v7 + ESQL/C. > >One question remains. Can you use an old SCO Informix 4GL port on the Linux >box to develop 4GL applications compiling and working with this new >Informix for Linux stuff. > >Did anybody tried that? I remember that the compiling sequence for 4GL >modules is : > >xxx.4gl (4GL source) >| >|------> xxx.ec (embedded SQL C source) > | > |-----> xxx.c (C source (SQL statements translated in C)) > | > |------> xxx.o (object file) > >So, in my mind, I wonder if the only thing to do is to stop the compiling >sequence after having generated the .ec modules, and then give the hand to >the Linux ESQL/C tools for the following steps. > >Thank you for answer. > >Pascal Ferrari

> > In short, if your goal is to combine SCO 4GL and Linux ESQL/C you > can try it. But if your goal is to develop 4GL code under Linux > don't waste your time. If you *do* want to develop 4GL under Linux > you can get a Linux native 4GL compiler from QueriX > (http://www.querix.co.uk) which does not require Informix libraries > or tools and does run fine against the Linux releases of the > SE and IDS engines. > Querix looks very smart. It is even more then a 4GL clone. It is a superset of 4GL, including additional data types and a better event oriented syntax. It also allows you to connect to other databases (Oracle for instance). However, the information I have about it is it costs almost $8.000 ! Can anybody confirm that? One thing more : it is run-time free. Pascal Ferrari

Hello Tim, Tim Schaefer wrote: > [...] > > 4Js - Impossible to install on Linux. > > [...] I would like comment a bit your quick statement... First of all, I find quite unfair your comment as you know that Linux is our primary in-house development platform. This is true since more than two years and we have always been very strong supporters of the free software community. Just look at our windows client being an evolution of TCL/Tk. Don't forget that the GPL licensed type of software is so successful today not only because of its quality but also because of commercial companies supporting it (IBM, Sun Microsystems, Informix, Cygnus, ...). Because of Informix legal issues, we could not release the native port of Four J's Universal Compiler on Linux earlier than July 1998. However, we provided to many customers the the tip of using Four J's Universal Compiler with the iBCS compatibility module. Now, Linux have the same priority as all other major OS vendors we support (Sun, HP, IBM, SGI, SCO, ...). Four J's Universal Compiler works extremely well on Linux ! I am curious to know what make you stating that it is impossible to install on Linux ! Note that if you downloaded the evaluation version from our web site, or if you used an old Four J's software this is the old iBCS version and this is clearly mentionned in our download page or release notes. We should have the native Linux demo version online shortly, but we primarly focus in supporting our customers rather than updating our demo version with our very latest software. Note that INFORMIX Dynamic 4GL is exactly the same software than Four J's Universal Compiler (at equivalent release level), thus both will support Linux the same way. So I also disagree with your statement "D4GL which is messy to use and difficult to impossible to install." ! Regarding the "Classic 4GL" issue, I don't see the point of using it anymore as D4GL is nearly 100% compatible, while bringing a lot of new business opportunities if you wish to use the existing or upcoming extended capabilities (graphics, light C/S, OO-like extensions, Java client, NT support, multimedia, etc...). Four J's Development Tools target is to bring enough resources to the 4GL language to provide a true and modern development environment as VB, Delphi and others did with more or less success. But this is another debate... Georges -- Georges A. Tomazi [gt@4js.com] Vice President - Operations Four J's Development Tools

> Regarding the "Classic 4GL" issue, I don't see the point of using > it anymore as D4GL is nearly 100% compatible, while bringing > a lot of new business opportunities if you wish to use the > existing or upcoming extended capabilities (graphics, light C/S, > OO-like extensions, Java client, NT support, multimedia, etc...). > Four J's Development Tools target is to bring enough resources > to the 4GL language to provide a true and modern development > environment as VB, Delphi and others did with more or less > success. But this is another debate... > I do not agree at all with that. Most of people who go to Linux are looking for a simple, performant and a global lower costing solution. And many applications do not need all the stuff described above that slows down and makes unstable as well as hard to maintain the overall. Put a good terminal emulator on an old 386, 4 MB RAM and 80 MB disk under Win 3.1, and the people working on it using your remote 4GL application will perform as well as one with the latest machine under Win98, now required for running any client application. The advantage of using the second solution? Only having colors and mouse usage! But the inconvenients are numerous : 1) Erratic interactions with other applications on the client machine. If it crashes, does that come from the server side or the client? It will be up to you to find that out each time. 2) Did you try to drive a user working in a graphical environment by phone for assistance? Those who are leaded to do that sometimes know what I mean. And this situation occurs more often than many believe, since you do not always have a machine pugged near to you. In this case, I am personally happy to have users working on character based applications. Did those who promote "modern development environments" work just one day as cashier in a shop in front of a queue of impatient clients? Tell me after what you think about mouse usage when you will have shifted all day long between your keyboard and the mouse in a stressing environment. So, let all that stuff to Microsoft clients who may, I suppose, spend their time in a armchair in front of their screen, fingering their nose while waiting the hourglass disappears. My ones are waiting for quick and efficient ways and a black and white screen does not disturb them since the balance sheets they print still show debit=credit. Linus and other Linux contributors did until today a wonderful job by providing such a pragmatic and low-costing system. So, let us keep in this way. Try for example to provide a GNU Informix SE (excellent database) clone and a new GNU 4GL (improvable development tool). We will do a lot of things, only with that. Pascal Ferrari

First of all, George, Bon jour! :-) It was a pleasure to catch up with you in France this past September, I enjoyed Paris very much. I will be back. Please make no mistake, I am grateful for having an opportunity to evaluate your product. But the agony I went through to try to get it installed was great. I was never able to get it to install on Linux. I have recently received a D4GL CD for evaluation and will take a look at the features it provides, however, after having failed to install it the last time, I will be very skeptical. The price is also way too high to be taken seriously. "Georges A. Tomazi" wrote: > > Hello Tim, > > Tim Schaefer wrote: > > > [...] > > > > 4Js - Impossible to install on Linux. > > > > [...] > > I would like comment a bit your quick statement... > > First of all, I find quite unfair your comment as you know that > Linux is our primary in-house development platform. This is > true since more than two years and we have always been very > strong supporters of the free software community. Just look > at our windows client being an evolution of TCL/Tk. Don't > forget that the GPL licensed type of software is so successful > today not only because of its quality but also because of > commercial companies supporting it (IBM, Sun Microsystems, > Informix, Cygnus, ...). > No argument with you here. > Because of Informix legal issues, we could not release the > native port of Four J's Universal Compiler on Linux earlier than > July 1998. However, we provided to many customers the > the tip of using Four J's Universal Compiler with the iBCS > compatibility module. > > Now, Linux have the same priority as all other major OS vendors > we support (Sun, HP, IBM, SGI, SCO, ...). Four J's Universal > Compiler works extremely well on Linux ! > > I am curious to know what make you stating that it is impossible > to install on Linux ! Note that if you downloaded the evaluation > version from our web site, or if you used an old Four J's software > this is the old iBCS version and this is clearly mentionned in our > download page or release notes. We should have the native Linux > demo version online shortly, but we primarly focus in supporting > our customers rather than updating our demo version with our > very latest software. As I said above, I will be evaluating ( finally ) D4GL. We had to go through a sales monkey to get a CD, when it should simply be available for download off the web. However, I doubt seriously that we will be buying it because of the extremely high price, and the runtimes, etc. We were given an invoice for: $25,000.00 - 5 users Linux $25,000.00 - 5 users AIX $50,000.00 Total At $5000 per developer this is way too expensive. I remember at the last IWUC of hearing that D4GL was going to be at the most $3000.00/user. Even this was absurd, and I expected to hear the price going down to something more reasonable. Classic 4GL should be a part of every engine sale, not as a sale but as a component of the engine. It is a better product that the transact-sql for Sybase users, and provides the same and greater functionality that transact-sql does. Without it, the engine is wonderful, but lacking good tools besides ESQLC to build a solid server. But to sell it separately misses the point. D4GL is probably a great tool, but it will probably go the way of New Era. By limiting the access and keeping the price high, it will be by-passed for other tools, namely Java. 4GL of any kind has a limited marketing window for the long term. Will new developers spend any time on it? Unknown. But most will not want to go through a sales monkey, and this will eliminate most of the developer community. IDS 7.3 on Linux had 19,000 downloads according to Informix, and this was a chance for 19,000 4GL developers to put Classic 4GL into production. Informix missed the boat bigtime on this. If developers like Classic 4GL, chances are they might migrate to D4GL IF it is cheap and easy to install. This is not possible currently. > > Note that INFORMIX Dynamic 4GL is exactly the same software > than Four J's Universal Compiler (at equivalent release level), thus > both will support Linux the same way. So I also disagree with your > statement "D4GL which is messy to use and difficult to impossible > to install." ! > I'll believes it when I see it. :-) > Regarding the "Classic 4GL" issue, I don't see the point of using > it anymore as D4GL is nearly 100% compatible, while bringing > a lot of new business opportunities if you wish to use the > existing or upcoming extended capabilities (graphics, light C/S, > OO-like extensions, Java client, NT support, multimedia, etc...). > Four J's Development Tools target is to bring enough resources > to the 4GL language to provide a true and modern development > environment as VB, Delphi and others did with more or less > success. But this is another debate... > > Georges > > -- > Georges A. Tomazi [gt@4js.com] > Vice President - Operations > Four J's Development Tools George, Unless your product gets into as many hands as possible, especially here in the United States, via download first, and later purchase, it doesn't stand a chance against the myriad of other products on the open market. We have too many choices, and too little time to think about what we use. Let New Era be your guide. It was never allowed into wide release without a sales monkey, subsequently there were no developers to build a market. Without developers you don't have a market. Developers will not spend time on something they do not find work available in. If shops don't use it, how will developers feed themselves? Developers will ask themselves if they can find work with certain tools and apps. If there is no work why would they spend time learning a particular product. If it isn't in front of us, it doesn't exist. If it isn't available on the web as a download, it doesn't exist. If it isn't priced for individual developer pricing for all developers it doesn't exist. You will have to incur UP FRONT the cost of seeding the market with your product, then over time recoup the money from the momentum of developers actually using it in production. Make it available for free or very cheap to develop with. If you make it free to develop with, and a developer puts a program into production, then they pay for the software ONCE, and no runtimes. Future apps will be considered first in D4GL because now the developer has recouped UP FRONT their cost associated with your tools. Developers don't code for free, this is how they pay their bills. Over time you will have to come up with additional products and add-ons to stay profitable, but you will be building a following. Microsoft has done this for years. If you charge a reasonable price for it, they will buy it. The developer will then deploy more apps, and thus your product will be used. I would imagine your product would sell well between $300 and $500 per developer, but not $5000, which is w

Mike Jagdis wrote: > David Williams said > >Jonathan Leffler <jleffler@earthlink.net> writes: > >>But I'd still prefer to use the Linux version of I4GL. > > Which hasn't yet been released as far as I am aware :-(. Which has been released, which is why I said anything! -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>