next »

[Matthias K.]

Hello list,

anybody out there with an AIX box and Daylight Savings Time enabled?

The following little program

MAIN
  DEFINE  a CHAR(50)
  LET a = TIME
  DISPLAY a
  SLEEP 5
END MAIN

gives the correct time (let's say: "11:00:00") when compiled with INFORMIX 4GL;
but compiled with Genero (Version 2.10.01-1138) the output is "10:00:00";
i.e. it lags behind  1 hour.

Same effect for "CURRENT HOUR TO SECOND" instead of "TIME".

The AIX is Version 5.3. According to the TZ setting ("CET-1CEST,M3.5.0,M10.5.0"),
the switch from Daylight Savings Time to Standard Time should occur on the last
Sunday of October, that is next Sunday.

It seems to me that the Genero runtime "thinks" that this switch occured already
 last Sunday (October 24, 2010) or, at least, has a different implementation of
 "TIME" compared to the INFORMIX 4GL runtime.
 (One would think,naively,  both of them using the same set of library functions/
 system calls a la ctime/localtime/asctime/strftime ... whatever).
 
Do we have a wrong TZ setting? Any other ideas?

[Reuben B.]

(One would think,naively,  both of them using the same set of library functions/
 system calls a la ctime/localtime/asctime/strftime ... whatever).

... if you ran your test program using strace or whatever the AIX equivalent is, truss?, you could probably see what the actual system call being used is.

Also you mentioned 2.10.01, does the problem occur with any newer versions?

[Matthias K.]

Hi Reuben,

thanks for your reply and the idea using truss.

Unfortunately, there isn't much information in the truss output. When it comes to
opening the (one and only) program module main_m.42m, there is:

4800670: 5533727: 0.2473:        access("main_m.42m", 0)        = 0
4800670: 5533727: 0.2475:        open("main_m.42m", O_RDONLY) = 3
4800670: 5533727: 0.2476:        fstatx(3, 0x0FFFFFFFFFFFE430, 176, 0) = 0
4800670: 5533727: 0.2478:        mmap(0x0000000000000000, 283, PROT_READ|PROT_WR
ITE, MAP_FILE|MAP_VARIABLE|MAP_PRIVATE, 3, 0) = 0x0000000000003000
4800670: 5533727: 0.2479:        close(3)               = 0
4800670: 5533727: 0.2481:        statx("main_m.42m", 0x0FFFFFFFFFFFE450, 176, 0)
 = 0
4800670: 5533727: kwrite(1, 0x0000000110041C14, 51)     = 51
4800670:    1 4 : 2 5 : 2 2
4800670:                                       \n
4800670: 5533727: kwrite(1, 0x0000000110041C14, 51)     = 51
4800670:    1 4 : 2 5 : 2 2
4800670:                                       \n

14:25:22 is the (incorrect) output of the program.
(one line for TIME, the other line for CURRENT HOUR TO SECOND).
No evidence of any time-related system call.

On Linux we are working with a Genero version 2.21; in this case the output is correct.

[Sebastien F.]

For TIME and CURRENT we are using the standard POSIX functions gettimeofday() and localtime() of the C library...

Maybe there is a bug or difference on your AIX machine with these functions?

We must check this, but in the meantime, you could try these functions with a little C program on your side.

Seb

[Matthias K.]

Hi Sebastien,

strange enough, the following example code gives _correct_ time on our AIX machine:

EXAMPLE 1 - localtime

#include <stdio.h>
#include <time.h>


int main(void)
{
  time_t result;


  result = time(NULL);
  printf("%s%ju secs since the Epoch\n",
         asctime(localtime(&result)),
         (uintmax_t)result);
  return(0);

EXAMPLE 1 - gettimeofday

#include <sys/time.h>
#include <time.h>
#include <stdlib.h>
#include <stdio.h>

int main(void)
{
  char buffer[30];
  struct timeval tv;

  time_t curtime;

  gettimeofday(&tv, NULL);
  curtime=tv.tv_sec;

  strftime(buffer,30,"%m-%d-%Y  %T.",localtime(&curtime));
  printf("%s%ld\n",buffer,tv.tv_usec);

  return 0;
}

Whatever; the problem will be gone next Monday anyway.

[Sebastien F.]

Thanks a lot Matthias for testing this... I wonder...
I want to figure out what's going on here.
Seb

[Sebastien F.]

Matthias, in your C examples you have used the asctime() and strftime() C functions to convert the time to a string...
I wonder if these do some additional TZ adjustment...

Can you try this please:
(done on Linux, should be of for AIX... note I pass a timezone structure (tz) to gettimeofday(): yes it's obsolete, but we have this in the code, certainly because older systems required a pointer for this parameter)

#include <sys/time.h>
#include <time.h>
#include <stdlib.h>
#include <stdio.h>

int main(void)
{
  struct timeval tv;
  struct timezone tz;
  time_t curtime;
  struct tm lt;

  gettimeofday(&tv, &tz);
  curtime=tv.tv_sec;
  lt = *(localtime(&curtime));
  lt.tm_year += 1900;
  printf("Current time: %04d-%02d-%02d %02d:%02d:%02d.%ld\n",
         lt.tm_year, lt.tm_mon, lt.tm_mday, lt.tm_hour, lt.tm_min, lt.tm_sec, tv.tv_usec);

  return 0;
}


Thanks!
Seb

[Sebastien F.]

Could you also provide the environment variables you have set (all the env output, except confidential stuff)
Seb

[Matthias K.]

Hi Sebastien,

yes, it _is_ the &tz-pointer.

Your last version (compiled/linked on our AIX box) gives the "wrong" time.
If i change the line

gettimeofday(&tv, &tz);

to

gettimeofday(&tv, NULL);

the correct time appears.

[Sebastien F.]

Cool that you reproduce...

I have tested on our AIX 5.3, but I cannot reproduce (with tz pointer passed):

comp@newton:~/sf$ uname -a
AIX newton 3 5 00006E42D900
comp@newton:~/sf$ export TZ="CET-1CEST,M3.5.0,M10.5.0"
comp@newton:~/sf$ xlc -o localtime.bin localtime.c
comp@newton:~/sf$ ./localtime.bin
Current time: 2010-09-29 11:37:17.961237
comp@newton:~/sf$ date +%H:%M:%S
11:37:45

We need to check your env...
Can we get the patch level of you AIX machine?

Seb

[Matthias K.]

Hi Sebastien,

our environment and the patchlevel (see attachments).

[Patrice L.]

Hello,

It seems that is a known issue introduced by IBM in AIX 5.3 TL 6 & 7 and fixed in TL8.

You certainly can fix your issue by applying the fix of following APAR : http://www-01.ibm.com/support/docview.wss?uid=isg1IZ22212 or by upgrading to a more recent TL.

Regards,
Patrice

[Matthias K.]

Hello Patrice and Sebastien,

many thanks for your efforts and patience.
Yes, it seems like APAR IZ22212 describing exactly this behaviour.

I'll try to upgrade to a newer TL.

Have a nice weekend!