Pro/Venix and Y2K

[David C. Jenner]

It's "bad" in the sense that the evidence available (empirical,
and sparse code) suggests that the software (and probably the
hardware) is working with only two-digit years.

You could, of course, try to remedy the Y2K problem by properly
handling the clock.  But the evidence suggests that the
problem may be spread over lots of code.  As you say, it would
be nice to have the Pro/Venix code (as opposed to the Venix/Pro
code).

DEC's Pro/Venix is more flexible than Venturecom's Venix/Pro.
You can write and link custom device drivers with the kernel
in Pro/Venix.  There is some hope you could actually "fix"
/dev/clock, but this probably isn't enough to solve the whole
Y2K problem.

Again, any knowledge about the whereabouts of even the binary
distribution disks of DEC's V2 Pro/Venix would be great.

Dave

Tim Shoppa wrote:
> 
> >There's some confusion about this (at least in my mind), so any
> >authoritative info would be interesting.
> 
> I agree - and would love more definitive information (Or, even
> better, the sources to Pro/Venix.)  I've
> learned an amazing amount about segments of the Unix lineage
> just from the comments in the past week, but the gaps in
> my knowledge still loom large!
> 
> It's entirely possible that Pro/Venix uses the Pro
> clock in BCD mode - it looked to me that the 2.9BSD version
> does it in binary mode.
> 
> >struct clkbuf {
> >       int clk_sec;    /* second (0-59) */
> >       int clk_min;    /* minute (0-59) */
> >       int clk_hour;   /* hour (0-23) */
> >       int clk_mday;   /* day of month (1-31) */
> >       int clk_mon;    /* month (0-11) */
> >       int clk_year;   /* year (00-99) */
> >       int clk_wday;   /* day of the week (Sunday = 0) */
> >       int clk_yday;   /* day of the year (0-365) */
> >       int clk_dst;    /* non-zero if daylight savings applies */
> >};
> >
> >So, it looks bad at least from the internal representation of the
> >year.
> 
> It depends on what you want to call "bad".  It's quite possible
> to build a Y2K compliant system out of non-Y2K compliant
> components!
> 
> 2.11BSD's date(1) was patched for Y2K in such a way that "00" in
> the two-digit year would be interpreted as the year 2000.  (See
> patch #327 for the details.)
> 
> Would similar fixes for more historic Unices be useful to the general
> folk here?
> 
> --
>  Tim Shoppa                        Email: shoppa at trailing-edge.com
>  Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
>  7328 Bradley Blvd                 Voice: 301-767-5917
>  Bethesda, MD, USA 20817           Fax:   301-767-5927