Re: Informix on AIX

I don't have a good answer for what the problem is. Jason Harris (jharris@westpac.com.au) wrote: >Daniel Wright <dw420@airmail.net> wrote: >>Chengteh Lee wrote: >>> I installed >>> INFORMIX-ESQL/C 5.00.UC2, >>> INFORMIX-4GL 4.10.UD3 >>> INOFRMIX-SE 5.00.UC3 >>> on AIX and complied our applications (in C) for some of our clients. >>> >>> We use infomix function, rdefmtdate, to convert Date string, >>> rdefmtdate(&ldate, "mm-dd-yyyy", str_date); >>> >>> I have input str_date = 07-11-1997, and informix return >>> ldate = 2104819714. I don't have much information >>> about this informix version. >>> I wonder if there are people using similar version of >>> Informix. Please tell me if this version support 4 digit year. >>> If the answer is yes, why I got this crazy return value? > >I have seen that value a lot when using ESQL/C. It usually represents a >null value. Though I cant tell you why it would be returned. Umm, it looks a bit like NULL, but it is not actually NULL. NULL would have the hex value 0x80000000; that number has the hex value 0x7D750002. It doesn't correspond to an error number either. And the correct answer has the hex representation 0x8B25 which is not easily related to that value. >>> ps. I set the enviornment variable: DBDATE=MDY4-. The value of DBDATE has no effect on this conversion. >>I can't really explain it, but that number does seem familiar. >>It sounds like the maximum value for a long integer on most UNIX >>systems. (as defined in /usr/include/limits.h). It isn't INT_MAX or LONG_MAX by 4 million or so. >>7-11-97 shouldn't exceed this value (if it's a DATE type informix >>variable, which if I recall correctly is the number of days since 1900.) It doesn't; the answer is 35621, barely out of range of a signed short let alone a long. >>Is ldate defined as a long? This is a good question. >>If I were you, I'd double-check Informix docs as to DBDATE and see if >>other dates gave you similar results. >>If that seems right, double-check that str_date really contains the >>string you think it does (Do a printf or fprintf() immediately before >>the call to rdefmtdate().) However, I note that the code is not testing the return value from rdefmtdate(), which should be zero on success and negative if it fails -- the negative value wouldbe the error number. Unless you are testing the return status, it may simply be a question of the conversion is failing (for as yet unknown reasons), and the output value is not being set at all. Have you printed ldate before the call as well as after? On Solaris 2.5.1 with ESQL/C 7.23.UC1, the following code works OK, and produces the output: 07-11-1997 => 35621 (rc = 0) I'd expect to get the same answer from any version of ESQL/C from 5.00 upwards. I'm not sure whether rdefmtdate() was part of 4.1x ESQL/C, so if you are mixing ESQL/C 4.1x from the I4Gl with ESQL/C 5.0x, that may be the source of some of your problems. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> PS: I decline to respond to messages with anti-spam in the return path. #include <stdio.h> int main() { long ldate; int rc; char *str_date = "07-11-1997"; rc = rdefmtdate(&ldate, "mm-dd-yyyy", str_date); printf("%s => %ld (rc = %d)\\n", str_date, ldate, rc); return(0); }