Pro/Venix and Y2K

[David C. Jenner]

There probably isn't much BSD lineage in Version 1 of Venix,
but there is some in Version 2.  Probably mostly in the form
of the usual add-ons like VI.

There's some confusion about this (at least in my mind), so any
authoritative info would be interesting.

First of all there's:

"Venix/Pro" from Venturecom, which is definitely of AT&T lineage,
probably V7/SysIII for V1 of Venix/Pro, and perhaps a bit of
BSD stuff mixed in for V2 of Venix/Pro.  This is what you find at
Internet archives.

Then there's:
"Pro/Venix" from DEC, which is a repackaging of Venix/Pro.  Again,
there are Versions 1 and 2 of this.  I have V1 and docs for V2,
but no disks for V2.

I'd really like to find a copy of the distribution of DEC
Pro/Venix V2, if it's legal (and having the Ancient Unix license
would seem to make it OK for at least the AT&T side). 

For Pro/Venix, V2, the manual entry for
"clock(7) - time-of-day clock" is:

/dev/clock refers to a time-of-day, battery-backed-up clock.  This
device node is provided primarily for the benefit of the date com-
mand, which will read from it given the -l flag (usually done on
system start-up), and write to it if a new date is set.
...
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.  Since I don't have this version, I can't comment on exactly
what happens.

Dave

Tim Shoppa wrote:
> 
> The following exchange recently took place on comp.sys.dec.micro/
> vmsnet.pdp-11/alt.sys.pdp11.  In it, I made the guess that PRO Venix
> is based on 2.9BSD - does anyone know more details about its heritage?
> 
> Donato B. Masaoy III wrote:
> >
> > Came into a Pro 380 and loaded Venix as a means of tyring out Unix.
> > Noticed that at 2000 it sets itself back to 1970. Is there fix for this?
> > Should I bother?
> 
> The PRO 380 Time-Of-Year clock has two modes:
> 
> 1.  BCD mode, where the year is stored in two decimal digits.
> 2.  Binary mode, where the year is stored as at least 7 bits (more
>     likely 8 bits - it's been a couple of months since the changes
>     were implemented the fix in RT-11's PI.SYS, PIX.SYS, and
>     SETUP.SAV to make it Y2K compliant.)
> 
> When in BCD mode, 31-Dec-99 rolls over into 1-Jan-00, and the
> clock keeps accurately ticking.  Venix evidently chokes on this
> and doesn't interpret "00" as "2000".
> 
> As Unix is incapable of representing times internally outside
> the range 1970-2038, the obvious fix is to interpret BCD years
> in the range 70-99 as being in the 1900's, and the BCD years
> in the range 00-38 as in the 2000's.  This is, for example,
> how BSD2.11 interprets the two-digit 11/93 or 11/94 clock year.
> 
> Of course, finding the sources to Pro 380 Venix to implement
> the changes may be difficult.  The PUPS archive has a version of 2.9BSD
> patches for the Pro, and if you're lucky Venix may be close
> enough that you can use the Pro-specific clock sources to patch
> your kernel binary.  In the 2.9BSD Pro patches, the clock
> code is in "/sys-dev/prostuff.c", and begins:
> 
> /* These two fuctions handle the pro 300's clock
>  * This code is defunct at the end of the century.
>  * Will Unix still be here then??
>  */
> 
> --
>  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

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA22497
	for pups-liszt; Fri, 27 Nov 1998 06:05:10 +1100 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)