Conference helix::vaxeln

    We became aware of this issue yesterday. Coincidently, both you and
    somebody else inquired about it at the same time.
    
    The problem is the known restriction that the ASCII representation of 
    relative times (i.e. time intervals) cannot exceed 9999 days. A
    relative time is represented in ASCII like this:
    
    		"dddd hh:mm:ss.cc"
    
    That's just the way it was defined back a long time ago. Note that this
    is not a restriction on interval times themselves but a restriction on
    converting them to and from ASCII.
    
    The issue before us is that next month is 10,000 days from the start of
    UNIX time -- January 1, 1970. By far, most VAXELN application don't
    give a hoot about 1970. VAXELN time is 64 bit count of clock ticks
    based at November 17, 1858. The 10,000 days that everyone is worried
    about came and went long before any of us was born. The restriction on
    the ASCII representation of relative time was a restriction when VAXELN
    V1.0 was released, is a restriction now and probably will be a
    restriction forever. You can leave the time set in 1858, set it for
    1997 or any time in between and you'll never have to worry about
    representing your interval times in ASCII until they get longer than
    9999 days. Don't forget, the most common use of an interval time is to
    give to wait_any so you'll sleep for a little while. What kind of an
    application would need to sleep for 27 years?
    
    There are two routines which take as parameters an ASCII representation
    of relative time -- ELN$TIME_STRING() and ELN$TIME_VALUE. One converts
    from ticks to ASCII and then other from ASCII to ticks. These two
    routines are the extent of the restriction on VAXELN.
    
    A problem might have been possible next month if you're using POSIX.
    POSIX time is also based on a number of seconds since 1970 and the
    VAXELN kernel sets your time from 1858 to 1970 whether you like it or
    not. Any POSIX routine which, internally, tried to convert relative
    times from seconds to ticks or vice versa using ELN$TIME_STRING() or
    ELN$TIME_VALUE() would have been in trouble. So far, we haven't found
    any. The POSIX time routines perform conversions in their own little
    world. By contrast, some of the VMS POSIX support used functions like
    SYS$ASCTIM() and SYS$BINTIM() and got hosed.
    
    So far no problems. We're going to have someone look into the issue
    more carefully. We'll let you know if there's any more news.

    
Here is the list of VMS impacted routines : 

LIB$CVT_TO_INTERNAL_TIME      (not emulated in ELN)
LIB$CVT_FROM_INTERNAL_TIME    (not emulated in ELN)
LIB$CVTF_TO_INTERNAL_TIME     (not emulated in ELN)
LIB$CVTF_FROM_INTERNAL_TIME   (not emulated in ELN)
LIB$CVT_VECTIM                (not emulated in ELN)

LIB$SUB_TIMES                 (emulated in ELN)
LIB$ADD_TIMES                 (emulated in ELN)
LIB$MULT_DELTA_TIME           (emulated in ELN)
LIB$MULTF_DELTA_TIME          (emulated in ELN)
LIB$CONVERT_DATE_STRING       (not emulated in ELN)

    The LIB$ routines you're talking about (as well as SYS$BINTIM and
    SYS$ASCTIM) have the same restriction as ELN$TIME_STING and
    ELN$_TIME_VALUE -- the limit on the number of days in the ASCII
    representation of relative time is 9999. This is not a bug.
    
    The only time you're going to run into the problem with this is if
    something in the VAXELN operating system (or in your application) tries
    to convert a relative time larger than 9999 days to ASCII.  That's
    illegal. We're pretty sure this doesn't happen in the O/S. In any case,
    the issue has nothing to do with January 1, 1970 and the 10,000 day
    anniversary next month.

    VMS is screwed up because their POSIX support uses those conversion
    routines in the operating system illegally. Whoever did their POSIX
    support didn't pay attention to their own documentation.
    
    We think the POSIX support in VAXELN doesn't use any of the ELN$ or
    LIB$ routines to convert VAX time to POSIX time. It does conversions
    all by itself and doesn't know anything about the 9999 day limit. I ran
    some tests with the date set to after the 10,000 days since 1970 and
    had no problem with POSIX clocks and timers and POSIX time conversion
    routines.
    
    If your POSIX application has a bug it *might* be sensitive to the day
    coming next month since your time starts at 1970. However, it's still
    the application's bug. You can't call ELN$TIME_STRING or ELN$TIME_VALUE
    (or any of those other routines) with a relative time greater than 9999
    days, ever. It's still unclear to me how or why an application would
    need a relative time this large in the first place.

    For traditional VAXELN application, the whole thing is big yawn. For
    POSIX/VAXELN applications, you're should be fine as long your
    application is just calling normal POSIX routines to manipulate the
    clock and timers. If you're doing something kooky like using
    ELN$TIME_STRING or ELN_TIME_VALUE to convert seconds to strings or
    strings to ticks (or whatever), you're could be in trouble.
    
    In the VAXELN world, May 19, 1997 is just another day. Actually, it's a
    Monday holiday in Canada. Maybe we should all stay home that day and
    rest.

    
    Hi,
                                                      
    I work as an on-site software support for a large VAXeln customer
    (Reuters) in London. 
    
    I have been asked whether VAXeln is affected by the 10,000 day delta
    time problem. Is there an official document or can I put together 
    something from the last replies? I have concerns doing this however as
    the VMS customer letters were passed by legal etc from reading the notes
    in the VMSNOTES conference.
    
    Thanks,
    
    Dave Bono (MCS London)

    None of my comments on this issue are appropriate for redistribution.
    
    I'll ping the Engineering Manager about an impact statement which can
    be shown to customers.

