Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.vms > #2657 > unrolled thread

Re: Y3K for PDP-11 Operating Systems

Back to article view | Back to comp.os.vms

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-03 12:51 -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 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
              [OT] Architectures, was: Re: Y3K for PDP-11 Operating Systems Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2011-05-04 17:23 +0000
              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

Page 1 of 3  [1] 2 3  Next page →

#2657 — Re: Y3K for PDP-11 Operating Systems

 >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] | [next] | [standalone]

#2658

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]

#2662

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]

#2664

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]

#2665

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]

#2668

In article <H9mdnUTgT5LYfF3QnZ2dnUVZ_uOdnZ2d@giganews.com>,
	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 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!
> 

Now that's funny, here.  Just how is the Z80 more primitve than the PDP-11?
And software?  At least 5 different OSes.  Wide language support.  Many
commercial applications.

And, at this point it is probably debatable which one between the TRS80
and PDP-11 has more users on both real hardware and emulators.  I have
quite a bit of both.

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]

#2670

On 5/4/2011 9:01 AM, Bill Gunshannon wrote:
> In article<H9mdnUTgT5LYfF3QnZ2dnUVZ_uOdnZ2d@giganews.com>,
> 	"Richard B. Gilbert"<rgilbert88@comcast.net>  writes:
>> 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!
>>
>
> Now that's funny, here.  Just how is the Z80 more primitve than the PDP-11?
> And software?  At least 5 different OSes.  Wide language support.  Many
> commercial applications.
>
> And, at this point it is probably debatable which one between the TRS80
> and PDP-11 has more users on both real hardware and emulators.  I have
> quite a bit of both.
>
> bill
>

I disposed of my "TRASH 80" and replaced it with a used Rainbow 100. 
The lack of a few milligrams of gold plating made the TRASH 80 a 
nightmare.  Tin oxidizes and did so on critical connectors!

[toc] | [prev] | [next] | [standalone]

#2671

Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>
>I disposed of my "TRASH 80" and replaced it with a used Rainbow 100. 
>The lack of a few milligrams of gold plating made the TRASH 80 a 
>nightmare.  Tin oxidizes and did so on critical connectors!

The GC "Nickel Print" kit fixed that problem nicely.  I made good money
nickel-plating the edge card connectors on Model Ones back when they were
new.
--scott
-- 
"C'est un Nagra. C'est suisse, et tres, tres precis."

[toc] | [prev] | [next] | [standalone]

#2672

In article <KsmdnY-dhd7k_VzQnZ2dnUVZ_vqdnZ2d@giganews.com>,
	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> On 5/4/2011 9:01 AM, Bill Gunshannon wrote:
>> In article<H9mdnUTgT5LYfF3QnZ2dnUVZ_uOdnZ2d@giganews.com>,
>> 	"Richard B. Gilbert"<rgilbert88@comcast.net>  writes:
>>> 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!
>>>
>>
>> Now that's funny, here.  Just how is the Z80 more primitve than the PDP-11?
>> And software?  At least 5 different OSes.  Wide language support.  Many
>> commercial applications.
>>
>> And, at this point it is probably debatable which one between the TRS80
>> and PDP-11 has more users on both real hardware and emulators.  I have
>> quite a bit of both.
>>
> 
> I disposed of my "TRASH 80" and replaced it with a used Rainbow 100. 

I always wanted a Rainbow, too, but never had the luck of finding one.

> The lack of a few milligrams of gold plating made the TRASH 80 a 
> nightmare.  Tin oxidizes and did so on critical connectors!
 
Wow, you have gold on all your PDP-11 modules?  Maybe those old
cards are worth more than I thought.  :-)  I have a number of
TRS-80 Model-I's with the Expansion Interface and they all work
quite well. I spent more time cleaning edges connectors on my
daughters Nintendo than on the TRS-80.  And, of course, like the
PDP-11, today it is mostly done with emulators anyway.

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]

#2683

On 5/4/2011 12:33 PM, Bill Gunshannon wrote:
> In article<KsmdnY-dhd7k_VzQnZ2dnUVZ_vqdnZ2d@giganews.com>,
> 	"Richard B. Gilbert"<rgilbert88@comcast.net>  writes:
>> On 5/4/2011 9:01 AM, Bill Gunshannon wrote:
>>> In article<H9mdnUTgT5LYfF3QnZ2dnUVZ_uOdnZ2d@giganews.com>,
>>> 	"Richard B. Gilbert"<rgilbert88@comcast.net>   writes:
>>>> 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!
>>>>
>>>
>>> Now that's funny, here.  Just how is the Z80 more primitve than the PDP-11?
>>> And software?  At least 5 different OSes.  Wide language support.  Many
>>> commercial applications.
>>>
>>> And, at this point it is probably debatable which one between the TRS80
>>> and PDP-11 has more users on both real hardware and emulators.  I have
>>> quite a bit of both.
>>>
>>
>> I disposed of my "TRASH 80" and replaced it with a used Rainbow 100.
>
> I always wanted a Rainbow, too, but never had the luck of finding one.
>
>> The lack of a few milligrams of gold plating made the TRASH 80 a
>> nightmare.  Tin oxidizes and did so on critical connectors!
>
> Wow, you have gold on all your PDP-11 modules?  Maybe those old
> cards are worth more than I thought.  :-)  I have a number of
> TRS-80 Model-I's with the Expansion Interface and they all work
> quite well. I spent more time cleaning edges connectors on my
> daughters Nintendo than on the TRS-80.  And, of course, like the
> PDP-11, today it is mostly done with emulators anyway.
>

I have no PDP-11.  I had one at work many long years ago.  I don't miss 
it.  Poor cripple!  The screwing around necessitated by the microscopic 
address space was more trouble than it was worth!

[toc] | [prev] | [next] | [standalone]

#2697

Richard B. Gilbert wrote:
> I have no PDP-11.  I had one at work many long years ago.  I don't miss it.

You must never have worked on an -8!

A 22-bit PDP-11 with RSX-11M+ (I/D space, supervisor mode libraries)
was a huge improvement over the sad little 18-bit beasts (physical
address, of course). And memory resident overlays at least meant
that you did not have to wait for more than a single system call's
overhead for additional segments of your overlaid program to be
accessed. But, oh, the task builder overlay description language
files you had to manage!

The 18-bit physical address space was a broken concept from the
beginning: "Hey, we have all this 18/36 bit stuff already built
for the 10- and 20-series, let's give the 11's two entire bits
of extended physical address!"  To go to 22 bits your device
drivers still had to go through the 18 bit atrocity, with the
extra two bits tucked into the CSR somewhere, just so they could
address a set of "Unibus mapping registers" to extend the map
from 18 bits to 22 bits. In retrospect it all seems to have been
rather poor planning.

If in fact your code fit into the address space and did not need
32 bit arithmetic, it could be fast.  The first time I started
working in a group that had VAXen I noticed two 750's sitting
off to the side because they had not been able to handle the
application load.  Their replacement: a pair of 11/84's.
Granted, this was specialized in that the language interpreter
had to do a lot of single byte operations, resulting in the
initial versions, on 750's at least, being rather inefficient.
Sometimes extra bits just mean extra overhead.

George

[toc] | [prev] | [next] | [standalone]

#2699

On 5/6/2011 2:08 PM, G Cornelius wrote:
> Richard B. Gilbert wrote:
>> I have no PDP-11.  I had one at work many long years ago.  I don't miss it.
>
> You must never have worked on an -8!

I did work on a PDP-8 but not much.  The memory issues seemed difficult 
enough that I was surprised that anyone managed to get anything done!

I came to the PDP-8 after working with 24 bit and 32 bit architectures.
I REALLY don't miss the PDP-8!
<snip>

[toc] | [prev] | [next] | [standalone]

#2701

On 2011-05-06 12.08, G Cornelius wrote:
> Richard B. Gilbert wrote:
>> I have no PDP-11.  I had one at work many long years ago.  I don't miss it.
>
> You must never have worked on an -8!

