>Megan wrote:
> I'm interested in what you propose, but suspect that Y10K would
> be overkill at this point. I'd like to see design discussion
> opened up for that... but it may all be moot since it wouldn't
> be compatible with V5.4, V5.5, V5.6, V5.7...
Jerome Fine replies:
Since this started in the public forum, I though I might as
well continue in this manner.
Although I responded privately to just Megan Gentry at first,
I thought that others might also be interested in contributing. In
addition, if Megan is too busy right now with her job change, then
let's get on with the design details and requirements phase.
I agree that Y10K would be overkill at this point. But
while the work for Y2K is being done for V5.03, it
would not take more than double the effort. I really do
believe that if Y10K is to be done at all, it should be
done NOW while the expertise is still around.
First, I want to say that I any bug fixes and enhancements
made to V5.03, let alone to later versions and especially
to V5.07, must be compatible with every later version
as well. Otherwise, in my opinion, there is no point in
doing them. So while some of the enhancements might never
become very popular (such as a Path Handler Device Driver)
or a SUPER extended MSCP device driver that can manage
256 RT-11 partitions at once (still need to solve many
technical problems with this one - definitely NOT a done
deal), EVERYTHING that is done to any of the older
versions of RT-11 such as V5.03 MUST also be possible
with every one of the later versions.
Also, I want to add that the changes would be made to
V5.03 of RT-11 ONLY because it is presently widely
available and licensed for use under the Supnik emulator
although it would certainly seem to be a win/win situation
to be able to make ALL of the bug fixes and enhancements
for V5.07 which could then be used by ALL hobby users
and Mentec could also freely use those enhancements and
sell them to commercial users who might just wish to purchase
V5.07 with the additional features - if some arrangement
could be found to make the bug fixes (some of the bugs
actually cause RT-11 to crash) and enhancements available
to both hobby users and commercial users.
But, based on my experience with commercial users back
about 5 years ago, none of them are interested in paying
JUST 25% of the $ US 1600 required for an upgrade to
V5.07 of RT-11. I did the Y2K upgrade to 90% of
V5.04G back in 1997 for one commercial customer,
but no one else bit. This seems to mean that every
commercial customer would rather pay the full price to
Mentec rather than one-quarter of $ US 1600 to a small
company or at least that is my personal experience.
As a result, the Y2K/Y10K bug fixes for V5.03 would
be licensed ONLY to hobby users and should, therefore,
not conflict with Mentec.
Note that while the (NOT Commented) source code
is available for RMONFB.MAC along with the rest of
the Resident Monitor, the changes made to DIR, PIP,
IND, MACRO (YES!! MACRO was done also) were
made as patches. I can't see any reason that the same
changes for V5.04G can't be backward ported to V5.03
in respect of the Y2K portion and the additional Y10K
code added at that time for both V5.03 and V5.04G of
RT-11.
> ... and it is the sort of change which would truly affect
> everything in the system, requiring sources to rebuild the
> fixes... since no-one but Mentec has rights to the sources,
> the product of any such change would be strictly illegal, so
> I am wondering how you are proposing to get around that.
As for the Y2K bug fixes, that part does not affect anything
much in the system at all - the parts that are not yet Y2K
compliant can easily co-exist with the parts that are while
the changes are slowly being made.
As for needing sources, the final product is produced in
MACRO-11 assembler, but it is then BINCOMed against
an EMPTY source file that produces, after it is assembled
and linked, a file with ALL "-1" (or some other fixed value)
if that becomes needed - has not been needed thus far)
everywhere the actual SAV file (including SAV files with
overlays - yes I ended up needing lots of dummy source
files to generate the correct overlay tables). If you have
any problems understanding, I can dig up a set I did for
LINK.
After I run BINCOM with the SAV file containing ONLY
the bug fixes against the SAV file that contains NOTHING,
the SIPP file that is produced can be run against the original
distributed SAV file that DEC (I presume that actually means
YOU in this case) produced for V5.04G to get the final SAV
file with both the original executable code and the new fixes.
As a result, NO sources at all of any kind for the original
SAV file (LINK.SAV as an example) are ever used. Of
course, if the source files ever do become available, the
source code WITH the bug fixes should be rather simple to
incorporate.
As for the Y10K part, my primary concern is that any
code and SAV files (the Monitors would need to be
first) that was capable of executing in a particular old
date range (either 1973 to 1999 OR 1972 to 2099)
would continue to be able to execute in the old date
range and provide correct results within that date range.
Finally, any directories that were produced with Y10K
compatible monitors and utilities in a date range that
could have been handled by an old monitor and SAV
files could still be handled by that old monitor and
SAV files. If a date such as 4035 CE was used, there
would still be the normal stuff and a date between 1972
and 2099 would appear if only a Y2K compatible
version of RT-11 was used instead. Plus the extra bit
in the file header would disappear if the file header
was changed or copied. On the other hand, if the
date 2063 was set up with a Y10K compatible
monitor, a Y2K compatible version of RT-11 (such
as V5.07 or a fixed V5.04G) could still manage to
CORRECTLY navigate. (see a,b,c,d,e,f,g)
Note that by initially producing a Y2K/Y10K V5.03
of RT-11 for ONLY hobby users, Mentec should have no
reason or justification to be concerned. As you suggested,
there will be some compatibility issues and it would be
MUCH easier if all hobby users had access to V5.07
of RT-11 just as all hobby users can use the latest version
of VMS on both VAX and Alpha.
I have been thinking about these goals and compatibility
problems for about two years, but no one was really interested.
So I just thought. The following aspects seem some of
the ideas that could be used:
(a) It seems BEST (it may not be necessary - your advice
on this aspect and your concurrence) to use one bit in the
SYSGEN word to signify Y10K compliance along with
a number of other enhancements
(b) Other words as required are padded to the fixed offsets
so as to be compatible with V5.07 code
(c) A single 16 bit word can be added to the fixed offsets
in the Resident Monitor area that holds the additional bits
for the top 16 bits of a 23 bit year value
(d) Other words/bytes/bits are added to the fixed offsets
as needed.
(e) KMOVLY.MAC bug fixes are made to handle both
Y2K and Y10K
(f) It seems BEST (this case seems absolutely necessary -
your advice and concurrence) to use one bit in the status
word for files to signify a Y10K file entry.
(g) For file headers on tape media, allowing for the
century byte to be defined for years up to 2999 CE
seems adequate at this point. Another few millennium
should also be possible, but eight bits is a limitation. On
the other hand, I very much doubt that the tape media
can survive, let along that tape drives will be available.
BUT tape media are not likely to survive or be used
in one hundred years. Disk drives may also not survive,
but some sort of compatibility is more likely to be built
into emulators for disk drives as opposed to tape drives.
(h) Lots of others, but this is a good start.
A few people responded to my last post and I will discuss
the details with them in respect of the Y10K bug fix. At
some point during the coding, I will post a set of the changes
which seem best suited to implement the Y10K features.
Anyone else who is interested is invited to participate either
in this forum or privately.
In addition, any bugs which anyone is aware of in RT-11,
especially ones which still remain in V5.07 of RT-11, would
be helpful to know about. They could be corrected in V5.03
of RT-11 and gradually work their way up to V5.07 in the
future.
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 Mon Dec 23 2002 - 19:03:01 GMT