Re: 64-bit 4GL woe
Has this involved an upgrade to 64 bit as well or has the system always been 64 bit? There are some gotchas if you migrate form 32 to 64 bit on Solaris. Basically 32 bit a LONG is 4 Bytes, 64 bit a long is 8 bytes. I think there hgas been some discussion on this board regarding this problem previously. johnd Neil Truby wrote: > "Jonathan Leffler" <jleffler@earthlink.net> wrote in message > news:RdBKe.4229$WD.1054@newsread1.news.pas.earthlink.net... > > Neil Truby wrote: > >> "Murray Wood (IList)" <ifxmaillist@quanta.co.nz> wrote in message > >> news:1123645133.257cb02d827aeaafe16d74722574be86@teranews... > >> > >>>4GL 7.32.UC2 with IDS 10.00.FC3 with no problems. > >> > >> > >> Thanks. The install order seems to matter again though, did you notice > >> that? > > > > Which one works? I'd predict I4GL before IDS, but live to learn. > > > As with Murray Wood, I found that 4GL, ISQL and then IDS works fine PROVIDED > you don't accept the default IDS 10 install which also installs CSDK and > Java too - that screws the toolsets up. > > > The only caveat is that you cannot used shared memory connections if the > > server is 64-bit and the client is 32-bit (or vice versa). > > Indeed. This is one of a number of reasons why I frustrated that we have > not been able to get the 64-bit stuff working. I guess IBM Tech Suupport > may eventually come up with the answer but in the meantime we're having to > use the 32-bit versions.
"scottishpoet" <dryburghj@yahoo.com> wrote in message news:1123839051.615630.19120@o13g2000cwo.googlegroups.com... > Has this involved an upgrade to 64 bit as well or has the system always > been 64 bit? > > There are some gotchas if you migrate form 32 to 64 bit on Solaris. > Basically 32 bit a LONG is 4 Bytes, 64 bit a long is 8 bytes. > > I think there hgas been some discussion on this board regarding this > problem previously. > > johnd IBM Tech Support in the UK did come up with the goods - see explanation below - and we're back on track with the 64-bit toolsets having made the minor changes highlighted. regards Neil Here's the problem ... In 32 Bit environment - INTEGER is 4 bytes and LONG in C is also 4 bytes. In 64 Bit environment - INTEGER is 4 bytes and LONG in C is 8 bytes. This issue seems to appear because SUN has modified fopen() etc to use 64 bit numbers instead of 32 bit numbers. Informix has no mechanism to cope with these new 64 bit numbers although there might be a different work around using bigints. Therefore a work around is to split the 64 bit long into 2 32 bit integers and passed these back to the 4GL. This has means small changes to the 4gl code for the 64 bit environment. Please find an example based on the code previously mentioned in the case ....