Jerry Hudgins of Corning wants to know  what the impact of the 10,000 day 
delta time problem under VAXELN will be.  He sent us the following as an 
example of the type of time conversions he is doing.


Sumithra

/*
 *  Routines to convert between VAX quadword time and the UNIX/POSIX
 *  timespec structure.  Usable under both VMS and VAXELN with the
 *  VAX C and DEC C compilers.
 */ 

#ifndef CVTTIME_H
#define CVTTIME_H

#ifndef HOST
#include $vaxelnc
#endif /* !HOST */

#include time

#ifdef HOST

typedef struct LARGE_INTEGER {
   unsigned int	low;
   int          high;
} LARGE_INTEGER;

struct timespec {
   time_t tv_sec;
   long   tv_nsec;
};

#endif /* HOST */

LARGE_INTEGER   cvt_unix_to_vax_time(struct timespec *);
struct timespec cvt_vax_to_unix_time(LARGE_INTEGER *);

#endif /* !CVTTIME_H */

/*
 *  Routines to convert between VAX quadword time and the UNIX/POSIX
 *  timespec structure.  Usable under both VMS and VAXELN with the
 *  VAX C or DEC C compilers.
 */

#ifndef HOST
#include $vaxelnc
#endif /* !HOST */

#include time
#include "cvttime.h"

/*
 *  VAX time representation of 1 second
 */

#define SECONDS_TO_QUADWORD (10000000L)

/*
 *  VAX time representation of UNIX epoch (01-Jan-1970 00:00:00.00)
 */

static const LARGE_INTEGER unix_epoch = {
   0x4beb4000L,
   0x007c9567L
};

/*
 *  Convert UNIX timespec structure to VAX quadword time.
 */

LARGE_INTEGER
cvt_unix_to_vax_time(struct timespec *unixtime)
{
   LARGE_INTEGER delta;
   LARGE_INTEGER result;
   long multiplier;
   long multiplicand;
   long addend;
   
   multiplier   = -SECONDS_TO_QUADWORD;
   multiplicand = unixtime->tv_sec;
   addend       = unixtime->tv_nsec / 100L;
   lib$emul(&multiplier, &multiplicand, &addend, &delta);
   lib$add_times(&delta, &unix_epoch, &result);
   return result;
}

/*
 *  Convert VAX quadword time to UNIX timespec structure.
 */

struct timespec
cvt_vax_to_unix_time(LARGE_INTEGER *vaxtime)
{
   struct timespec result;
   LARGE_INTEGER delta;
   long divisor;
   long quotient;
   long remainder;

   lib$sub_times(vaxtime, &unix_epoch, &delta);   
   divisor = -SECONDS_TO_QUADWORD;
   lib$ediv(&divisor, &delta, &quotient, &remainder);
   result.tv_sec  = quotient;
   result.tv_nsec = remainder * 100L;
   return result;
}

    

    Yes, this program will break.
    
    If you set the date to May 19, 1997 and run it, the first LIB$SUB_TIMES
    will return the LIB-F-IVTIME (invalid time passed in, or computed)
    error message. The operating system will work exactly as intended, i.e.
    it will not crash. 
    
    ELN$SUB_LARGE_INTEGERS wouldn't have this problem because it works
    differently. It subtracts two absolute times and produces an absolute
    time. LIB$SUB_TIMES subtracts two absolute times and produces a delta
    time.
    
    I'm not sure what to do about this. It's still not a bug in VAXELN.
    Changing the LIB$ routines to allow invalid delta times could cause
    more problems than it solves. 

    
    Jerry Hudgins came up with the following workaround.  I thought you
    might be interested.
    
    >Sumithra:
    
    >I finally noticed that VAXELN also provides emulations for LIB$ADDX and
    >LIB$SUBX, so I've been able to replace LIB$ADD_TIMES and LIB$SUB_TIMES
    >with these and thus avoid the delta-time problem.  I'd still appreciate
    >hearing what Engineering eventually has to say about this issue, of
    >course.  Thanks.
    
    >-jch
     

    I guess they could also do two calculations. For dates after May 19,
    1997, first get the number of seconds from Jan 1, 1970 to May 19, 1997
    (a fixed number) and then get the number of seconds from May 19, 1997
    to the current time. Then add them together. There won't be a problem
    for 27 more years. I hope we'll all be retired by then.
    
    I can't see the 9999 day restriction getting removed in VAXELN. It
    would involve a lot of changes all over the operating system and would
    run the risk of breaking existing, innocent applications. VMS had
    little choice because their code crashed violently in several cases.
    
    We're going to make a decision soon.

    So people can find the official information they need on this issue,
    I've hidden all the replies to this note and write-locked it so no
    further replies can be made. Please refer to note 6.* for the whole
    story.