Subject: OS/8 Date Problems

From: [email-masked] (Charles Lasner)
Date: 16 Jan 1994 11:21:52 GMT

At the request of some, here is a detailed explanation of the OS/8 Date
expiration,etc. issues:

In OS/8 V3D, the date is determined as follows:

Bits[3-4] of the c(07777) are a *8 multiplier of the base date group year
off of 1970.  Thus there are 4 possible values:

00 - 1970
01 - 1978
10 - 1986
11 - 1994

Thus, the current correct-time value for these bits is 11, the case for
1994.  This also means that the current method expires 31-Dec-2001. 
(Note: Most date printout routines throughout OS/8 are deficient in that
they will produce incorrect output past 31-Dec-1999.  This is not a
limitation of the date counting itself!)

The relative year is held separately as c(17662).  There are 3 bits for
the relative year 0-7 past the base year.  Other bits stand for the
relative day of the month, and the relative month of the year.

(Note:  A side issue regarding the date word itself is the ability to
easily compare file dates arithmetically.  In this regard, the specific
ordering of these bits was poorly chosen.  Had they been properly ordered
and weighted, it would be possible to compare dates of files directly to
find out if they are before/after some arbitrary date.  Instead, the date
words first have to be unpacked and shuffled into a proper binary
weighting scheme. 

Further, each field (other than the 3-bit year field) has many wasted
states.  Thus, the date word is only useful for exactly an 8-year period. 
Contrast this with the P?S/8 date word scheme:  Each month is assumed to
have exactly 31 days.  The day within a group is determined by multiplying
the year by 372 (12 months in a year * 31 days in a month), and adding on
31 * {relative month in the year 0-11} and adding on {relative day in the
month 0-30} to produce a relative day in that period.  Thus, the only
wasted states are for the few nonexistent days (at most days 29-31) in short
months. 

The resultant date value arithmetically compares directly for newer/older
date tests, etc. Retrieving the individual date values of year, month, day
is accomplished by simple integer division.  Additionally, the useful
range of this method is nearly 12 years.  Since the base group year is
also a multiple of 8 just as in OS/8, this means that the user can
"procrastinate" updating the system's reckoning of the base 8-year group
by nearly 4 years.)

The original design of the PS/8 date scheme was for 1970-1977 only.  The
date within a file is held in an optional "additional information" word
(AIW) in each directory entry, which the user can activate or disable when
the directory is initialized.  Some users opt to avoid file dates because
the limited capacity of the directory can cause disk space to be
inaccessible because there are many (a few hundred) small files.  This
situation is aggravated when the AIW count is increased (from none to
one), etc.  Thus, all standard utilities are written to only care about at
most one AIW word.  If only one is present, it's the date word.  In
theory, if there are more AIW words, then the first one is the date word,
and the rest are user defined. 

To avoid changing the existing flimsy scheme as much as possible, the
extension using bits[3-4] in 07777 was added in OS/8 V3.  Now the date
word is relative to an 8-year group base value which is 0-3 * 8 years past
1970.  The date of a file is actually anomalous, and is subject to being
wrong by integer multiples of 8 years.  A file's date is *presumed* to be
in the 8 year period starting January 1, seven years before the current
year and ending December 31, the current year. 

This is especially troublesome at the beginning of the year.  For example,
as of this writing in January, 1994, files created in December of 1986
appear to be created in the future!  (In December of 1994.)

A partial fix for this would be to change the reckoning to be that if the
year appears to be the current year, then in fact that's only true if the
date is today or less during this year, else the file must be actually
nearly 8 years old.  At the minimum, all date processing in all programs
has to be modified to rectify this particular point.

However, given the need to fix *something*, a better solution ought to
include extending the date in a non-anomalous way.  For starters, this
means that files have to be able to support the notion of 2 AIW values. 
If the second AIW word is present, then it should mean that the file's
exact year can be determined.  Only if a single AIW is present should the
present scheme be used (modified to avoid the rest-of-current-year
"future" anomaly for files nearly 8 years old). (And of course the total
absence of AIW words continues to mean the file is undated.)

Since the current structure supports 32 years since 1970, not too many
bits are needed to make the date last to a reasonably practical upper
limit.  This is fortunate, since finding extension bits may be
problematic. 

One plan to obtain bits currently under consideration is to modify the
contents of 07601.  Other than the incidental usage of bit[11] to
tentatively indicate the "recommendation" to search the tape starting
forwards instead of the normal reverse, bits[9-11] of this word have no
significance whatsoever. 

(Note: the bit[11] usage is meaningful only to certain tape handlers for
all calls made to the handlers, not just this specific usage in 07601
which just happens to be the function word of the call used to save memory
when a program exits by jumping to 07600.  Thus, the only consequence of
this bit set is that the save-exit will take an additional turn around as
the tape starts forward then turns around again realizing that reverse was
a better choice.  Note that unless the tape is physically rewound into the
end zone manually before the program exits, the proper choice for this
operation is certainly to start the tape search in reverse.  Additionally,
there eventually will be available "smarter" tape handlers that ignore
bit[11] and instead produce better tape motion for all calls based on an
internal reckoning of current tape position on a dynamic basis; the
current definition is only purposefully acted upon by a few specific
system handler calls where the efficiency of a forward initial search can
be statically determined.)

Bit[11] of 07601 is being considered as the ^C-abort indicator.  This
would allow programs to indicate ^C keyboard abort by setting this bit and
exiting to 07600.  (This design feature is necessary to facilitate DECmate
functionality of proper program abort exit where the DECmate keyboard
hardware is incapable of supporting the original PDP-8 ability to detect
^C abort.)

Proper design of the abort mechanism requires bit[11] only, but making
available bits[9-10] would allow a safety mechanism should the word be
accidentally incremented too many times.  (Note: as long as all programs
are consistently implemented, the safety mechanism is unnecessary.  P?S/8
has already undergone the analogous change to all system programs.  No
safety mechanism is provided, and the scheme works perfectly well, etc.)

Thus, if the modifications for ^C-abort affect only bit[11], then
bits[9-10] can be used to extend the scope of the date word by a factor of
4.  Thus, OS/8 dates could be extended to the year 2097.  Unless other
bits are located, it would appear that the best overall compromise is to
use the three low-order bits of 07601 in this manner, etc. I would
appreciate any user feedback on the wisdom of this particular set of
tentative changes to allow code to be written to carry it out!

Once the definition for these bits is stabilized, the rest of the problem
consists of modifying the DATE program to maintain them correctly, and
changing the USR and related routines to handle all AIW cases correctly. 
Any program that indicates today's date or the dates within files
according to available AIW words needs to be updated. 

Since the modification only defines two bits of the second AIW word in a
directory entry, perhaps this is a good time to tentatively define the
rest of the bits in the second AIW word.  I propose that it become the
time of day to the nearest two minutes. 

There are 720 two-minute periods in a day, thus this can be expressed in
the remaining 10 bits of the second AIW word.  The format can be all 0000
means that there is no time info in the word.  0001 means the file was
created at 00:00, 0002 means 00:02, 0003 means 00:04, 0004 means 00:06,
etc.  (Note: making a case that means time isn't available as opposed to
00:00 avoids the common anomaly of MS-DOS files in XT-class machines where
there routinely was time reckoning but no hardware clock to maintain the
actual time when the machine was unused.  Unless the user sets the time
accurately, files routinely appear to have been created shortly after
00:00 on 1-Jan-1980.  Better to indicate no time information than clearly
wrong information!)

There are various clocks for the PDP-8 that would allow for real-time
reckoning of the time (DK8E family and the CESI "ASCII" front panel
controller which includes a battery-operated CMOS clock chip are available
for the -8's.  Also, this is an obvious user-definable hardware project! 
All DECmates II and above already support the video clock in CP memory
which is accessible from OS/278 by a documentable call, etc.)  The VT78
and DECmate I always have a 100 Hz clock, as do virtually all -8/a
systems, etc.  Note: it's still the province of a user-defined program to
actually insert this information!  However, most machines at least have
the hardware to make it possible to provide time information if desired. 
Thus, we should implement the mechanism in OS/8 that makes it possible, etc.

If all of the above is completely implemented, then OS/8 file dates from
00:00 1-Jan-1970 through 23:58 31-Dec-2097 can be uniquely represented.  I
leave it to PDP-8 hackers of the 22nd century to further extend what's
discussed here! 

cjl (January 1994)