>Christopher Smith wrote:
> > From: Jerome H. Fine
> > As for the first bug I want to put on the list, MACRO-11 does
> > not conform to the ISO standard since it uses ONLY 2 digit
> There's an ISO MACRO-11? :)
> Chris
> Christopher Smith, Perl Developer
> Amdocs - Champaign, IL
Jerome Fine replies:
Mentec has tried to conform to the ISO standards for the display
of the date which requires that all 4 digits be used to display the
value for the year. I understand that when the bugs in RT-11 were
fixed in regard to the way the date was displayed, in all cases,
4 digits were used except for MACRO-11, i.e. the file MACRO.SAV,
which is the assembler program for RT-11, which was not modified
between the distribution for V5.06 and V5.07 and still uses only
2 digits (the low order two digits of course) for the value of the year.
The date January 1st, 1973 is displayed as: 01-Jan-73
The date January 1st, 1999 is displayed as: 01-Jan-99
The date January 1st, 2000 is displayed as: 01-Jan-00
The date January 1st, 2073 is displayed as: 01-Jan-73
The above solution is unnecessary. It is quite possible to include the
high order two digits in the year. I made the required changes in the
distribution for V5.04G of RT-11 many years ago. If anyone wants
me to do the same for MACRO.SAV in the distribution for V5.06
of RT-11, I would be pleased to do so. This exercise mainly involves
removing some of the patch since in the V5.06 distribution, the correct
low order two digits for the years between 2000 and 2099 were
already being displayed correctly. Obviously I can't do this for
hobby users, but after I get the bug list started, I will do it for
V5.03 of RT-11.
At the same time, I will probably correct another bug which seems
to be present as well - although I would need a consensus as to
whether the bug should remain due to everyone being content to
use it based on it having always been incorrect - although I may
not have understood the code correctly and could have arrived
at the wrong conclusion. I refer to the manner in which the decimal
seconds of elapsed time are displayed. I suspect they are NOT a
decimal fraction of seconds, but are the number of ticks modulo
the clock rate, i.e. for a 60 cycle clock the decimal fraction of
seconds
will always be between 0 and 59 (decimal of course). For a 50
cycle clock, the decimal fraction of seconds will always be between
0 and 49 (decimal of course). Anyone should easily be able to
verify this.
Can anyone else add to the above two bugs?
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
Received on Fri Apr 12 2002 - 22:24:01 BST