Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.dec > #218 > unrolled thread
| Started by | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| First post | 2011-04-04 09:12 -0400 |
| Last post | 2011-05-25 14:05 -0400 |
| Articles | 20 on this page of 143 — 22 participants |
Back to article view | Back to comp.sys.dec
Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-04-04 09:12 -0400
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-04-30 22:27 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-01 10:01 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-01 10:27 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-01 20:53 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-01 21:16 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-01 20:54 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-01 21:07 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-02 09:37 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-02 08:39 -0700
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-02 05:15 +0000
Re: Y3K for PDP-11 Operating Systems jjh <jjhudak@gmail.com> - 2011-05-02 18:20 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-03 08:18 -0500
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-03 12:51 -0400
VAXTREK koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-03 12:50 -0500
Re: Y3K for PDP-11 Operating Systems Henry Crun <mike@rechtman.com> - 2011-05-03 21:39 +0300
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-03 15:56 -0400
Re: Y3K for PDP-11 Operating Systems onedbguru <onedbguru@yahoo.com> - 2011-05-03 15:52 -0700
Re: Y3K for PDP-11 Operating Systems billig999@cs.uofs.edu (Bill Gunshannon) - 2011-05-04 00:07 +0000
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-04 01:16 -0400
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-04 13:01 +0000
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-04 10:19 -0400
Re: Y3K for PDP-11 Operating Systems kludge@panix.com (Scott Dorsey) - 2011-05-04 10:58 -0400
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-04 16:33 +0000
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-04 21:51 -0400
Re: Y3K for PDP-11 Operating Systems G Cornelius <cornelius@eisner.decus.org> - 2011-05-06 13:08 -0500
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-06 14:47 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@update.uu.se> - 2011-05-06 16:13 -0600
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-07 21:00 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-07 19:51 -0600
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-08 07:19 -0400
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-09 17:32 -0400
Re: Y3K for PDP-11 Operating Systems Rob Brown <mylastname@gmcl.com> - 2011-05-09 09:40 -0600
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-09 09:43 -0600
Re: Y3K for PDP-11 Operating Systems vandys@vsta.org - 2011-05-09 21:47 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-09 16:05 -0600
Re: Y3K for PDP-11 Operating Systems vandys@vsta.org - 2011-05-09 23:05 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-09 17:20 -0600
Re: Y3K for PDP-11 Operating Systems vandys@vsta.org - 2011-05-10 00:12 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-09 19:36 -0600
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-10 02:01 +0000
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 08:31 -0500
Re: Y3K for PDP-11 Operating Systems John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-10 09:56 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 12:50 -0500
Re: Y3K for PDP-11 Operating Systems G Cornelius <cornelius@eisner.decus.org> - 2011-05-11 11:04 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-04 10:02 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-04 12:20 -0500
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-04 18:10 +0000
Re: Y3K for PDP-11 Operating Systems John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-04 12:21 -0700
Re: Y3K for PDP-11 Operating Systems MetaEd <metaed@gmail.com> - 2011-05-04 15:06 -0700
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-04 20:17 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 08:20 -0500
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 08:29 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-10 09:29 -0600
Re: Y3K for PDP-11 Operating Systems G Cornelius <cornelius@eisner.decus.org> - 2011-05-10 12:16 -0500
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 12:45 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-10 15:34 -0600
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 12:58 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-10 15:36 -0600
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-03 12:38 -0400
Re: Y3K for PDP-11 Operating Systems paramucho@hotmail.com (paramucho) - 2011-05-03 11:28 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-03 12:09 -0400
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-23 03:41 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-22 21:51 -0700
Re: Y3K for PDP-11 Operating Systems jjh <jjhudak@gmail.com> - 2011-05-23 07:47 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-23 15:04 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-23 15:52 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 00:16 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-23 17:40 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 12:58 +0000
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-24 14:02 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-24 07:36 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 16:42 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-24 11:17 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 20:07 +0000
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-24 21:07 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-25 03:34 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-25 15:46 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-25 16:00 -0700
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-26 17:50 +0200
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 09:53 -0700
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-26 22:20 +0200
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-28 18:01 +0000
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-25 20:58 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-26 01:23 +0000
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-26 08:01 -0500
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-27 00:54 +0000
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-26 16:15 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-26 23:56 +0000
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-27 14:37 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-27 00:02 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 20:17 -0700
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-27 14:51 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-27 12:48 -0700
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-27 14:35 -0400
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 21:14 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-26 01:32 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-26 16:39 -0400
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-26 17:50 +0200
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-24 21:01 -0400
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-26 07:53 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 09:59 -0700
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-26 10:03 +0200
Re: Y3K for PDP-11 Operating Systems paramucho@hotmail.com (paramucho) - 2011-05-26 14:21 +0000
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-26 18:50 +0000
Re: Y3K for PDP-11 Operating Systems paramucho@hotmail.com (paramucho) - 2011-05-27 11:58 +0000
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-27 17:23 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 10:04 -0700
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-27 03:30 +0200
Re: Y3K for PDP-11 Operating Systems kludge@panix.com (Scott Dorsey) - 2011-05-26 22:17 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 20:26 -0700
Re: Y3K for PDP-11 Operating Systems John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-30 14:09 -0700
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-30 18:15 -0700
Re: Y3K for PDP-11 Operating Systems jjh <jjhudak@gmail.com> - 2011-05-31 11:02 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-31 15:54 -0500
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-31 21:37 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-24 22:59 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-25 03:51 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 08:36 -0400
Re: Y3K for PDP-11 Operating Systems "Tom Lake" <tlake@twcny.rr.com> - 2011-05-25 13:25 -0400
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 14:01 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-25 11:44 -0700
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-25 21:20 -0400
Re: Y3K for PDP-11 Operating Systems Rob Brown <mylastname@gmcl.com> - 2011-05-26 10:53 -0600
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-26 16:27 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 20:27 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-26 16:38 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 21:44 -0700
Re: Y3K for PDP-11 Operating Systems paramucho@hotmail.com (paramucho) - 2011-05-24 12:02 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-23 10:48 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-23 15:46 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 00:19 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-23 17:43 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 14:41 -0400
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-24 02:54 +0000
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 13:03 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-24 07:39 -0700
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-24 15:10 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-24 08:48 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 16:54 +0000
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-24 14:42 +0000
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 16:56 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 14:05 -0400
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| Date | 2011-04-04 09:12 -0400 |
| Subject | Y3K for PDP-11 Operating Systems |
| Message-ID | <4d99c3b6$0$23756$14726298@news.sunsite.dk> |
[Multipart message — attachments visible in raw view] — view raw
Is there any interest in extending any of the PDP-11 operating systems so that they are able to support dates at least until 3000? While my personal interest lies with RT-11, I am curious if anyone has looked at the requirements for any of the other PDP-11 operating systems to determine what is required for Y3K date support? In addition, are the resources (technical knowledge, files to make the required changes and hardware to support the development) available? For RT-11, the resources are available and I suggest a review of the required software changes by anyone who has the technical background to evaluate any proposals for Y3K implementation. If other individuals who are interested in RSX-11, RSTS/E and TSX-Plus are motivated to support Y3K implementation for these OSs, I would be interested in providing support for any solutions required to exchange dates between all PDP-11 operating systems. I am not sure if there is any commercial impact to producing Y3K code for PDP-11 OSs. However, it is possible that any current commercial use MIGHT be more likely if Y3K support is available. On the other hand, it is almost certain that any Y3K projects for all PDP-11 OSs must be done without any commercial support at this time. Consequently, as with all DECUS contributions, any actual code changes would become available to everyone. If this enhances the commercial value of the PDP-11 OSs, then it should be a positive development. Responses and suggestions are appreciated. If, as I have noted in the past there is no response, then at some point when it seems worthwhile, I shall at least present the technical details of what is required to implement Y3K for RT-11. There may also be details of other enhancements along with RT-11 bug fixes. If anyone has a wish list for RT-11 or knows of any RT-11 bugs which need fixing, I would very much appreciate the help. Jerome Fine
[toc] | [next] | [standalone]
| From | billy@MIX.COM |
|---|---|
| Date | 2011-04-30 22:27 +0000 |
| Message-ID | <ipi2br$imv$1@reader1.panix.com> |
| In reply to | #218 |
Jerome H. Fine <everyone@nospam.com> wrote:
> Is there any interest in extending any of the PDP-11 operating systems
> so that they are able to support dates at least until 3000? [...]
>
> For RT-11, the resources are available
Just curious, but what resources are these, and where are they?
> If, as I have noted in the past there is no response, then at
> some point when it seems worthwhile, I shall at least present
> the technical details of what is required to implement Y3K for
> RT-11.
Hmm. Let's pretend I didn't respond, and please present said
details.
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
[toc] | [prev] | [next] | [standalone]
| From | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| Date | 2011-05-01 10:01 -0400 |
| Message-ID | <4dbd67b3$0$302$14726298@news.sunsite.dk> |
| In reply to | #323 |
>billy@MIX.COM wrote: >>Jerome H. Fine <everyone@nospam.com> wrote: > >>Is there any interest in extending any of the PDP-11 operating systems >>so that they are able to support dates at least until 3000? [...] >> >>For RT-11, the resources are available >> >Just curious, but what resources are these, and where are they? > > The most important resource is the experience of producing a Y2K version of RT-11 based on an old release of RT-11 (well even V05.07 from 1998 is old now - I mean a release that is 10 years older than V05.07). So I know what needs to be done, have the capability and the time to do it - if I live long enough. I am confident that others have done similar things with RSTS/E, RSX-11 and RTEM-11, but if they are still working, they will not have the time to devote to Y3K. >>If, as I have noted in the past there is no response, then at >>some point when it seems worthwhile, I shall at least present >>the technical details of what is required to implement Y3K for >>RT-11. >> >Hmm. Let's pretend I didn't respond, and please present said >details. > >Billy Y.. > For RT-11, the starting point is the number of additional bits to hold the year number (actually the offset from the base year) after 2099. At present, the 16 bit word which holds the date uses 7 bits for the year and the base is 1972 CE (Commercial Events, Common Era, Christian Era or Gregorian Calendar as you prefer - all are identical, but the Phrase attached to CE can be used to specify your religious preference). The next decision concerns where to place those extra bits both in the Resident Monitor and in the entry for each file for file structured devices and how the file entry knows that the extended year is present. RT-11 will also require two additional EMT requests to Get and Set the date now that more than a 16 bit word is used for the date. I suggest that the new EMT requests include the 32 bit value for the time. Is the above information sufficient to begin with? I don't really expect an answer since your post seems to be much less than really interested. However, on the chance that you are willing to at least comment (or perhaps someone else is interested enough to notice - after almost a month since I first posted), what solution do you suggest for where the extra bits are placed in each file entry for file structured devices in RT-11? After that decision is made, along with how many bits are available, the rest of the effort is mostly just an exercise in coding - although at the same time, many extra features could be added to RT-11 and bugs could be fixed (there are still a some bugs in RT-11 which on rare occasions cause RT-11 to crash) if there was any interest from potential users. Jerome Fine
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-01 10:27 -0700 |
| Message-ID | <ipk56h$4qh$1@Iltempo.Update.UU.SE> |
| In reply to | #325 |
On 2011-05-01 07:01, Jerome H. Fine wrote:
> >billy@MIX.COM wrote:
>
>>> Jerome H. Fine <everyone@nospam.com> wrote:
>>
>>> Is there any interest in extending any of the PDP-11 operating systems
>>> so that they are able to support dates at least until 3000? [...]
>>>
>>> For RT-11, the resources are available
>>>
>> Just curious, but what resources are these, and where are they?
>>
>>
> The most important resource is the experience of producing
> a Y2K version of RT-11 based on an old release of RT-11
> (well even V05.07 from 1998 is old now - I mean a release
> that is 10 years older than V05.07).
>
> So I know what needs to be done, have the capability
> and the time to do it - if I live long enough.
>
> I am confident that others have done similar things with
> RSTS/E, RSX-11 and RTEM-11, but if they are still
> working, they will not have the time to devote to Y3K.
Sigh! I didn't want to comment, since I feel this is another non-thread
without any real relevance. But just to point out that RSX itself (when
we talk about the kernel) is good to go another 30000+ years.
Things that needs attention earlier are the file system, and of course
numerous applications that store dates in another format than what is
returned from the kernel. And at some point (atleast around the year
10.000) the date formatting routines that convert from binary to text
and so on, will probably need to be looked at.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
[toc] | [prev] | [next] | [standalone]
| From | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| Date | 2011-05-01 20:53 -0400 |
| Message-ID | <4dbe008c$0$311$14726298@news.sunsite.dk> |
| In reply to | #327 |
[Multipart message — attachments visible in raw view] — view raw
>Johnny Billquist wrote: > Sigh! I didn't want to comment, since I feel this is another > non-thread without any real relevance. But just to point out that RSX > itself (when we talk about the kernel) is good to go another 30000+ years. The primary problem with RT-11 is that the kernel (call Resident Monitor in RT-11) uses only 7 bits for the year out of 16 bits for the date value. Likewise each file entry for file structured disk drives. (I guess that all current disk drives are file structured in RT-11.) Where the extra bits go is not a problem for the Resident Monitor - probably just add on to the fixed offsets which has been done many times in the past. However, the definition of a file entry (one for each file on a file structured disk drive) has never changed, although additional bits have been defined in the 16 bits status word over the decades and there are still many bits unused (at least 6 if that is where the additional bits for the year are located). However, if another 2000+ years is added to what can be handled, another 4 bits (128 ** 4) are required and 7 bits (128 ** 7) are required to add another 30000+ years. If 30000+ years is the maximum number of years to ever be considered, then the location of those extra bits becomes easier if other interesting possibilities for RT-11 files are abandoned. At the same time, it would seem useful to add additional dates to RT-11 file entries - Modification Date, Access Date and perhaps time as well in each case. The additional words required for each file entry can easily be handled by current RT-11 software, but would required changes to the kernel if the additional words became part of the definition of an RT-11 file entry for file structured devices. > Things that needs attention earlier are the file system, and of course > numerous applications that store dates in another format than what is > returned from the kernel. And at some point (at least around the year > 10.000) the date formatting routines that convert from binary to text > and so on, will probably need to be looked at. The question of date formatting routines will probably become a secondary issue in about 2000 years. Current data strongly suggests that the rules for the current CE (Commercial Events, Common Era, Christian Era or Gregorian) Calendar will be insufficient to track the average length of the Tropical Year which is currently about 365.2418 days for the year based on the Vernal (Spring) Equinox. On the other hand, the next 2000 years are likely to see significant changes in transportation capability - all the way from FTL to stone age regression if major conflicts are not resolved. In the case of the latter sort of situation, keeping alive old software will not likely be much of a concern. It is impossible to know what effect FTL will have on society as a whole and how the calendar will change - let alone if some over eager humans decide to alter the parameters of the Earth's rotation rate, etc. The only suggestion would be to allow additional digits to be displayed in the year. Up to year 30000 (with 5 digits) would probably be the best solution to add to the software at this point and let the rule changes needed to the number of days in a year be done if someone ever decides to modify the calendar. Jerome Fine
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-05-01 21:16 +0000 |
| Message-ID | <ipkiiu$gll$2@dont-email.me> |
| In reply to | #218 |
In vmsnet.pdp-11 Jerome H. Fine <everyone@nospam.com> wrote: > Is there any interest in extending any of the PDP-11 operating systems > so that they are able to support dates at least until 3000? While my > personal interest lies with RT-11, I am curious if anyone has looked > at the requirements for any of the other PDP-11 operating systems > to determine what is required for Y3K date support? In addition, > are the resources (technical knowledge, files to make the required > changes and hardware to support the development) available? It is unlikely that either of us will be here in 2099, and every day it is less and less likely that anyone will be doing any computing after 2099, much less 3000. Not that I am against worthless computing problems, but I do wonder why. -- glen
[toc] | [prev] | [next] | [standalone]
| From | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| Date | 2011-05-01 20:54 -0400 |
| Message-ID | <4dbe00be$0$311$14726298@news.sunsite.dk> |
| In reply to | #329 |
>glen herrmannsfeldt wrote: >>In vmsnet.pdp-11 Jerome H. Fine <everyone@nospam.com> wrote: > >>Is there any interest in extending any of the PDP-11 operating systems >>so that they are able to support dates at least until 3000? While my >>personal interest lies with RT-11, I am curious if anyone has looked >>at the requirements for any of the other PDP-11 operating systems >>to determine what is required for Y3K date support? In addition, >>are the resources (technical knowledge, files to make the required >>changes and hardware to support the development) available? >> >It is unlikely that either of us will be here in 2099, and every >day it is less and less likely that anyone will be doing any >computing after 2099, much less 3000. > > While I agree that doing anything useful with a 16 bit CPU, especially within a 64 KB address space, seems unlikely to take place, there certainly seems to be ample interest in emulators that continue to extend the life of the operating system. I understand that a number of commercial RSTS/E systems continue to run under the commercial version of the Ersatz-11 emulator. In addition, the totally free SIMH PDP-11 emulator will continue to be supported for many decades even if Ersatz-11 (a 32 bit assembler program) will eventually not be able to run unless John Wilson upgrades to the 64 bit code. In addition, having working (able to execute the instruction set even if the original hardware is no longer available) examples may still be of interest in 90 years. It seems doubtful if anyone will have the interest after 2099 to modify the code, let alone the knowledge base. As for RSTS/E and RSX-11, some programs will requite modification in less than 30 years, so the work should be done now while the few people still interested and capable are around. >Not that I am against worthless computing problems, but I >do wonder why. > The first reason is probably that the problem is fun to solve. Some people solve crossword puzzles. Other do sudoku puzzles. Still others calculate the number of primes in a series of whole real numbers - I think that the range now is up to 10 ** 23, although I have not looked in over a year and it may have advanced to 10 ** 24. Perhaps we may get to finding the result up to 10 ** 100 by the end of this century. I happen to like RT-11. Perhaps I will be happier if I manage to make RT-11 Y3K compliant, perhaps not. It does not look as if anyone else is interested. Jerome Fine
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-01 21:07 -0700 |
| Message-ID | <iplal7$mll$1@Iltempo.Update.UU.SE> |
| In reply to | #331 |
On 2011-05-01 17:54, Jerome H. Fine wrote:
> >glen herrmannsfeldt wrote:
>
>>> In vmsnet.pdp-11 Jerome H. Fine <everyone@nospam.com> wrote:
>>
>>> Is there any interest in extending any of the PDP-11 operating systems
>>> so that they are able to support dates at least until 3000? While my
>>> personal interest lies with RT-11, I am curious if anyone has looked
>>> at the requirements for any of the other PDP-11 operating systems
>>> to determine what is required for Y3K date support? In addition,
>>> are the resources (technical knowledge, files to make the required
>>> changes and hardware to support the development) available?
>>>
>> It is unlikely that either of us will be here in 2099, and every
>> day it is less and less likely that anyone will be doing any
>> computing after 2099, much less 3000.
>>
>>
> While I agree that doing anything useful with a 16 bit CPU,
> especially within a 64 KB address space, seems unlikely
> to take place, there certainly seems to be ample interest in
> emulators that continue to extend the life of the operating
> system. I understand that a number of commercial RSTS/E
> systems continue to run under the commercial version of the
> Ersatz-11 emulator. In addition, the totally free SIMH PDP-11
> emulator will continue to be supported for many decades even
> if Ersatz-11 (a 32 bit assembler program) will eventually not be
> able to run unless John Wilson upgrades to the 64 bit code.
I bet RSX systems will still be around in 2099, even if they will be few.
> In addition, having working (able to execute the instruction set
> even if the original hardware is no longer available) examples
> may still be of interest in 90 years. It seems doubtful if anyone
> will have the interest after 2099 to modify the code, let alone
> the knowledge base. As for RSTS/E and RSX-11, some
> programs will requite modification in less than 30 years, so
> the work should be done now while the few people still
> interested and capable are around.
There is absolutely no need to modify RSX in 30 years. A few utilities
and tools will give problems in about 30 years (or was it 50). But we're
talking some DECnet and/or RMS stuff here. Neither of which is really
important to keep any system running, and even more, their failure modes
are pretty much harmless, and are actually not a problem or restriction
of RSX, but of the DECnet protocol specifications.
RSX will not really start having actual weird behavior that might affect
users before atleast 2099, and most likely not anything before 2155. The
problems that happen after that are mostly pretty minor as well. So this
whole thing is more or less a non-issue for RSX for now.
The first actual "bad" thing that will happen in RSX is the file system
date limitations, which is quite some way off. Also, the queue manager
date related options will eventually give problems, if you rely on that.
But even for these, we're talking so far into the future that even our
kids will not face it.
RT-11 is a different ballgame, but I do not use RT-11, and I feel it is
totally meaningless to try and bundle RT-11, RSX and RSTS/E together on
this issue. Their horizons and problems are so different that it is
pointless to try and discuss them in the same thread.
So, Jerome, feel free to continue talking about your Y3K issues in
RT-11, but leave RSX out of it. (And RSTS/E probably too...)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
[toc] | [prev] | [next] | [standalone]
| From | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| Date | 2011-05-02 09:37 -0400 |
| Message-ID | <4dbeb37f$0$305$14726298@news.sunsite.dk> |
| In reply to | #332 |
>Johnny Billquist wrote: > >On 2011-05-01 17:54, Jerome H. Fine wrote: > >> While I agree that doing anything useful with a 16 bit CPU, >> especially within a 64 KB address space, seems unlikely >> to take place, there certainly seems to be ample interest in >> emulators that continue to extend the life of the operating >> system. I understand that a number of commercial RSTS/E >> systems continue to run under the commercial version of the >> Ersatz-11 emulator. In addition, the totally free SIMH PDP-11 >> emulator will continue to be supported for many decades even >> if Ersatz-11 (a 32 bit assembler program) will eventually not be >> able to run unless John Wilson upgrades to the 64 bit code. > > I bet RSX systems will still be around in 2099, even if they will be few. Which is why I am suggesting that any date related problems be fixed now while individuals like yourself (who are VERY rare and know enough to fix the date code) are still active. >> In addition, having working (able to execute the instruction set >> even if the original hardware is no longer available) examples >> may still be of interest in 90 years. It seems doubtful if anyone >> will have the interest after 2099 to modify the code, let alone >> the knowledge base. As for RSTS/E and RSX-11, some >> programs will requite modification in less than 30 years, so >> the work should be done now while the few people still >> interested and capable are around. > > There is absolutely no need to modify RSX in 30 years. A few utilities > and tools will give problems in about 30 years (or was it 50). But > we're talking some DECnet and/or RMS stuff here. Neither of which is > really important to keep any system running, and even more, their > failure modes are pretty much harmless, and are actually not a problem > or restriction of RSX, but of the DECnet protocol specifications. > > RSX will not really start having actual weird behavior that might > affect users before atleast 2099, and most likely not anything before > 2155. The problems that happen after that are mostly pretty minor as > well. So this whole thing is more or less a non-issue for RSX for now. > The first actual "bad" thing that will happen in RSX is the file > system date limitations, which is quite some way off. Also, the queue > manager date related options will eventually give problems, if you > rely on that. But even for these, we're talking so far into the future > that even our kids will not face it. Since I don't have any detailed documentation on RSX-11 or RSTS/E, I apologize for the incorrect dates. The bottom line is that if problems will occur, why not fix them now while you can. It might be necessary to hold off with releasing the corrections for a while, but eventually I hope that all PDP-11 code will be available to at least all hobby users. > RT-11 is a different ballgame, but I do not use RT-11, and I feel it > is totally meaningless to try and bundle RT-11, RSX and RSTS/E > together on this issue. Their horizons and problems are so different > that it is pointless to try and discuss them in the same thread. Well, then I presume that I should start a new thread. However, while I don't have the ability to test under an RSX-11 system, I seem to remember that there are a few utilities which are able to pass files back and forth. I presume that these programs understand both the RSX-11 and RT-11 file systems. Likewise for RSTS/E and RT-11. These programs are the real and legitimate target of this thread and should be modified. Johnny, can you confirm that RSX-11 has such programs that pass RT-11 files back and forth between RSX-11 and RT-11? Do you know if these programs have been modified to handle RT-11 dates up to 2099? If you respond, I will do likewise on the RT-11 side of the fence. > So, Jerome, feel free to continue talking about your Y3K issues in > RT-11, but leave RSX out of it. (And RSTS/E probably too...) I understand. Except for the file exchange programs, I will attempt to avoid Y3K issues in RSX-11 and RSTS/E. In case you don't read the rest, how accurately does RSX-11 keep File Creation, Modification and Access times? Nearest Second? Nearest Tick? The file exchange programs between RSX-11 and RT-11 could be improved if the file times were available. Thus far, no one seems to be technically capable of making any comments on extending RT-11 past 2099 CE, or at least no one who is actually willing to say so on Usenet. I have not had any private e-mails either, so the few individuals who are technically aware of the RT-11 situation don't wish to become involved at this point or have other reasons which they feel prevent them from engaging in this discussion. Certainly, comments and suggestions as to how to handle the extra bits (required for the year in the entry for each file in RT-11 file structured devices) would be welcome. Does anyone who is interested require the details of the file entry data for each file? There are a minimum of seven words with 3 words (in Rad50) required for the name and file type. Currently, the file size (in blocks), file creation date and file status (a word of 16 bits with only 8 bits used) leave only one word available after the file is made permanent. TSX-Plus uses this word for the file creation time. RT-11 already has code to handle additional words in each file entry and additional words could be defined. The USR (User Service Routines) in RT-11 can easily be modified to handle any additional date and time information. I did that with one installation about 30 years ago which also ran MUBASC (Multi-User Basic) to allow the system to keep track of files which were not being accessed. I would propose adding: File Creation Time File Modification Date and Time File Access Date and Time Other essential file Information? How accurately do RSX-11 and RSTS/E keep the above file times? If there are to be changes to the file sharing programs between RSX-11 and RT-11, then the level of accuracy for the above file times would be helpful information. If RSX-11 and RSTS/E keep the times to the level of ticks, then more than 16 bits are needed. Even to the nearest second requires more than 16 bits - although seconds/2 obviously only needs 16 bits. Also, I understand that RSTS/E also has information on if a file is executable. Would that be useful for sharing between RT-11 and RSTS/E? Jerome Fine
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-02 08:39 -0700 |
| Message-ID | <ipmj7j$3ue$1@Iltempo.Update.UU.SE> |
| In reply to | #339 |
On 2011-05-02 06:37, Jerome H. Fine wrote:
> >Johnny Billquist wrote:
>
>> >On 2011-05-01 17:54, Jerome H. Fine wrote:
>>> In addition, having working (able to execute the instruction set
>>> even if the original hardware is no longer available) examples
>>> may still be of interest in 90 years. It seems doubtful if anyone
>>> will have the interest after 2099 to modify the code, let alone
>>> the knowledge base. As for RSTS/E and RSX-11, some
>>> programs will requite modification in less than 30 years, so
>>> the work should be done now while the few people still
>>> interested and capable are around.
>>
>> There is absolutely no need to modify RSX in 30 years. A few utilities
>> and tools will give problems in about 30 years (or was it 50). But
>> we're talking some DECnet and/or RMS stuff here. Neither of which is
>> really important to keep any system running, and even more, their
>> failure modes are pretty much harmless, and are actually not a problem
>> or restriction of RSX, but of the DECnet protocol specifications.
>>
>> RSX will not really start having actual weird behavior that might
>> affect users before atleast 2099, and most likely not anything before
>> 2155. The problems that happen after that are mostly pretty minor as
>> well. So this whole thing is more or less a non-issue for RSX for now.
>> The first actual "bad" thing that will happen in RSX is the file
>> system date limitations, which is quite some way off. Also, the queue
>> manager date related options will eventually give problems, if you
>> rely on that. But even for these, we're talking so far into the future
>> that even our kids will not face it.
>
> Since I don't have any detailed documentation on RSX-11
> or RSTS/E, I apologize for the incorrect dates. The bottom
> line is that if problems will occur, why not fix them now while
> you can. It might be necessary to hold off with releasing the
> corrections for a while, but eventually I hope that all PDP-11
> code will be available to at least all hobby users.
Having all source code for all software would be a nice thing, yes. But
that is also a different issue. :-)
>> RT-11 is a different ballgame, but I do not use RT-11, and I feel it
>> is totally meaningless to try and bundle RT-11, RSX and RSTS/E
>> together on this issue. Their horizons and problems are so different
>> that it is pointless to try and discuss them in the same thread.
>
> Well, then I presume that I should start a new thread.
>
> However, while I don't have the ability to test under an
> RSX-11 system, I seem to remember that there are
> a few utilities which are able to pass files back and
> forth. I presume that these programs understand both
> the RSX-11 and RT-11 file systems. Likewise for
> RSTS/E and RT-11. These programs are the real
> and legitimate target of this thread and should be
> modified. Johnny, can you confirm that RSX-11
> has such programs that pass RT-11 files back and
> forth between RSX-11 and RT-11? Do you know
> if these programs have been modified to handle RT-11
> dates up to 2099? If you respond, I will do likewise
> on the RT-11 side of the fence.
Yes. The program to read RT-11 formatted volumes under RSX is called FLX
(File exchange), and it will handle dates up to 2099.
FLX also understands DOS-11 formatted tapes, and the date limit there is
2035.
DECnet DAP protocol have a two digit year specification, and will fail
in 2069. That is a limit of DAP and will affect *all* DECnet nodes,
running any OS. The effect is rather limited, though. It will just mean
that files read over DECnet will indicate the wrong dates for files.
Nothing really bad will happen because of that.
>> So, Jerome, feel free to continue talking about your Y3K issues in
>> RT-11, but leave RSX out of it. (And RSTS/E probably too...)
>
> I understand. Except for the file exchange programs, I
> will attempt to avoid Y3K issues in RSX-11 and RSTS/E.
> In case you don't read the rest, how accurately does
> RSX-11 keep File Creation, Modification and Access
> times? Nearest Second? Nearest Tick? The file exchange
> programs between RSX-11 and RT-11 could be improved
> if the file times were available.
RSX keeps creation and modification time stamps down to a second.
There is no access time stamp.
In case you switch to using ODS-2 on RSX instead of ODS-1 (the code is
more or less already there), you instead get timestamps to the accuracy
of 100ns (if I remember ODS-2 right). Using ODS-2 will also remove the
2099 date limit that the ODS-1 file system have.
> Also, I understand that RSTS/E also has information
> on if a file is executable. Would that be useful for sharing
> between RT-11 and RSTS/E?
RSTS/E have a file protection. This is a 8-bit field. It encodes both
access rights, file executable status, and file privilege status.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-05-02 05:15 +0000 |
| Message-ID | <iplekj$8t3$1@dont-email.me> |
| In reply to | #331 |
In vmsnet.pdp-11 Jerome H. Fine <everyone@nospam.com> wrote: (snip, I wrote) >>It is unlikely that either of us will be here in 2099, and every >>day it is less and less likely that anyone will be doing any >>computing after 2099, much less 3000. > While I agree that doing anything useful with a 16 bit CPU, > especially within a 64 KB address space, seems unlikely > to take place, there certainly seems to be ample interest in > emulators that continue to extend the life of the operating > system. I understand that a number of commercial RSTS/E > systems continue to run under the commercial version of the > Ersatz-11 emulator. In addition, the totally free SIMH PDP-11 > emulator will continue to be supported for many decades even > if Ersatz-11 (a 32 bit assembler program) will eventually not be > able to run unless John Wilson upgrades to the 64 bit code. I don't see anything wrong with running a 16 but CPU as long as anyone wants. Though as far as I know, the CPU will run fine even if the date is wrong. Also, note that our current calendar has a 400 year period. If you miss by 400 years, it will even get the right day of the week. (Though by that time they might change the number of days in the week.) Though as I understand it, some strange things happen when the clock wraps. Programs that determine whether a file is new or not fail. > In addition, having working (able to execute the instruction set > even if the original hardware is no longer available) examples > may still be of interest in 90 years. It seems doubtful if anyone > will have the interest after 2099 to modify the code, let alone > the knowledge base. As for RSTS/E and RSX-11, some > programs will requite modification in less than 30 years, so > the work should be done now while the few people still > interested and capable are around. >>Not that I am against worthless computing problems, but I >>do wonder why. > The first reason is probably that the problem is fun to solve. OK, fine reason. Though usually I am happy enough to work with a system that otherwise works, but prints the wrong date. > Some people solve crossword puzzles. Other do sudoku > puzzles. Still others calculate the number of primes in a series > of whole real numbers - I think that the range now is up to > 10 ** 23, although I have not looked in over a year and it > may have advanced to 10 ** 24. Perhaps we may get to > finding the result up to 10 ** 100 by the end of this century. > I happen to like RT-11. Perhaps I will be happier if I manage > to make RT-11 Y3K compliant, perhaps not. It does not look > as if anyone else is interested. -- glen
[toc] | [prev] | [next] | [standalone]
| From | jjh <jjhudak@gmail.com> |
|---|---|
| Date | 2011-05-02 18:20 -0700 |
| Message-ID | <bdd4fd3d-bb52-43fb-ad9c-746b901f4d13@gu8g2000vbb.googlegroups.com> |
| In reply to | #218 |
On Apr 4, 9:12 am, "Jerome H. Fine" <every...@nospam.com> wrote: > Is there any interest in extending any of the PDP-11 operating systems > so that they are able to support dates at least until 3000? While my > personal interest lies with RT-11, I am curious if anyone has looked > at the requirements for any of the other PDP-11 operating systems > to determine what is required for Y3K date support? In addition, > are the resources (technical knowledge, files to make the required > changes and hardware to support the development) available? > > For RT-11, the resources are available and I suggest a review of > the required software changes by anyone who has the technical > background to evaluate any proposals for Y3K implementation. > > If other individuals who are interested in RSX-11, RSTS/E and > TSX-Plus are motivated to support Y3K implementation for > these OSs, I would be interested in providing support for > any solutions required to exchange dates between all PDP-11 > operating systems. > > I am not sure if there is any commercial impact to producing > Y3K code for PDP-11 OSs. However, it is possible that > any current commercial use MIGHT be more likely if Y3K > support is available. On the other hand, it is almost certain > that any Y3K projects for all PDP-11 OSs must be done > without any commercial support at this time. Consequently, > as with all DECUS contributions, any actual code changes > would become available to everyone. If this enhances the > commercial value of the PDP-11 OSs, then it should be a > positive development. > > Responses and suggestions are appreciated. > > If, as I have noted in the past there is no response, then at > some point when it seems worthwhile, I shall at least present > the technical details of what is required to implement Y3K for > RT-11. There may also be details of other enhancements along > with RT-11 bug fixes. If anyone has a wish list for RT-11 or > knows of any RT-11 bugs which need fixing, I would very much > appreciate the help. > > Jerome Fine Hi Jerome: To make sure I understand, y3K = 3000, it is 2011 now...um that is 989 years from now...or roughly 12.5 lifetimes....I seriously don't think that anyone in the year 3000 will want to know anything about DEC hw or sw. I can't even begin to imagine any commercial organization running RT11 in the year 3000....(hmmmm Nomad?) Computing technology will have probably undergone 4 or 5 radical technology changes. I am almost sure no one will want to learn RT-11. What for? I don't want to learn IBM 1130 assembler or PDP1 assembler for that matter. (and it has only been 40 years...) Then again, it would be interesting to see what happens if the borg assimilates a PDP11 running RT11... This does bring up an interesting issue...I have several near pristine DEC systems and I wonder who will want them in 25-30 years? I doubt any museums will be around that will showcase the stuff. I've tried to get a number of engineering students over the last 10 years to 'play' with them, and the general reaction is 'that junk? - what can I do with it...lol' In summary, I have no interest in spending time in this area. I have other types of crossword puzzles to keep me busy.... -John
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.encompasserve.org (Bob Koehler) |
|---|---|
| Date | 2011-05-03 08:18 -0500 |
| Message-ID | <RHunKDRg9aYW@eisner.encompasserve.org> |
| In reply to | #352 |
In article <bdd4fd3d-bb52-43fb-ad9c-746b901f4d13@gu8g2000vbb.googlegroups.com>, jjh <jjhudak@gmail.com> writes: > > To make sure I understand, y3K =3D 3000, it is 2011 now...um that is 989 > years from now...or roughly 12.5 lifetimes....I seriously don't think > that anyone in the year 3000 will want to know anything about DEC hw > or sw. You obviously have not read the historical documents.
[toc] | [prev] | [next] | [standalone]
| From | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| Date | 2011-05-03 12:51 -0400 |
| Message-ID | <4dc032d4$0$313$14726298@news.sunsite.dk> |
| In reply to | #360 |
>Bob Koehler wrote: >>In article <bdd4fd3d-bb52-43fb-ad9c-746b901f4d13@gu8g2000vbb.googlegroups.com>, jjh <jjhudak@gmail.com> writes: > > >>To make sure I understand, y3K =3D 3000, it is 2011 now...um that is 989 >>years from now...or roughly 12.5 lifetimes....I seriously don't think >>that anyone in the year 3000 will want to know anything about DEC hw >>or sw. >> >You obviously have not read the historical documents. > > I am curious, I have not read the historical documents. Can you please post a link? As for Y3K for RT-11, since the date is presently managed up to 2099 as of V05.07 of RT-11, dates starting in 2100 become the next problem. And since adding support only for an additional 128 years seems like a complete waste of time, then 3000 CE was chosen as the next minimum step. In practice, at least an additional 4000 years would probably be added, more than enough to handle dates until the rules for the CE (Commercial Events, Common Era, Christian Era or Gregorian - all are identical and have a 400 year cycle) Calendar requires a rule change to handle years which are less than the current 365.2418 days. So Y3K is really just Y2.1K if that makes a difference. Jerome Fine
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.encompasserve.org (Bob Koehler) |
|---|---|
| Date | 2011-05-03 12:50 -0500 |
| Subject | VAXTREK |
| Message-ID | <lsGuFDM674ze@eisner.encompasserve.org> |
| In reply to | #367 |
In article <4dc032d4$0$313$14726298@news.sunsite.dk>, "Jerome H. Fine" <everyone@nospam.com> writes: > I am curious, I have not read the historical documents. > Can you please post a link? Oh, I wish I had a link. Let me look around. Oooh, cool, found one at (URL wraps) http://www.anvari.org/shortjoke/VaxTrek/2_hi-folks-the-following-is-a-little-humour-written-by-tom-wade-of-eurokom-and-eoin-meehan-of-printech-international-plc.html you can use http://tinyurl.com/62kpfj3 Or, just use you favorite search engine and enter the keyword "VAXTREK".
[toc] | [prev] | [next] | [standalone]
| From | Henry Crun <mike@rechtman.com> |
|---|---|
| Date | 2011-05-03 21:39 +0300 |
| Message-ID | <dou598-bke.ln1@Ubuntu.mike-r.com> |
| In reply to | #367 |
On 03/05/11 20:51, Bob Koehler wrote: > >Bob Koehler wrote: > >>> In article<bdd4fd3d-bb52-43fb-ad9c-746b901f4d13@gu8g2000vbb.googlegroups.com>, jjh<jjhudak@gmail.com> writes: >> >> >>> To make sure I understand, y3K =3D 3000, it is 2011 now...um that is 989 >>> years from now...or roughly 12.5 lifetimes....I seriously don't think >>> that anyone in the year 3000 will want to know anything about DEC hw >>> or sw. >>> >> You obviously have not read the historical documents. >> >> > I am curious, I have not read the historical documents. > Can you please post a link? > > As for Y3K for RT-11, since the date is presently managed > up to 2099 as of V05.07 of RT-11, dates starting in 2100 > become the next problem. And since adding support only > for an additional 128 years seems like a complete waste of > time, then 3000 CE was chosen as the next minimum step. > In practice, at least an additional 4000 years would probably > be added, more than enough to handle dates until the rules > for the CE (Commercial Events, Common Era, Christian Era > or Gregorian - all are identical and have a 400 year cycle) > Calendar requires a rule change to handle years which are > less than the current 365.2418 days. > > So Y3K is really just Y2.1K if that makes a difference. > > Jerome Fine IIRC there was an article by someone from DEC who promised that RSTS would be patched to accept five-digit years before the year 9999. However I doubt that current versions would be supported until then... -- Mike R. Home: http://alpha.mike-r.com/ QOTD: http://alpha.mike-r.com/php/qotd.php No Micro$oft products were used in the URLs above, or in preparing this message. Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
[toc] | [prev] | [next] | [standalone]
| From | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| Date | 2011-05-03 15:56 -0400 |
| Message-ID | <4dc05df0$0$310$14726298@news.sunsite.dk> |
| In reply to | #376 |
>Henry Crun wrote: >> As for Y3K for RT-11, since the date is presently managed >> up to 2099 as of V05.07 of RT-11, dates starting in 2100 >> become the next problem. And since adding support only >> for an additional 128 years seems like a complete waste of >> time, then 3000 CE was chosen as the next minimum step. >> In practice, at least an additional 4000 years would probably >> be added, more than enough to handle dates until the rules >> for the CE (Commercial Events, Common Era, Christian Era >> or Gregorian - all are identical and have a 400 year cycle) >> Calendar requires a rule change to handle years which are >> less than the current 365.2418 days. >> >> So Y3K is really just Y2.1K if that makes a difference. > > > IIRC there was an article by someone from DEC who promised that RSTS > would be patched to accept five-digit years before the year 9999. > However I doubt that current versions would be supported until then. If I remember the code correctly, most of the subroutines which are used to display the year already handle as many digits as are required to report the year. However, as I just mentioned, the length of the Tropical Year is slowly decreasing. It is estimated that in around 4000 years (somewhere around 6000 CE), the current rules (for the Gregorian Calendar which are quite adequate to keep the CE calendar synchronized with the seasons and keep the Vernal Equinox close to March 21) will no longer apply. The number of days in a Tropical Year will gradually decline to less than 365.24 at some point and it will become necessary to drop another leap year during every 400 years. One possible choice is the current retention of the century leap year for years that are divisible by 400 (which is currently still a leap year, i.e. 2000 and 2400 are leap years). Naturally, the changes will occur slowly if nothing else changes the situation - which is probably idealistic - something always seems to occur which changes much more than is expected. In fact, if the current (probably somewhat inaccurate) estimates are correct, 4000 CE should not be a leap year. The next scheduled leap year to be dropped might be 6000 CE or 8000 CE. It all depends. After a few thousand more years when all of the remaining century leap years (which are divisible by 400) have been dropped and the number of days in a Tropical Year is less than 365.24, some other leap year will need to be chosen. I always joke that at some time in the next 2000 years, some overly capable humans may decide to increase the Earth's rate of rotation and fix the year at 365.25 days so that the Julian Calendar can be used once more. Or we may decide to eliminate the need for Calendars by other means. Whatever happens, other changes to RSTS/E will occur to keep track of the date and all other operating systems for all computers by the time five-digit years occur with regard to the CE Calendar - IF the CE Calendar is still being used. Jerome Fine
[toc] | [prev] | [next] | [standalone]
| From | onedbguru <onedbguru@yahoo.com> |
|---|---|
| Date | 2011-05-03 15:52 -0700 |
| Message-ID | <7d287cc3-4605-49a0-826e-fb92fc14e98d@j28g2000vbp.googlegroups.com> |
| In reply to | #376 |
On May 3, 2:39 pm, Henry Crun <m...@rechtman.com> wrote: > On 03/05/11 20:51, Bob Koehler wrote: > > > > > > > > > > > >Bob Koehler wrote: > > >>> In article<bdd4fd3d-bb52-43fb-ad9c-746b901f4...@gu8g2000vbb.googlegroups.com>, jjh<jjhu...@gmail.com> writes: > > >>> To make sure I understand, y3K =3D 3000, it is 2011 now...um that is 989 > >>> years from now...or roughly 12.5 lifetimes....I seriously don't think > >>> that anyone in the year 3000 will want to know anything about DEC hw > >>> or sw. > > >> You obviously have not read the historical documents. > > > I am curious, I have not read the historical documents. > > Can you please post a link? > > > As for Y3K for RT-11, since the date is presently managed > > up to 2099 as of V05.07 of RT-11, dates starting in 2100 > > become the next problem. And since adding support only > > for an additional 128 years seems like a complete waste of > > time, then 3000 CE was chosen as the next minimum step. > > In practice, at least an additional 4000 years would probably > > be added, more than enough to handle dates until the rules > > for the CE (Commercial Events, Common Era, Christian Era > > or Gregorian - all are identical and have a 400 year cycle) > > Calendar requires a rule change to handle years which are > > less than the current 365.2418 days. > > > So Y3K is really just Y2.1K if that makes a difference. > > > Jerome Fine > > IIRC there was an article by someone from DEC who promised that RSTS would be > patched to accept five-digit years before the year 9999. However I doubt that > current versions would be supported until then... > > -- > Mike R. > Home:http://alpha.mike-r.com/ > QOTD:http://alpha.mike-r.com/php/qotd.php > No Micro$oft products were used in the URLs above, or in preparing this message. > Recommended reading:http://www.catb.org/~esr/faqs/smart-questions.html#before question... who cares??? I can almost guarantee that none of us will be here in 2099... and by that time you might be using neural-net technology that will make the PDP look like a TRS80.
[toc] | [prev] | [next] | [standalone]
| From | billig999@cs.uofs.edu (Bill Gunshannon) |
|---|---|
| Date | 2011-05-04 00:07 +0000 |
| Message-ID | <92bjl8F19sU1@mid.individual.net> |
| In reply to | #378 |
In article <7d287cc3-4605-49a0-826e-fb92fc14e98d@j28g2000vbp.googlegroups.com>, onedbguru <onedbguru@yahoo.com> writes: > On May 3, 2:39 pm, Henry Crun <m...@rechtman.com> wrote: >> On 03/05/11 20:51, Bob Koehler wrote: >> >> > >Bob Koehler wrote: >> >> >>> In article<bdd4fd3d-bb52-43fb-ad9c-746b901f4...@gu8g2000vbb.googlegroups.com>, jjh<jjhu...@gmail.com> writes: >> >> >>> To make sure I understand, y3K =3D 3000, it is 2011 now...um that is 989 >> >>> years from now...or roughly 12.5 lifetimes....I seriously don't think >> >>> that anyone in the year 3000 will want to know anything about DEC hw >> >>> or sw. >> >> >> You obviously have not read the historical documents. >> >> > I am curious, I have not read the historical documents. >> > Can you please post a link? >> >> > As for Y3K for RT-11, since the date is presently managed >> > up to 2099 as of V05.07 of RT-11, dates starting in 2100 >> > become the next problem. And since adding support only >> > for an additional 128 years seems like a complete waste of >> > time, then 3000 CE was chosen as the next minimum step. >> > In practice, at least an additional 4000 years would probably >> > be added, more than enough to handle dates until the rules >> > for the CE (Commercial Events, Common Era, Christian Era >> > or Gregorian - all are identical and have a 400 year cycle) >> > Calendar requires a rule change to handle years which are >> > less than the current 365.2418 days. >> >> > So Y3K is really just Y2.1K if that makes a difference. >> >> IIRC there was an article by someone from DEC who promised that RSTS would be >> patched to accept five-digit years before the year 9999. However I doubt that >> current versions would be supported until then... >> > question... who cares??? I can almost guarantee that none of us will > be here in 2099... and by that time you might be using neural-net > technology that will make the PDP look like a TRS80. Hey, just what xfdo you think was wrong with the TRS80? bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include <std.disclaimer.h>
[toc] | [prev] | [next] | [standalone]
| From | "Richard B. Gilbert" <rgilbert88@comcast.net> |
|---|---|
| Date | 2011-05-04 01:16 -0400 |
| Message-ID | <H9mdnUTgT5LYfF3QnZ2dnUVZ_uOdnZ2d@giganews.com> |
| In reply to | #379 |
On 5/3/2011 8:07 PM, Bill Gunshannon wrote: > In article<7d287cc3-4605-49a0-826e-fb92fc14e98d@j28g2000vbp.googlegroups.com>, > onedbguru<onedbguru@yahoo.com> writes: >> On May 3, 2:39 pm, Henry Crun<m...@rechtman.com> wrote: >>> On 03/05/11 20:51, Bob Koehler wrote: >>> >>>> >Bob Koehler wrote: >>> >>>>>> In article<bdd4fd3d-bb52-43fb-ad9c-746b901f4...@gu8g2000vbb.googlegroups.com>, jjh<jjhu...@gmail.com> writes: >>> >>>>>> To make sure I understand, y3K =3D 3000, it is 2011 now...um that is 989 >>>>>> years from now...or roughly 12.5 lifetimes....I seriously don't think >>>>>> that anyone in the year 3000 will want to know anything about DEC hw >>>>>> or sw. >>> >>>>> You obviously have not read the historical documents. >>> >>>> I am curious, I have not read the historical documents. >>>> Can you please post a link? >>> >>>> As for Y3K for RT-11, since the date is presently managed >>>> up to 2099 as of V05.07 of RT-11, dates starting in 2100 >>>> become the next problem. And since adding support only >>>> for an additional 128 years seems like a complete waste of >>>> time, then 3000 CE was chosen as the next minimum step. >>>> In practice, at least an additional 4000 years would probably >>>> be added, more than enough to handle dates until the rules >>>> for the CE (Commercial Events, Common Era, Christian Era >>>> or Gregorian - all are identical and have a 400 year cycle) >>>> Calendar requires a rule change to handle years which are >>>> less than the current 365.2418 days. >>> >>>> So Y3K is really just Y2.1K if that makes a difference. >>> >>> IIRC there was an article by someone from DEC who promised that RSTS would be >>> patched to accept five-digit years before the year 9999. However I doubt that >>> current versions would be supported until then... >>> >> question... who cares??? I can almost guarantee that none of us will >> be here in 2099... and by that time you might be using neural-net >> technology that will make the PDP look like a TRS80. > > Hey, just what xfdo you think was wrong with the TRS80? > Other than primitive hardware and primitive software? It was a good machine in its day but its day is LONG GONE!
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.sys.dec
csiph-web