FORTRAN interface to CRTL functions

[Ph Vouters]

Hi Michael,

If you consider the technical articles at http://vouters.dyndns.org/tima/Linux-Fortran-Internationalizing_messages.html and http://vouters.dyndns.org/tima/OpenVMS-Fortran-Internationalizing_messages.html perform exactly the same. However my HP Fortran for OpenVMS not recognizing ISO_C_BINDING, the VMS solution to this problem is entirely OpenVMS dependant. This is no matter of the VMS CRTL often prefixing its routines with DECC$.

In the hope this can give you some clues.
Philippe

[Joseph Huber_1]

In general I would discourage direct calls of decc$* routines (except the ones documented in CRTL help): You never know what macros the C compiler is defining/expecting/using.
See this example:

program test_ctime
character*32 ct
integer t
integer decc$time
external decc$time

t=0
call CTIME_F(t,ct)
print *,' t=',t,' ',ct

print *,' using time_f():'
call time_f(t)
call CTIME_F(t,ct)
print *,' t=',t,' ',ct

print *,' using decc$time():'
t=decc$time()
call CTIME_F(t,ct)
print *,' t=',t,' ',ct
end


Where time_f.c and ctime_f.c are the wrapper routines at
http://www.mpp.mpg.de/~huber/util/

fortran test_ctime
link test_ctime
show time
5-FEB-2011 21:17:07
run test_ctime
t= 0 Thu Jan 1 01:00:00 1970
using time_f():
t= 1296937035 Sat Feb 5 21:17:15 2011
using decc$time():
t= 1296940635 Sat Feb 5 22:17:15 2011
Observe the different values for t !

There are even more discrepancies when mktime() comes into play:

http://www.mpp.mpg.de/~huber/util/tests/test_mktime.for

[Joseph Huber_1]

mktime e.g. needs

#define _DECC_V4_SOURCE
#define _VMS_V6_SOURCE
#define _TM_LONG
#define USE_GMTOFF /* seems always to give the correct offset*/
#define __USE_XOPEN 1
#define _XOPEN_SOURCE
#define __TM_USE_UTC_TIME

to produce the right result:

sh time
6-FEB-2011 10:54:56
run test_mktime
1296989699 ctime_f(decc$time()):
Sun Feb 6 11:54:59 2011

1296989699 ctime_f(decc$mktime(gmtime_f(decc$time(),tm))):
Sun Feb 6 11:54:59 2011

1296989699 ctime_f(mktime_f(gmtime_f(decc$time(),tm))):
Sun Feb 6 11:54:59 2011

1296986099 ctime_f(time_f()):
Sun Feb 6 10:54:59 2011

1296986099 ctime_f(mktime_f(gmtime_f(time_f(),tm))):
Sun Feb 6 10:54:59 2011

The results of ctime() should match the VMS show time, they do not if decc$ calls are used without wrappers!

Without that definition,
ctime_f(mktime_f(gmtime_f(time_f(),tm)))
is not the same as
ctime_f(time_f())

So again, direct calls to decc$time,decc$gmtime,decc$mktime do not produce the correct results.

[Michael Menge]

Is there an explanation for the different seconds from time() and decc$time() (missing/other c-macros active) or is it a bug? A call to decc$crtl_init() gives the same results.

[Joseph Huber_1]

Have a look into
If not the behaviour of VMS before V7 is requested by macros like _DECC_V4_SOURCE and _VMS_V6_SOURCE (see HELP CRTL TIME FUNCTION_VAR), then a C time() call uses an __UTC_* entry point. The DECC_V4/VMS_V6* macros would result in time_t to be calculated from local VMS time, resulting in 1 hour difference in my (MET) case, which seems to be the case for direct calls to decc$time().

Other differences come from compiling gmtime(_r) with or without the __TM_USE_UTC_TIME and *GMTOFF* macros.
Interestingly I need to compile mktime with the _V4_/_V6_ macros to have the above chain of
ctime(time())
giving the same result as
ctime(mktime(gmtime(time(),tm))),