Heh. Yeah, well, the PDP-8 code is pretty compact in a way, but of 
course you don't write something like SSL for a PDP-8.
Also, on both the PDP-8 and PDP-11 (but especially on the -8) assembly 
language programming was the norm. And you get so much more use out of 
memory that way. (And it also encourages you to keep your programs 
small... ;-) )

> A 22-bit PDP-11 with RSX-11M+ (I/D space, supervisor mode libraries)
> was a huge improvement over the sad little 18-bit beasts (physical
> address, of course). And memory resident overlays at least meant
> that you did not have to wait for more than a single system call's
> overhead for additional segments of your overlaid program to be
> accessed. But, oh, the task builder overlay description language
> files you had to manage!

Yeah. The ODL-files are not that fun, but I agree that M+ on a big 
PDP-11 is a very different experience to some small -11 with some other OS.

> The 18-bit physical address space was a broken concept from the
> beginning: "Hey, we have all this 18/36 bit stuff already built
> for the 10- and 20-series, let's give the 11's two entire bits
> of extended physical address!"  To go to 22 bits your device
> drivers still had to go through the 18 bit atrocity, with the
> extra two bits tucked into the CSR somewhere, just so they could
> address a set of "Unibus mapping registers" to extend the map
> from 18 bits to 22 bits. In retrospect it all seems to have been
> rather poor planning.

Well. The 18-bit thingy was not totally for the PDP-11. The Unibus was 
first done for the PDP-11, true, but the PDP-11 at that time was only 16 
bits (there was no MMU). However, the Unibus was also used in some 
18/36-bit products, where those two extra bits made sense. And sharing a 
bus design between several machines also makes sense (and both address 
and data can be 18 bits).

But yes, having room only for 18-bit addresses on the bus was obviously 
pretty little, and the PDP-11 quickly grew out of that too. Gordon Bell 
have a famous quote for the PDP-11 and address extensions.

The Unibus map is annoying, true, but not really a big issue. It's the 
same thing on a VAX. Except the Unibus map is more fine grained on VAXen.

