Upgrading from I4GL 1.10??
A user with a 1990-vintage I4GL 1.10 / C-ISAM application asked how much code rework a move to current I4GL (or D-4GL) would need, and whether gcc on Solaris could be used. Respondents who had done the same upgrade (to 7.2x) reported very little change: the main gotcha is cursor names becoming module-scoped rather than global, fixed either by compiling with -globcurs (if cursor names are unique) or by using CURSOR_NAME() when building prepared statements referencing a cursor. For gcc, compile with -fwriteable-strings, since 4GL writes to literal strings.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Yes, you read the subject right. I have an application running on I4GL 1.10 (on C-ISAM database 2.10) circa 1990. We're considering upgrading to the latest 4GL and maybe D-4GL. The question is, how much coding work is involved? I'm assuming newer versions of I4GL have some changed syntax and functionality that would necessitate some code modifications. So, just how much work might need to be done? Would it be only minor stuff or do you think there is a lot of work in modifying the code for modern-day I4GL? Also, does anybody happen to know if there are any limitations on trying to compile this ancient version with gcc on Solaris? Right we're running a SunOS-compiled version in binary-compatible mode. Just thought I'd ask before trying to set up gcc on the Solaris machine. Thanks, Mike Sent via Deja.com http://www.deja.com/ Before you buy.
Hi! Just completed move from 1.10 to 7.2x. The only code modifications were to cursor names, because I didn't know about the environment variable that can be set to maintain uniqueness of names per module valid. I used RDS (not compiler) on SCO Unix, so I cannot answer the second part of your question. HTH Michael mdchachi@my-deja.com wrote: > Yes, you read the subject right. I have an application running on > I4GL 1.10 (on C-ISAM database 2.10) circa 1990. > We're considering upgrading to the latest 4GL and maybe D-4GL. > The question is, how much coding work is involved? I'm assuming > newer versions of I4GL have some changed syntax and functionality > that would necessitate some code modifications. > > So, just how much work might need to be done? > Would it be only minor stuff or do you think there is a lot > of work in modifying the code for modern-day I4GL? > > Also, does anybody happen to know if there are any limitations > on trying to compile this ancient version with gcc on Solaris? > Right we're running a SunOS-compiled version in binary-compatible > mode. Just thought I'd ask before trying to set up gcc on the > Solaris machine. > > Thanks, > > Mike > > Sent via Deja.com http://www.deja.com/ > Before you buy.
The only gotcha to the move should be the change from global cursor names to module scoped cursor names. There is a commandline option to C4GL to revert to the older behavior if that gives you trouble. On using gcc with 4GL you have to pass the -fwriteable-strings options to gcc because 4GL writes to pointers to literal strings which GCC does not permit by default. Art S. Kagel mdchachi@my-deja.com wrote: > > Yes, you read the subject right. I have an application running on > I4GL 1.10 (on C-ISAM database 2.10) circa 1990. > We're considering upgrading to the latest 4GL and maybe D-4GL. > The question is, how much coding work is involved? I'm assuming > newer versions of I4GL have some changed syntax and functionality > that would necessitate some code modifications. > > So, just how much work might need to be done? > Would it be only minor stuff or do you think there is a lot > of work in modifying the code for modern-day I4GL? > > Also, does anybody happen to know if there are any limitations > on trying to compile this ancient version with gcc on Solaris? > Right we're running a SunOS-compiled version in binary-compatible > mode. Just thought I'd ask before trying to set up gcc on the > Solaris machine. > > Thanks, > > Mike > > Sent via Deja.com http://www.deja.com/ > Before you buy.
It is in fact the other way round, and you have to use CURSOR_NAME when preparing statements that make use of a cursor, eg let xxx="update blah set blah=1 where current of my_cursor" becomes let xxx="update blah set blah=1 where current of ", cursor_name("my_cursor") or, if you use unique cursor names across your application (eg if prefix the name with a module mnemonic), just use -globcurs -- Ciao, Marco ______________________________________________________________________________ Marco Greco <marco@informix.com> Standard disclaimers apply! Informix faq http://www.iiug.org/techinfo/faq/informix.htm 4glworks http://www.ctonline.it/~marcog Informix on Linux http://www.ctonline.it/~marcog/ifmxlinux.htm "Art S. Kagel" wrote: > > The only gotcha to the move should be the change from global cursor names to > module scoped cursor names. There is a commandline option to C4GL to revert > to the older behavior if that gives you trouble. > > On using gcc with 4GL you have to pass the -fwriteable-strings options to gcc > because 4GL writes to pointers to literal strings which GCC does not permit > by default. > > Art S. Kagel > > mdchachi@my-deja.com wrote: > > > > Yes, you read the subject right. I have an application running on > > I4GL 1.10 (on C-ISAM database 2.10) circa 1990. > > We're considering upgrading to the latest 4GL and maybe D-4GL. > > The question is, how much coding work is involved? I'm assuming > > newer versions of I4GL have some changed syntax and functionality > > that would necessitate some code modifications. > > > > So, just how much work might need to be done? > > Would it be only minor stuff or do you think there is a lot > > of work in modifying the code for modern-day I4GL? > > > > Also, does anybody happen to know if there are any limitations > > on trying to compile this ancient version with gcc on Solaris? > > Right we're running a SunOS-compiled version in binary-compatible > > mode. Just thought I'd ask before trying to set up gcc on the > > Solaris machine. > > > > Thanks, > > > > Mike > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy.