🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by Kerry Kurasaki Wed, 07 Oct 1992 18:57
OS-8: Trivia Question
#25
Author: Kerry Kurasaki
Date: Wed, 07 Oct 1992 18:57
5 lines
550 bytes
Does anyone remember when the "End of the World" was for OS-8?

And what that meant?

Kerry
Re: OS-8: Trivia Question
#31
Author: Charles Lasner
Date: Thu, 08 Oct 1992 02:38
114 lines
6980 bytes
In article <1992Oct7.185715.8365@pony.Ingres.COM> kerry@Ingres.COM (Kerry Kurasaki) writes:
>Does anyone remember when the "End of the World" was for OS-8?
>
>And what that meant?
>
>Kerry

Sure, it's DEC 31 1977, the last day of the original inadequate date format.

Since then, a kludge is in effect:

The contents of location 07777 bits[3-4] represent a two-bit field where
each increment means 8 more years.  Thus the base year group is either:

1970
1978
1986
1994

depending on the two-bit quantity.  (BTW, COS-310 used the identical scheme
but starts on a different base year.)

Note that there is a typical formatting problem for 2000 and 2001 that all
systems have at end-of-century, but at least the date "survives" into the
next century a little.  Thus DEC 31 2001 is the current drop-dead date.

But the current scheme is still a kludge, since there is no info for the
determination of the actual base group year bit combination.  Thus, we can
only "drift" along with our OS/8 files.  Any long-time user knows the problem
of suddenly "new" files appearing that are actually 8 years old.  The bits
are used to *presume* the base year, since the files don't contain the needed
info to determine it.  So, all directory-oriented programs use the following:

All files are either this year or the previous 7 years.  This means that on
Jan 1 of any supported year, files that are actually 8 years old appear to
be up to a year in the future.  As the year progresses, the problem lessens
of course.  This could be re-implemented to check if the date in this year
is newer than today, thus allowing files to exist in an 8-year period ending
today, as opposed to ending on DEC 31 of this year.

There is a solution however:  The OS/8 directory structure supports the 
concept of Additional Information Words (AIWs).  The default is one AIW, and
none is occasionally used by those who need more files in the directory.  The
OS/8 directory structure is the worst of several worlds: it is a linked
structure in theory, but it is laid out sequentially, and specifically in
record 1-6 only.  The standard system cannot expand the directory, and
moreover, while there is a "correct" way to look at the directory that
uses the links and terminator, there are programs that "know better" and
deal with it as an implied monolith that just happens to be what it is.  Thus,
if it were to be changed, a lot of programs would "break".

Within the limited structure there is room for a few hundred files, the exact
number dependent on how many entries for empties there are, and whether there
are AIW words present.  Since devices can be 4096 records long, it is possible
when there are many small files to run out of directory before you run out of
physical space.  Thus, some users delete the AIW word to maximize (small) file
count.  But the first AIW word is defined as the date word, so such file
structures don't support the date concept at all.

There is no official function for any AIWs past the first one, so it could be
defined to contain the base group year bits.  This would allow an improved
system to provide accurate dates for files, at the slight additional expense of
lowering the maximum file count slightly more.  This wouldn't affect the
majority of users whatsoever.  Moreover, there have been various attempts at
subfiles, which can have their own internal conventions, and thus at least for
archival purposes, avoid that problem.

The rest of the problem is to determine at least one additional base group
year bit, which would then up the drop dead date to DEC 31 2033.  I'll look
for yet another bit to up the ante to DEC 31 2097.  I won't be around to see
how the next generation after that handles the problem.

P?S/8 solves the problem in a slightly different manner.  The base year group
is the same quantity of groups of 8 years, only starting at 1960.  Four bits
are allocated for base group years, so the last group value starts at 2080.
Most of the date printing routines are already conditioned for end-of-century
conditions, so printing of dates from 1960 through 2099 are handled correctly.

The 12-bit P?S/8 equivalent of the AIW represents 8 years worth as in OS/8, but
in a different way:

The OS/8 date word is divided into separate bit fields.  Three are for the
year, four for the month in a year, and five for the day within a month.  The
only advantage of such a scheme is that it's easy to AND off the desired bits
for a calculation.  However, the bits aren't arranged in an order that leads
to sorted dates.  (The year is in the low-order bits.)  This is unfortunate,
and we're stuck with a format where you can't do an arithmetic compare of
the binary value to determine whether a file is newer or older, and must
instead first create a binary function of the date word for such comparison.
This is part of why standard system programs only provide services such as
a directory of files with/not with today's date, etc.

The P?S/8 date word is the 12-bit value obtained by placing today in a
continuum of days derived in sequential order assuming that every month
has exactly 31 days.  Thus, each mythical year has 372 days in it.  Doing the
appropriate divide operations can isolate the year, day of the year, or day of
the week, current month, current day, etc. as needed.  Some of the operations
can make use of both the quotient and remainder.  All this means is that there
are spread throughout the values of the date word some "impossible" dates
such as February 30-31, which must be excluded by applications programs.  The
OS/8 format can have an impossible day 32 of any month, as well as a month
13-16 equally impossible, so there are actually more OS/8 cases of mythical
values to avoid.

Additionally, the actual term of the date word is not 8 years with this scheme,
rather it's about 11-3/4 years.  Thus, the date group base year needs to be
updated every 8 years as in OS/8, but you have almost 4 years to procrastinate
before actually implementing it.  The total unique date therefore lasts from
1960 through 2080 plus 11-3/4 years or sometime near the end of 2091.  Thus the
P?S/8 date scheme lasts for nearly 132 years and occupies 16 bits total.
Arithmetic compares suffice to prove whether a file is newer or older than 
any viable date.

cjl
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads