RT-11 Bug Fixes and Enhancements - DEC

This is a discussion on RT-11 Bug Fixes and Enhancements - DEC ; I am a VERY addicted RT-11 hobby user who enjoys 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 ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: RT-11 Bug Fixes and Enhancements

  1. RT-11 Bug Fixes and Enhancements

    I am a VERY addicted RT-11 hobby user who enjoys
    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'.




  2. Re: RT-11 Bug Fixes and Enhancements

    "Jerome H. Fine" writes:
    > 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

  3. Re: RT-11 Bug Fixes and Enhancements

    >Eric Smith wrote:

    >"Jerome H. Fine" writes:
    >
    >
    >>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).
    >

    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,

    Jerome Fine
    --
    To obtain the actual e-mail address, please remove
    the ten characters which immediately follow the 'at'.

  4. Re: RT-11 Bug Fixes and Enhancements

    In article <47dd1427$0$90263$14726298@news.sunsite.dk>,
    "Jerome H. Fine" 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

  5. Re: RT-11 Bug Fixes and Enhancements

    Howard S Shubs writes:

    > "Jerome H. Fine" 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.


    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.

    mlp

  6. Re: RT-11 Bug Fixes and Enhancements

    Howard S Shubs wrote:
    > 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.

  7. Re: RT-11 Bug Fixes and Enhancements

    >Eric Smith wrote:

    >Howard S Shubs wrote:
    >
    >
    >>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 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'.

  8. Re: RT-11 Bug Fixes and Enhancements

    "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.

  9. Re: RT-11 Bug Fixes and Enhancements

    >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.
    >
    >

    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

  10. Re: RT-11 Bug Fixes and Enhancements

    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. That would be equivalent to
    referring to the problems at the end of 1999 as a "Y1K problem".

  11. Re: RT-11 Bug Fixes and Enhancements

    "Jerome H. Fine" wrote:
    > >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.

    > RUN DUP DU0:/Z:6


    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.

  12. Re: RT-11 Bug Fixes and Enhancements

    >Eric Smith wrote:

    >>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

  13. Re: RT-11 Bug Fixes and Enhancements

    >Douglas A. Gwyn wrote:

    >"Jerome H. Fine" wrote:
    >
    >
    >> >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.
    >>>
    >>>

    >>RUN DUP DU0:/Z:6
    >>
    >>

    >
    >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 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

  14. Re: RT-11 Bug Fixes and Enhancements

    Eric Smith writes:

    > 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

  15. Re: RT-11 Bug Fixes and Enhancements

    >Mark L Pappin wrote:

    >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/kalend...egorian_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/kalend...ears_15K_L.pdf
    (b) 50,000 BCE to 50,000 CE
    http://individual.utoronto.ca/kalend..._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/kalend...ary_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

  16. Re: RT-11 Bug Fixes and Enhancements

    "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.

    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.

  17. Re: RT-11 Bug Fixes and Enhancements

    >Douglas A. Gwyn wrote:

    >>"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

+ Reply to Thread