Re: 4GL 7.20, IDS 9.4

This is a multi-part message in MIME format. --------------030403020904040809060107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Forgive me if I am wrong, but 9.x is 64 bit engine and 7.x is 32 bit. So, that means, if you are using still old 4gl, you cannot connect using shared mem to dbase. you need tcp/ip bye dhali Jonathan Leffler wrote: >Five Cats wrote: > > > >>Does anyone know if we can continue to use programs written in 4GL v7.20 >>(currently running with IDS 7.3x) if we upgrade the engine to 9.4x? The >>platform is SOLARIS - can't remember which exact version, can find out >>if it matters. >> >> >> > >As others have said, it should be OK. However, I4GL 7.20 should not >really be in use, regardless of which side of the .UEn divide you are >working with (p-code version 602 prior to UE1, 720 from UE1 upwards, >with an incompatiblity accidentally introduced at UD6 or thereabouts). > > > >>The only reason for the upgrade is the 2GB limit. It is stopping them >>doing dbexport to disk as the largest table (31 million rows) is larger >>than 2GB when unloaded. Actually I think they are getting horribly >>close to it being larger than 2GB in the data pages as well. >> >> > >As others said, the dbexport to disk can run into issues, but the DBMS >is not troubled by 2 GB limits - unless you don't add chunks to your >dbspace. > > > >>We don't want to alter the version of RDS due to the issues with the >>p-code altering and our having to then recompile and reissue all the >>programs. They have a complicated mixture of standard and bespoke >>programs, and recompilation would for one thing might well show that >>there is a degree of uncertainty as to where all the correct source for >>the bespoke is.... >> >> > >I recommend doing the recompilation immediately -- otherwise your >bespoke problems will get worse and worse. You need to address the >issue now - immediately, if not the year before last - rather than >wait till one of your bespoke customers asks for a revision to their >bespoke package. > > > --------------030403020904040809060107 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> Forgive me if I am wrong,<br> <br> but 9.x is 64 bit engine and 7.x is 32 bit. So, that means, if you are using still old 4gl, you cannot connect using shared mem to dbase. you need tcp/ip<br> <br> bye<br> dhali<br> <br> Jonathan Leffler wrote:<br> <blockquote type="cite" cite="midC1w5c.23590$%2506.20473@newsread2.news.pas.earthlink.net"> <pre wrap="">Five Cats wrote: </pre> <blockquote type="cite"> <pre wrap="">Does anyone know if we can continue to use programs written in 4GL v7.20 (currently running with IDS 7.3x) if we upgrade the engine to 9.4x? The platform is SOLARIS - can't remember which exact version, can find out if it matters. </pre> </blockquote> <pre wrap=""><!----> As others have said, it should be OK. However, I4GL 7.20 should not really be in use, regardless of which side of the .UEn divide you are working with (p-code version 602 prior to UE1, 720 from UE1 upwards, with an incompatiblity accidentally introduced at UD6 or thereabouts). </pre> <blockquote type="cite"> <pre wrap="">The only reason for the upgrade is the 2GB limit. It is stopping them doing dbexport to disk as the largest table (31 million rows) is larger than 2GB when unloaded. Actually I think they are getting horribly close to it being larger than 2GB in the data pages as well. </pre> </blockquote> <pre wrap=""><!----> As others said, the dbexport to disk can run into issues, but the DBMS is not troubled by 2 GB limits - unless you don't add chunks to your dbspace. </pre> <blockquote type="cite"> <pre wrap="">We don't want to alter the version of RDS due to the issues with the p-code altering and our having to then recompile and reissue all the programs. They have a complicated mixture of standard and bespoke programs, and recompilation would for one thing might well show that there is a degree of uncertainty as to where all the correct source for the bespoke is.... </pre> </blockquote> <pre wrap=""><!----> I recommend doing the recompilation immediately -- otherwise your bespoke problems will get worse and worse. You need to address the issue now - immediately, if not the year before last - rather than wait till one of your bespoke customers asks for a revision to their bespoke package. </pre> </blockquote> </body> </html> --------------030403020904040809060107-- sending to informix-list