Y2K/Y10K for V5.03 of RT-11

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