(That's why the 11/70 had Massbuses... ;-) )

> If in fact your code fit into the address space and did not need
> 32 bit arithmetic, it could be fast.  The first time I started
> working in a group that had VAXen I noticed two 750's sitting
> off to the side because they had not been able to handle the
> application load.  Their replacement: a pair of 11/84's.
> Granted, this was specialized in that the language interpreter
> had to do a lot of single byte operations, resulting in the
> initial versions, on 750's at least, being rather inefficient.
> Sometimes extra bits just mean extra overhead.

Heck. The 11/750 is not a fast machine. It's definitely slower than an 
11/84, unless you do things that the VAX can do natively and the PDP-11 
can't.

	Johnny

[toc] | [prev] | [next] | [standalone]

#2711

Johnny Billquist <bqt@update.uu.se> writes:

> On 2011-05-06 12.08, G Cornelius wrote:
>> Richard B. Gilbert wrote:

>> The 18-bit physical address space was a broken concept from the
>> beginning: "Hey, we have all this 18/36 bit stuff already built
>> for the 10- and 20-series, let's give the 11's two entire bits
>> of extended physical address!"  To go to 22 bits your device
>> drivers still had to go through the 18 bit atrocity, with the
>> extra two bits tucked into the CSR somewhere, just so they could
>> address a set of "Unibus mapping registers" to extend the map
>> from 18 bits to 22 bits. In retrospect it all seems to have been
>> rather poor planning.

> Well. The 18-bit thingy was not totally for the PDP-11. The Unibus was 
> first done for the PDP-11, true, but the PDP-11 at that time was only 16 
> bits (there was no MMU). However, the Unibus was also used in some 
> 18/36-bit products, where those two extra bits made sense. And sharing a 
> bus design between several machines also makes sense (and both address 
> and data can be 18 bits).

There wasn't any Unibus in the PDP-10 world until the introduction of the 2020,
which used the Unibus for I/O interfaces.  That was 1978, nearly a decade after
the PDP-11 brought Unibus into being...

-- 
Rich Alderson                                   news@alderson.users.panix.com
    the russet leaves of an autumn oak/inspire once again the failed poet/
    to take up his pen/and essay to place his meagre words upon the page...

[toc] | [prev] | [next] | [standalone]

#2713

On 2011-05-07 19.00, Rich Alderson wrote:
> Johnny Billquist<bqt@update.uu.se>  writes:
>
>> On 2011-05-06 12.08, G Cornelius wrote:
>>> Richard B. Gilbert wrote:
>
>>> The 18-bit physical address space was a broken concept from the
>>> beginning: "Hey, we have all this 18/36 bit stuff already built
>>> for the 10- and 20-series, let's give the 11's two entire bits
>>> of extended physical address!"  To go to 22 bits your device
>>> drivers still had to go through the 18 bit atrocity, with the
>>> extra two bits tucked into the CSR somewhere, just so they could
>>> address a set of "Unibus mapping registers" to extend the map
>>> from 18 bits to 22 bits. In retrospect it all seems to have been
>>> rather poor planning.
>
>> Well. The 18-bit thingy was not totally for the PDP-11. The Unibus was
>> first done for the PDP-11, true, but the PDP-11 at that time was only 16
>> bits (there was no MMU). However, the Unibus was also used in some
>> 18/36-bit products, where those two extra bits made sense. And sharing a
>> bus design between several machines also makes sense (and both address
>> and data can be 18 bits).
>
> There wasn't any Unibus in the PDP-10 world until the introduction of the 2020,
> which used the Unibus for I/O interfaces.  That was 1978, nearly a decade after
> the PDP-11 brought Unibus into being...

True. And I did say that the Unibus first came with the PDP-11. And I 
don't know why DEC decided on having 18 address bits on the Unibus, but 
it can't very well have been for just doing a 2-bit expansion of the 
PDP-11 address space in the future, so it seems more likely that they 
were considering the possibility of using it on 18/36 bit products. But 
that is just guessing on my part. (But really, if it were for just -11 
expansion, why on earth only make room for a 2 bit expansion? When it 
was done, it was a totally open and free decision to make provisions for 
a larger expansion. If that was the case, then I would agree with the 
statement that it was very poor planning.)

Also, the fact that you can run 18-bit data on the Unibus is totally 
lost on a PDP-11, since it never use that, but instead use the two 
additional bits for parity of each data byte.

I don't know much details of the Unibus on the PDP-15 either, but that 
came sooner than the -2020.

Also, not totally relevant, but the 11/40 FE of the KL-10 have a Unibus 
as well, and the machine normally use a dual-ported RP06 which is 
formatted in 18-bit mode, that is also accessed by the FE. As such, 
something non entirely -11-normal is done on the RH11 of the FE...
But it's not really the same as any 18/36 bit machine with a Unibus in 
anyway, so it's more of a curious oddball among -11s.

	Johnny

[toc] | [prev] | [next] | [standalone]

#2715

On 5/7/2011 9:00 PM, Rich Alderson wrote:
> Johnny Billquist<bqt@update.uu.se>  writes:
>
>> On 2011-05-06 12.08, G Cornelius wrote:
>>> Richard B. Gilbert wrote:
>
>>> The 18-bit physical address space was a broken concept from the
>>> beginning: "Hey, we have all this 18/36 bit stuff already built
>>> for the 10- and 20-series, let's give the 11's two entire bits
>>> of extended physical address!"  To go to 22 bits your device
>>> drivers still had to go through the 18 bit atrocity, with the
>>> extra two bits tucked into the CSR somewhere, just so they could
>>> address a set of "Unibus mapping registers" to extend the map
>>> from 18 bits to 22 bits. In retrospect it all seems to have been
>>> rather poor planning.
>
>> Well. The 18-bit thingy was not totally for the PDP-11. The Unibus was
>> first done for the PDP-11, true, but the PDP-11 at that time was only 16
>> bits (there was no MMU). However, the Unibus was also used in some
>> 18/36-bit products, where those two extra bits made sense. And sharing a
>> bus design between several machines also makes sense (and both address
>> and data can be 18 bits).
>
> There wasn't any Unibus in the PDP-10 world until the introduction of the 2020,
> which used the Unibus for I/O interfaces.  That was 1978, nearly a decade after
> the PDP-11 brought Unibus into being...
>

Please be a little more careful about your attributions.  The above text 
does not contain anything that I wrote!

[toc] | [prev] | [next] | [standalone]

#2736

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

> On 5/7/2011 9:00 PM, Rich Alderson wrote:
>> Johnny Billquist<bqt@update.uu.se>  writes:

>>> On 2011-05-06 12.08, G Cornelius wrote:
>>>> Richard B. Gilbert wrote:

> Please be a little more careful about your attributions.  The above text 
> does not contain anything that I wrote!

My apologies.

-- 
Rich Alderson                                   news@alderson.users.panix.com
    the russet leaves of an autumn oak/inspire once again the failed poet/
    to take up his pen/and essay to place his meagre words upon the page...

[toc] | [prev] | [next] | [standalone]

#2729

On Fri, 6 May 2011 at 16:13 -0600, Johnny Billquist wrote:

> On 2011-05-06 12.08, G Cornelius wrote:
>
>> If in fact your code fit into the address space and did not need 32 
>> bit arithmetic, it could be fast.  The first time I started working 
>> in a group that had VAXen I noticed two 750's sitting off to the 
>> side because they had not been able to handle the application load. 
>> Their replacement: a pair of 11/84's. Granted, this was specialized 
>> in that the language interpreter had to do a lot of single byte 
>> operations, resulting in the initial versions, on 750's at least, 
>> being rather inefficient. Sometimes extra bits just mean extra 
>> overhead.
>
> Heck. The 11/750 is not a fast machine. It's definitely slower than 
> an 11/84, unless you do things that the VAX can do natively and the 
> PDP-11 can't.

It seemed to me that the 11/750 was even slower than an 11/44, but 
perhaps that had something to do with their respective workloads.


-- 

Rob Brown                        b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd.      (780)438-9343 (voice)
Edmonton                         (780)437-3367 (FAX)
                                  http://gmcl.com/

[toc] | [prev] | [next] | [standalone]

#2730

On 2011-05-09 09.40, Rob Brown wrote:
>
> On Fri, 6 May 2011 at 16:13 -0600, Johnny Billquist wrote:
>
>> On 2011-05-06 12.08, G Cornelius wrote:
>>
>>> If in fact your code fit into the address space and did not need 32
>>> bit arithmetic, it could be fast. The first time I started working in
>>> a group that had VAXen I noticed two 750's sitting off to the side
>>> because they had not been able to handle the application load. Their
>>> replacement: a pair of 11/84's. Granted, this was specialized in that
>>> the language interpreter had to do a lot of single byte operations,
>>> resulting in the initial versions, on 750's at least, being rather
>>> inefficient. Sometimes extra bits just mean extra overhead.
>>
>> Heck. The 11/750 is not a fast machine. It's definitely slower than an
>> 11/84, unless you do things that the VAX can do natively and the
>> PDP-11 can't.
>
> It seemed to me that the 11/750 was even slower than an 11/44, but
> perhaps that had something to do with their respective workloads.

I don't know for sure, but I would have guessed that they were about 
equal, but maybe with a small edge for the 11/44.

	Johnny

[toc] | [prev] | [next] | [standalone]

#2737

In alt.sys.pdp11 Rob Brown <mylastname@gmcl.com> wrote:
> It seemed to me that the 11/750 was even slower than an 11/44, but 
> perhaps that had something to do with their respective workloads.

For anything not requiring 32 bits, I'm quite sure the 11/70 outran it, in
both integer math and string handling scenarios.  Floating point, I'm not
sure--not an area where I had to deal with performance.

-- 
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.os.vms

csiph-web