RT-11 Bug Fixes and Enhancements
Jerome H. Fine
the challenge of fixing bugs in the RT-11 operating
system as well as producing enhancements. Is there
anyone who reads this who would find them useful, let
alone anyone who would want to share in at least
defining what is done and how?
One of my long term goals will be a Y9K set of bug
fixes. I also have a preliminary version of an LL:
(Logical Lookup List device driver), patches for
2 serious bugs that crash RT-11 and Y2K bug fixes
for many of the RT-11 utilities - including MACRO,
DIR, PIP, BUP, LINK, LIBR and IND.
Finally, I just found a server which accepts posts
for comp.sys.dec and comp.sys.dec.micro, but NOT
for alt.sys.pdp11 nor vmsnet.pdp-11 at this point.
Are there any servers who do not charge and accept
posts for these 2 latter newsgroups? Obviously,
a server which accepts text only messages is quite
acceptable as is a server which is WRITE ONLY for
these 2 newsgroups since there are a number of READ
ONLY newsgroups for text only posts - including the
latter 2 newsgroups which I already monitor.
I guess that if someone would agree to forward my
posts to the latter 2 newsgroups, that would also
be just as helpful.
Jerome Fine
--
To obtain the actual e-mail address, please remove
the ten characters which immediately follow the 'at'.
Eric Smith
> One of my long term goals will be a Y9K set of bug
Do you mean Y10K? Why would there be a Y9K problem?
I'm certainly interested in bug fixes and enhancements,
but calendar fixes beyond Y2038 aren't of that much
interest (yet).
Eric
Jerome H. Fine
Jerome Fine replies:
(a) The 1998 CE release of V05.07 of RT-11 was almost completely
Y2K compliant. About the only utility that does not use 4 digit
years is MACRO, although the last 2 digits of the year are now
correct. This aspect can easily be fixed.
(b) V05.07 of RT-11 will be able to keep track of the year until 2099 CE.
(c) V05.03 of RT-11 which Mentec allows for hobby use can be easily
(well it depends on who is making the changes) made Y2K compliant
and able to handle years up to 2099 CE.
(d) If it is not done soon, I doubt that there will be anyone sufficiently
able and interested to make any changes to RT-11 software.
(e) After 2099 CE, the date value (a 16 bit word) has no more bits
available. Since adding additional bits to hold years beyond 2099 CE
will be a major modification, it seems reasonable to add a full 16 bit
PDP-11 word - and at the same time allow for the time to also be added
to each file directory while a date word is being added - and at the
same time
allow, in addition to the creation date / time of each file, at least
the modification
date / time. Comments would be appreciated on this proposal!
(f) The current Common Era (aka Gregorian) Calendar will likely require
at least minor modifications and adjustments to the RULE BASED
use of the leap day every 4 years (except for century years not divisible
by 400) sometime during the next 4000 years. It is possible that some
overly capable humans may decide to "fix" the Tropical Year (currently
around 365.2422 days - which is a bit shorter by 25.92 seconds than
the 365.2425 days of the average year of the CE Calendar) so that
no modification will be required. Since it will take around 3000 years
before one of the leap days needs to be dropped, there is plenty of
time. However, if no "fix"es are made, then after around 4000 years,
the current estimates suggest that only minor modifications may no
longer be sufficient. Consequently, I figure that until there is more
information available, the year 9999 CE is quite sufficient as the current
goal - i.e. a Y9K bug fix will be sufficient for now.-);
(g) Another question is if anyone else is interested in a Y9K version
of RT-11 as noted by the fact that Eric Smith was the only person
who posted a reply! Anyone else waiting to prove me wrong?
Sincerely yours,
Howard S Shubs
"Jerome H. Fine" <jhfin...@dp3knospamcompsys.to> wrote:
> Consequently, I figure that until there is more
> information available, the year 9999 CE is quite sufficient as the current
> goal - i.e. a Y9K bug fix will be sufficient for now.-);
That's known as the Y10K problem. That's why you're confusing people.
--
While its true that "you can't fix stupid", apparently you
can package it up and sell it. -- fnorgby on TMBO
Eric Smith
> That's known as the Y10K problem. That's why you're confusing people.
Mark L Pappin wrote:
> People including you, obviously.
> Not supporting dates after 9999 CE is the Y10K problem.
> Adding support for dates after 9999 CE would be the Y10k bug fix.
> Adding support for up to but not after 9999 CE is the Y9K bug fix.
According to whom?
Logically, a "Y9K" bug fix would be a fix for a bug causing dates after
the year 8999 to have problems. I've never heard of a system having a
known problem of that nature.
The next date problems that are most commonly expected are:
Y2038 problem: 32-bit unix time goes negative.
Y2069 problem (should really be Y2070): some systems use an RTC chip with
a two-digit year, and offset that with an origin of 1970.
Y2100 problem: there are STILL systems with two-digit years, that may
fail after 2099. Also, 2100 is not a leap year, which will cause a
problem for systems with poorly-written leap year code.
Y2106 problem: 32-bit unix time wraps around completely (even if unsigned)
Y3K (Y3000) problem: hypothetical, for systems with three-digit years. It
would be nice to think that people wouldn't have solved the Y2K or Y2100
problems by adding only a single digit to the year, but I wouldn't bet
on it.
Jerome H. Fine
Jerome Fine replies:
Since your list starts with a unix problem followed by an RTC problem,
you might
consider looking more closely at RT-11 which is the target or goal of
the bug fixes
and enhancements that I have chosen.
If you completely accept the above paragraph, then please read further.
If not, then
I suggest that you do not bother since we will be looking at two
completely different
problems.
With regard to dates between 8999 and 9999, please carefully read (f)
below to
understand that changes to the Calendar may be required which probably
can't be
predicted at present - which is why you have not heard of any problems
for those
years - but it may be possible to define a range of possible solutions
so that a table
can be set up to allow for future changes to a modified Common Era
Calendar which
minimizes the drift just as changes between the Julian Calendar and the
Gregorian
Calendar minimized the drift in 1582 AD.
As I have noted before, I have not found anyone else interested in
fixing bugs and
making enhancements to RT-11, so I suggest that if it is not done now,
it may never
be done. As far a bug fixes are concerned, there are at least two which
cause RT-11
to crash and many others which are annoying. As for enhancements, there
are many
already available for hobby use, but it seems that most individuals
interested in the
PDP-11 just want to use the hardware as opposed to the software.
(a) Prior to V05.07 (released by Mentec almost 10 years ago in 1998),
most versions
of RT-11 (and specifically the official versions released by DEC) were
able to handle
years from 1973 to 1999. This included V05.06 released by DEC in 1992
even though
some other operating system for the PDP-11 were being made Y2K compliant
and the
extent of the effort to make V05.06 fully Y2K compliant would have been
much less
than the extra work to move from V05.05 of RT-11 to V05.06 of RT-11.
(b) Since I was requested to produce a Y2K compliant version from
V05.04G of RT-11,
I have a fairly good estimate of just how much effort was needed to make
V05.06 of RT-11
Y2K compliant. For example, MACRO.SAV requires about a dozen
instructions. Other
utilities require more, but the job is not that difficult.
(c) A Y2K compliant version of RT-11 easily handles all dates from 1972
to 2099 by using
2 extra bits in the date value to add an additional 96 years from 2003
to 2099 - which the
original RT-11 was able to handle, but did not have the code to display
from 2000 to 2003.
V05.07 of RT-11 is able to handle ALL years from 1972 to 2099 which
means that the
next date which requires changes is 2100.
(d) I have requested suggestions in respect of the extra capacity
required for dates in RT-11
beyond 2099, but have not received a response. The usual answer is that
we will not be
around to see the problem, so let someone else think about and fix it.
(e) As soon as there is even just one more bit allocated in RT-11 for
additional years beyond
2099 (and probably a complete 16 bit word is obviously far more
reasonable rather than doing
the job one step at a time), the storage location is the only serious
problem. Fortunately, RT-11
already has that aspect well in hand for file directories, the only real
question being how to notify
the programs that the storage location is being used. I propose to
address this question by using
a single bit in an appropriate location to specify that the required
storage location is present at a
pre-defined address (one address in the fixed offsets and a second
address or actually offset in
the words used for each file label in file directories) so that the year
field is then expanded from
7 bits to 23 bits. I further propose that the use of the extra 16 bits
be defined in a manner which
results in the current 7 bits being unchanged for the years 1972 to 2099
and that all current versions
of RT-11 be able to run as is for years for which they are designed with
the understanding that
a Y9K compliant version of RT-11 be able to handle dual or mixed use
(with regard to the date)
file directories.
(f) The other rather even more nasty problem is that the rule based
Common Era (aka Gregorian)
Calendar has a non-zero drift over the next few thousand years which may
dramatically increase
after about 4000 years around 6000 CE. Should there be adjustments to
the rules to keep the
drift to less than a day or two, then it is likely that within about
2000 years, the rules about which
years have a leap day are most likely to see 4000 CE NOT be a leap year
- all current data being
applicable. This assumes that global warming does not change the
rotational period of the Earth
sufficiently to cause significant (one day every 400 years would be
extremely significant) changes
in the number of days per year which is currently approximately 365.2422
days for the Mean
Northward Equinoctial Year (to specify just one of the many possible
average values for the
length of a year). The rule based (i.e. observations are not used)
Common Era Calendar is
exactly 365.2425 days per year (= 365 97/400) since every fourth year is
a leap year except
century years which are not evenly divisible by 400. This causes a
drift of about one day per
3000 years. How this problem will be resolved in the future need not be
addressed right now,
but perhaps it might be at least possible to consider the options before
there is the actual need
to address the problem. In any case, and whatever the solution, this
paragraph is the reason
that I see no point in a Y10K solution. Y9K will be more than
sufficient for RT-11 until the
questions addressed by this paragraph are considered and at least
partially resolved although
if the length of the year remains at least 365 days, it may be possible
to add the the rules and
set up a table for future years if the changes are clearly defined.
I would appreciate comments on these RT-11 proposals for a Y9K compliant
version of RT-11
which specifically address the above (a) through (f), but not limited to
them.
Sincerely yours,
Jerome Fine
--
To obtain the actual e-mail address, please remove
the ten characters immediately following the 'at'.
Douglas A. Gwyn
> (e) After 2099 CE, the date value (a 16 bit word) has no more bits
> available. Since adding additional bits to hold years beyond 2099 CE
> will be a major modification, it seems reasonable to add a full 16 bit
I urge against this, except in the form of newly added service requests.
Otherwise, changing binary formats would certainly cause problems for
new code that may access old files.
Jerome H. Fine
Jerome Fine replies:
Fortunately, RT-11 does NOT require any new service requests in this
regard. And no
binary formats require any changes of any kind!
For the devices which support a file structure, each file uses a minimum
of seven words.
INIT DU0:
or
RUN DUP DU0:/Z
or
RUN DUP DU0:/Z:0
all set up a file structure with the seven word minimum.
There are many bits available in the status word (not including the
READ ONLY bit
which is active starting with V05.06 of RT-11, but not easily displayed
or modified
since it is not supported by either DIR or PIP, although the resident
monitor code is
present) which may be used to specify that the word used by the .Enter
request is
now the extra date value - although TSX-PLUS uses that word for the file
creation
time. My preference would be to also allow 2 words for the file
creation time and
also add 4 more words for the file modification date / time as an option
if the
user requests that there be 6 additional words in the file directory
which would then
be used for that purpose. Since the RT-11 command:
RUN DUP DU0:/Z:6
initializes a directory on DU0: with 6 extra words for each directory
entry, that aspect
(setting up extra words in each directory entry) is already present in
RT-11.
A single (currently unused) bit at the SYSGEN offset may be used to
specify that the
fixed offsets in the resident monitor contains the extra date value.
Activating the use of the READ ONLY bit would be a reason to add a
service request
in the same manner as the PROTECT bit has its own service request.
Since there already
is a service request for the file date, no new service request for the
file creation date is
required.
YES!! Requesting the date (.Date) and setting the date would require
new (modified?)
service requests.
Sincerely yours,
Jerome Fine
Eric Smith
> Adding support for up to but not after 9999 CE is the Y9K bug fix.
I wrote:
> According to whom?
[list of calendar problems omitted]
Jerome H. Fine wrote:
> Since your list starts with a unix problem followed by an RTC
> problem, you might consider looking more closely at RT-11 which is
> the target or goal of the bug fixes and enhancements that I have
> chosen.
I wasn't criticizing anything you've done or proposed. I'm disputing
the idea (apparently promoted by Mark) of referring to a calendar
problem that occurs at the end of the year 9999 (or anywhere else
within that year) as a Y9K problem. That would be equivalent to
referring to the problems at the end of 1999 as a "Y1K problem".
Douglas A. Gwyn
> >Douglas A. Gwyn wrote:
> >"Jerome H. Fine" wrote:
> >>(e) After 2099 CE, the date value (a 16 bit word) has no more bits
> >>available. Since adding additional bits to hold years beyond 2099 CE
> >>will be a major modification, it seems reasonable to add a full 16 bit
> >>PDP-11 word ...
> >I urge against this, except in the form of newly added service requests.
> >Otherwise, changing binary formats would certainly cause problems for
> >new code that may access old files.
But existing programs don't know about this. They make monitor service
calls to get information about files. If there is any change in the way
that file information is encoded, they won't know about it and will do
the wrong thing. That is why any changed service call interface needs
to use a different subcode number taken from the set of those not used
with standard RT-11.
Jerome H. Fine
>>Jerome H. Fine wrote:
>
>
>>Since your list starts with a unix problem followed by an RTC
>>problem, you might consider looking more closely at RT-11 which is
>>the target or goal of the bug fixes and enhancements that I have
>>chosen.
>>
>I wasn't criticizing anything you've done or proposed. I'm disputing
>the idea (apparently promoted by Mark) of referring to a calendar
>problem that occurs at the end of the year 9999 (or anywhere else
>within that year) as a Y9K problem. That would be equivalent to
>referring to the problems at the end of 1999 as a "Y1K problem".
>
>
Jerome Fine replies:
Actually, I appreciate the feedback since it provided me with something to
explain.
As for the exact vocabulary used, the actual question of Y9K or Y10K
is probably not important since at the present time, there is insufficient
information about the modified rules which will be needed by the Common
Era (aka Gregorian) Calendar to keep the drift between the observed
date of the Equinox and the March date for the start of spring from
becoming too large. From what I have been able to understand, after
about 4000 years, the number of days in the year is likely to decrease
at a faster rate than at present. In addition, no one is able to take into
account the possible effects of melting in the Antarctic which will shift
large masses of water toward the equator - which should also slow
the Earth's rate of rotation.
It also seems clear that there is really very little interest at this
time in dates
after 2099, let alone fixing other bugs and making enhancements in RT-11.
Sincerely yours,
Jerome Fine
Jerome H. Fine
Jerome Fine replies:
I am not really sure what you are attempting to state. As far as I
can understand, we agree in every aspect.
I appreciate your persistence. Are you saying that after 2099,
programs which attempt to set or retrieve the date will get data
which is incorrect since they will be using requests which involve
only a single 16 bit word rather than two 16 bit words? If so, that
seems so obvious to me that I had not even considered it to be a
factor. Naturally, I will not be using the same subcodes for a monitor
service call if the size of the date changes. In fact, the EMT request
which provides the date in R0 can't be used at all since two words
will be needed.
Perhaps the only part that I have omitted is that where possible,
current programs should be able to run using files set up by the
new operating system code and / or the utilities until 2099. This
will be possible because the value of the low order 16 bits of
the new date word (which will become a 32 bit quantity) will be
identical to the old 16 bit data value for the same dates which
are allowed to be from January 1st, 1972 to December 31st, 2099.
Assuming that the high order new date word is non-zero, this will
allow RT-11 to work with dates prior to 1972, an aspect that was
also lacking up to now. Please comment on this possibility. As
long as adding a second (high order) word allows for dates prior
to 1972, I see it as positive to implement a proleptic Common
Era (aka Gregorian) Calendar - the only question is how far back
would possibly be useful?
Have I addressed your concerns?
Sincerely yours,
Jerome Fine
Mark L Pappin
> Mark L Pappin wrote:
>> Adding support for up to but not after 9999 CE is the Y9K bug fix.
>
> I wrote:
> > According to whom?
> [list of calendar problems omitted]
>
> Jerome H. Fine wrote:
>> Since your list starts with a unix problem followed by an RTC
>> problem, you might consider looking more closely at RT-11 which is
>> the target or goal of the bug fixes and enhancements that I have
>> chosen.
>
> I wasn't criticizing anything you've done or proposed. I'm
> disputing the idea (apparently promoted by Mark) of referring to a
> calendar problem that occurs at the end of the year 9999 (or
> anywhere else within that year) as a Y9K problem.
I didn't promote that idea (and indeed would dispute it also), but
merely tried to explain what I saw as Jerome's terminology having been
misunderstood by you.
What I saw was the use of "Y9K bug fix" as an imaginative way to say
"add support for dates way beyond the current upper limit", but others
such as you did not see this meaning. Since Jerome explicitly stated
that years beyond 9999 would not be supported by this new scheme, it
seemed obvious to me that there was no attempt to address the "Y10K
problem".
Jerome's later posts make it clear to me that he had not in fact
intended "Y9K bug fix" to be interpreted as the witticism I saw.
> That would be equivalent to referring to the problems at the end of
> 1999 as a "Y1K problem".
Um, no it wouldn't.
mlp
Jerome H. Fine
>I didn't promote that idea (and indeed would dispute it also), but
>merely tried to explain what I saw as Jerome's terminology having been
>misunderstood by you.
>
>What I saw was the use of "Y9K bug fix" as an imaginative way to say
>"add support for dates way beyond the current upper limit", but others
>such as you did not see this meaning. Since Jerome explicitly stated
>that years beyond 9999 would not be supported by this new scheme, it
>seemed obvious to me that there was no attempt to address the "Y10K
>problem".
>
>Jerome's later posts make it clear to me that he had not in fact
>intended "Y9K bug fix" to be interpreted as the witticism I saw.
>
Jerome Fine replies:
I thought that more information concerning the problems associated with the
implementation of any Y9K compliant software might help to clarify the
situation.
I subscribe to a list which enjoys looking at attempts to make changes
to the
calendar. Many of the individuals are EXTREMELY capable astronomers
who are able to understand the extremely complex relationships which result
in the orbits of the planets around the sun along with the spin of the
Earth about
its axis.
The current Common Era (aka Gregorian) Calendar which was first used
in 1582 introduced a modified set of rules to stop the drift of the Julian
Calendar which had then been in use for about 1600 years. In 1582, the
accumulated drift was over 10 days, i.e. the Northward Equinox which
was supposed to occur on about March 21st each year was late by about
10 days each year due to the rules used by the Julian Calendar. The new
modifications to the rules were probably just about the minimum required
at the time and, as many of us are aware, dropped 3 leap days out of every
400 years, specifically the leap days for the century years which are not
evenly divisible by 400. So, in the recent past, the years 1700 CE, 1800 CE
and 1900 CE were not leap years, i.e. they did not include a February 29th.
On the other hand, 2000 CE did include a February 29th, as will 2400 CE,
2800 CE, etc. while 2100 CE, 2200 CE, 2300 CE, 2500 CE, etc. will not
include a February 29th.
The difficulty is that these rules for the Common Era Calendar result in
a year
with exactly 365.2425 days while the actual Northward Equinoctial year
has only
about 365.2423 days. Over the next 8000 years, this will again result
(if no new
modifications are implemented to the current Common Era Calendar) in a drift
of when the Northward Equinox occurs. However, because the drift is so
small,
it will be around 4000 CE that a change needs to be made to the rules -
and even
then, the drift will still be less than a day. Or at least, that is the
best current
estimate. A discussion of "Why March 21st?" can be found at:
http://www.sym454.org/mar21/
http://individual.utoronto.ca/kalendis/mar21.htm
Within this link, and much more interesting, are two graphs which
provide the
"Gregorian Calendar Date at the Astronomical March Equinox" or the dates of
the Common Era Calendar when the Northward Equinox occurs. The graphs
provide the dates from 1582 CE up to 2400 CE followed by the dates from
1500 CE up to 8500 CE:
http://individual.utoronto.ca/kalendis/equinox/Gregorian_ME.pdf
There is another page which provides other information which is also
very interesting.
The Length of the Seasons is at:
http://individual.utoronto.ca/kalendis/seasons.htm
Contained with in this page are links to the Graphical Analyses of the
Length of the
Solar Year which includes a number of graphs. For my purposes, the
three most
useful graphs are the Mean Equinoctial and Solstitial Year Lengths at:
(a) 10,000 BCE to 15,000 CE
http://individual.utoronto.ca/kalendis/solar/Mean_Solar_Years_15K_L.pdf
(b) 50,000 BCE to 50,000 CE
http://individual.utoronto.ca/kalendis/solar/Mean_Solar_Years_50K.pdf
(c) Uncertainties due to the Slowing Earth Rotation Rate
Mean Northward Equinoctial Year Length, with varying Delta T rates
http://individual.utoronto.ca/kalendis/solar/EqSolst_Years_vary_DeltaT.pdf
The last three graphs show that until about 30,000 CE, the estimated
length of the
year will likely be longer than 365.24 days. On the other hand, if
other unanticipated
factors reduce the Rotation Rate of the Earth MUCH more quickly, then it is
conceivable that the length of the year could fall below 365.24 days as
early as
10,000 CE. The reason that I have chosen 365.24 days is because the rule
changes required to prevent drift between the actual date of the Equinox and
a fixed date such as March 21st will be the complete elimination of leap
days
for ALL century years, including century years divisible by 400. Note that
even dropping the one century year divisible by 400 will probably not be
required
until at least 4000 CE (at least that is the most probable current best
estimate);
consequently, the rules for the current Common Era (aka Gregorian) Calendar
rules should not require any changes for a VERY long time.
However, by 10,000 CE, it is almost certain that some modification to the
rules will be required to reduce the drift - if that is considered to be
an important
aspect to the humans who live at that time and many other factors, which are
obviously impossible to predict at this point, remain the same.
If you have read all the way to the end and looked at the charts, do you now
understand why I chose Y9K as the next goal?
Comments would be appreciated, especially comments which provide for a
possible resolution of the problem. I have considered one solution which is
a table of the years in which the extra leap day of February 29th is dropped
since up until 10,000 CE, there should be very few. The table could be
updated as required when and IF it ever becomes an adopted fact. The
key point is that once the code to use the table is in place, changes to
the rules may be very arbitrary, but could still handled at least until
the length
of the year is less than 365 days - assuming that the basic current Common
Era Calendar is retained in its present form as basically was been done when
the rule changes were made to the Julian Calendar to produce the Gregorian
Calendar, i.e. (other than the changes made when implementation occurred
along with the days which were dropped when the Gregorian Calendar
first became active,) the rule changes for leap years specified that the
three
century leap years in the Julian Calendar which are not evenly divisible by
400 were no longer leap years in the Gregorian Calendar. For a future
modified
Common Era Calendar, the first rule change may be to eliminate leap years
which are evenly divisible by 4000. However, based on the graphs which have
the above links, a rule may not be possible. A table driven list of
leap years
which have been eliminated might, therefore, be the way that these future
problems can be handled right now insofar as the code is concerned for
applications which are unlikely to have individuals who are interested, let
alone are capable, of making any changes in the future - the future being
10,000 CE.
Sincerely yours,
Jerome Fine
Douglas A. Gwyn
>> It also seems clear that there is really very little interest at this
> time in dates
> after 2099, let alone fixing other bugs and making enhancements in RT-11.
I think you're drawing unwarranted conclusions.
I'm pretty sure that participants in these newsgroups don't expect to
be personally affected by the behavior of RT-11 programs after 2099.
Some of us presumably don't want a "bug fix" that introduces new problems.
If there are still some important applications based on RT-11, those
users could tell you what improvements are really needed. I suspect
that there are very few if any such applications remaining. My own
use of RT-11 is primarily under the SIMH simulator (extended with a
VS60 implementation that Budne and I developed) and with actual old
hardware, which doesn't really need new device support. There is
essentially *no* good reason to develop *new* applications for RT-11.
Jerome H. Fine
>>"Jerome H. Fine" wrote:
>
>
>>>It also seems clear that there is really very little interest at this
>>>
>>>
>>time in dates
>>after 2099, let alone fixing other bugs and making enhancements in RT-11.
>>
>>
>
>I think you're drawing unwarranted conclusions.
>
>
Jerome Fine replies:
Based on the number of individuals who are participating in this thread,
I am fairly
confident that no one else will reply to prove me incorrect. And it
seems that your
last sentence actually confirms my above statement about "very little
interest".
Please explain if I misunderstood.
>I'm pretty sure that participants in these newsgroups don't expect to
>be personally affected by the behavior of RT-11 programs after 2099.
>
>
While your statement is obvious, that was exactly the reason why Y2K became
such a problem in the first place - well maybe some companies were hoping to
make a huge easy profit in 1999.
For once, maybe it would be useful to write the code well before it is
actually needed -
or even just in case? I have heard that VMS has been tested for both
Y3K and Y4K,
but probably not beyond. Since you mention SIMH below, I can actually
hope that
VAX emulation running VMS may actually continue to at least Y3K. Would
it not
be reasonable to also have RT-11 be able to do the same?
>Some of us presumably don't want a "bug fix" that introduces new problems.
>
>
I am not sure why you are making such a blanket statement. As an
example, V05.05 of
MACRO.SAV in RT-11 requires about ten more instructions to display the 4
digit year from
1972 to 2099 rather than the last 2 digits of the year from 1973 to
1999. It is almost trivial
to make sure that the code is correct by stepping through those extra
instructions for a few
sample years. And since the current code for V05.05 actually causes
MACRO.SAV to fail to
execute under some conditions in 2008, an appropriate "bug fix" is
surely worth the effort.
The same instructions changes are probably needed for V05.03b of
MACRO.SAV, just
with a different offset for the SLP file. Incidentally, V05.03b of
MACRO.SAV is used in
V05.03 of RT-11 which is allowed under SIMH for hobby use. Does anyone
want me
to figure out the SLP file? Not very useful, of course, unless the rest
of V05.03 of RT-11
is also made Y2K compliant!
There are 3 code mistakes in RT-11 (KMON, Resident Monitor and a device
driver)
which crash RT-11 under certain conditions. While they rarely occur
(the most likely
reason they have not been detected by many), they also require very few
instructions
to correct.
And then there are the bugs which result in incorrect values most of
which require only
an additional instruction or two - in some cases just changing the order
of instructions.
And then it would be "nice" to be able to have the code in DIR.SAV and
PIP.SAV
to handle READ ONLY files, i.e. to display and toggle the READ ONLY status
since the Resident Monitor already has the 3 extra instructions to
prevent writing
to a file with that status. It really is inconvenient using SIPP.SAV to
do that.
>If there are still some important applications based on RT-11, those
>users could tell you what improvements are really needed. I suspect
>that there are very few if any such applications remaining. My own
>
>
Fire away - does anyone have any requests?
>use of RT-11 is primarily under the SIMH simulator (extended with a
>VS60 implementation that Budne and I developed) and with actual old
>hardware, which doesn't really need new device support. There is
>essentially *no* good reason to develop *new* applications for RT-11.
>
I actually agree in respect of "*new* applications", although in some
cases I see the challenge
as being rather interesting.
But the "Subject: RT-11 Bug Fixes and Enhancements" is not about that.
Can you honestly
say that fixing a few bugs and adding a few enhancements to SL: (Single
Line Editor) would
not be useful? Well, not if you don't use the SL: - which in SIMH is a
bit difficult as opposed
to Ersatz-11 which has VT100 emulation built in (in addition to being up
to ten times as fast
as SIMH).
Actually, since you did mention SIMH, how difficult might it be to also
emulate the HD: device
that John Wilson has in Ersatz-11? If I made the modifications to the
RL and / or RK device
code, might anyone help with the debug phase?
Sincerely yours,
Jerome Fine