The year 2038 problem is associated with the Unix time format (which is seconds since January 1, 1970). The Open
Group standard defines this value as the typedef time_t, with the exact representation left as an implementation
choice. Traditionally, most Unix systems have used a signed 32 bit integer for time_t. This value overflows
and becomes negative at 68 years - year 2038.
OpenVMS has APIs that use this time format, notably the CRTL, DECthreads, and other Unix compatible interfaces.
The OpenVMS native time format is 64 bits and is not vulnerable to this problem.
OpenVMS dealt with the year 2038 problem as part of the Year 2000 (Y2K) response, back in 1998. The CRTL now
defines time_t as an unsigned 32 bit integer, extending its range to 136 years (thus expiring in 2106). There is
a compile time option that allows an application to declare time_t as a signed integer, provided to address
potential compatibilty issues with applications that assumed a signed value. All C language VMS components are
compiled with the default unsigned value.
As a result, all OpenVMS-based software that uses Unix time formats should not be vulnerable to the year 2038
problem as long as it has been compiled within the last 10 years or so.
For additional information on OpenVMS releases that have the Y2K patch included, please refer to http://h71000.www7.hp.com/openvms/products/year-2000/index.html