but this may be due to the old VMS/DECC version combination I have.

[Michael Menge]

decc$localtime_r returns GMT time and
decc$gmtime_r returns (as mentioned) only 0:
program test
integer tm(0:10),scnds
scnds = 1301184000 ! 2011-03-27T00:00:00Z
tm = 0
call decc$gmtime_r (scnds,tm)
print *, 'gmt', scnds, tm
tm = 0
call decc$localtime_r (scnds,tm)
print *, 'local', scnds, tm

scnds = 1301194800 ! 2011-03-27T03:00:00Z
tm = 0
call decc$gmtime_r (scnds,tm)
print *, 'gmt', scnds, tm
tm = 0
call decc$localtime_r (scnds,tm)
print *, 'local', scnds, tm
end

Isn't it a bug for decc$gmtime_r returning nothing or are there any hints not to use it?

[Michael Menge]

Replacing decc$gmtime_r by the wrapper routine gmtime_f mentioned above and
decc$localtime_r by localtime_f.c:

#include
struc tm *localtime_f (const time_t *scnds, struc tm *result)
{
return localtime_r (scnds, result);
}

gives the correct results.

[Joseph Huber_1]

> decc$localtime_r returns GMT time and
but -as the name indicates- should return local time.


>decc$gmtime_r returns (as mentioned) only 0:
>Isn't it a bug for decc$gmtime_r returning >nothing or are there any hints not to use it?

There are no hints not only not to use it, but also no hints to use it.

Since direct calls to decc$* are not documented, all is speculation and mood.

[Ph Vouters]

For the record. HP Fortran for OpenVMS solution. Next time write a corresponding C program and $ cc/list/machine to know which DECC$ entry points the HP C compiler uses.

$ fortran/source_form=free/debug/noopt gmtime.f90
$ link gmtime
$ run gmtime
tm%tm_sec= 21
tm%tm_min= 18
tm%tm_hour= 11
tm%tm_mday= 9
tm%tm_mon= 111
tm%tm_wday= 9
tm%tm_yday= 39
tm%tm_isdst= 0
$ type gmtime.f90
program gmtime
implicit none
integer(kind=4) t0;
integer(kind=4) tm_ptr;
external print_tm, decc$perror
integer(kind=4),external :: decc$__utc_time ,decc$__utctz_gmtime

t0=decc$__utc_time(%val(0))
tm_ptr=decc$__utctz_gmtime(%ref(t0))
if (tm_ptr .eq. 0) then
call decc$perror(%ref('gmtime'))
stop
endif
call print_tm(%val(tm_ptr))
stop
end

subroutine print_tm(tm)
implicit none
type tm_t
integer(kind=4) tm_sec
integer(kind=4) tm_min
integer(kind=4) tm_hour
integer(kind=4) tm_mday
integer(kind=4) tm_mon
integer(kind=4) tm_year
integer(kind=4) tm_wday
integer(kind=4) tm_yday
integer(kind=4) tm_isdst
integer(kind=4) tm_gmtoff
integer(kind=4) tm_zone
end type tm_t
type (tm_t) tm

print *,"tm%tm_sec=",tm%tm_sec
print *,"tm%tm_min=",tm%tm_min
print *,"tm%tm_hour=",tm%tm_hour
print *,"tm%tm_mday=",tm%tm_mday
print *,"tm%tm_mon=",tm%tm_year
print *,"tm%tm_wday=",tm%tm_mday
print *,"tm%tm_yday=",tm%tm_yday
print *,"tm%tm_isdst=",tm%tm_isdst
return
end

[Ph Vouters]

Michael,

The full solution is documented at http://vouters.dyndns.org/tima/OpenVMS-Fortran-time-gmtime-Calling_time_and_gtime_in_Fortran_OpenVMS.html
Yours truly,
Philippe