🚀 go-pugleaf

Jerome Fine wrote in message <3613A881.ED0E72FC@idirect.com>...
>TO:  All Current Users of RT-11 Application Programs
>

SNIP

>For those sites who do not use the date
>at all, but no longer want to depend on the PDP-11
>hardware or "could use" a dramatic speed improvement,
>there are a number of possibilities depending on the
>current hardware being used.  If only a maximum of three
>serial lines are in use for terminals along with only a
>small amount of disk storage (up to 2 GBytes), there are
>simple replacement solutions based on a standard PC
>running W95 and using the E11 emulator mentioned above.
>Of course, this solution is not limited to only those sites
>that don't use the date at all.
>


Our particular system has 24 serial ports (8 DHV + 12 DLV).  Five of the
serial ports are driving printers (which could just as well be Centronics
parallel).  Only four of the remaining serial ports are in use for
terminals, one of which is the main console.  The rest of the serial ports
are currently unused.

Is there an RT-11 emulator on a PC that could handle three terminals and
five printers (you may ask why we have five printers...Laser Printer for
letters, 8.5" wide printer for small reports, 14" wide printer for big
reports, gummed label printer for mailings, pre-printed, 3-part form
printer...this way we avoid changing paper.  There is also a check printer,
but that is hanging off the AUX port of the terminal in accounting.).  It
would be nice if we could add more terminals as the need arises.

Les

In article <3615617f.0@emerald.silicon.net>,
Les LaZar [Zoltech Corp] <Les_LaZar@csi.com> wrote:
>Is there an RT-11 emulator on a PC that could handle three terminals and
>five printers (you may ask why we have five printers...Laser Printer for
>letters, 8.5" wide printer for small reports, 14" wide printer for big
>reports, gummed label printer for mailings, pre-printed, 3-part form
>printer...this way we avoid changing paper.  There is also a check printer,
>but that is hanging off the AUX port of the terminal in accounting.).  It
>would be nice if we could add more terminals as the need arises.

The "full" version of Ersatz-11 supports lots of terminal lines, this config
should be no problem with lots of space to expand, assuming some of the
printers are serial (or could be made serial with a Black Box DP/RS232
converter) since PCs generally support only 3 or 4 parallel LPTs max.
You can use any combination of COM, LPT, RocketPort, PCI-FAST, Acceleport
Xe, or BocaBoard ports, to emulate any combination of DL(V)11x, DHU/DHV11,
or DZ(Q)11 ports.  The hobby/demo version of E11 doesn't support muxes
(either real or emulated) but you can still get up to 16 DL(V)s (and up to
four LP(V)s) using COM or LPT ports (and you always get up to twelve emulated
VT100 sessions shown one at a time on the PC monitor), and the next release
will include support for the Sound Blaster MIDI port (OK so I'm probably
the only person who cares about that!).  Anyway this wouldn't be an "RT-11
emulator", it would be real RT-11 running on an emulated PDP-11.

John Wilson
D Bit

John Wilson wrote:
>
> In article <3615617f.0@emerald.silicon.net>,
> Les LaZar [Zoltech Corp] <Les_LaZar@csi.com> wrote:
> >Is there an RT-11 emulator on a PC that could handle three terminals and
> >five printers (you may ask why we have five printers...Laser Printer for
> >letters, 8.5" wide printer for small reports, 14" wide printer for big
> >reports, gummed label printer for mailings, pre-printed, 3-part form
> >printer...this way we avoid changing paper.  There is also a check printer,
> >but that is hanging off the AUX port of the terminal in accounting.).  It
> >would be nice if we could add more terminals as the need arises.
>
> The "full" version of Ersatz-11 supports lots of terminal lines, this config
> should be no problem with lots of space to expand, assuming some of the
> printers are serial (or could be made serial with a Black Box DP/RS232
> converter) since PCs generally support only 3 or 4 parallel LPTs max.
> You can use any combination of COM, LPT, RocketPort, PCI-FAST, Acceleport
> Xe, or BocaBoard ports, to emulate any combination of DL(V)11x, DHU/DHV11,
> or DZ(Q)11 ports.  The hobby/demo version of E11 doesn't support muxes
> (either real or emulated) but you can still get up to 16 DL(V)s (and up to
> four LP(V)s) using COM or LPT ports (and you always get up to twelve emulated
> VT100 sessions shown one at a time on the PC monitor), and the next release
> will include support for the Sound Blaster MIDI port (OK so I'm probably
> the only person who cares about that!).  Anyway this wouldn't be an "RT-11
> emulator", it would be real RT-11 running on an emulated PDP-11.
>
> John Wilson
> D Bit
-----
There is good reason on a PDP-11 not to run too many parallel printers
at once ... they are character interrupt devices ... One interrupt per
character ... And because a parallel printer chugs the data out at a
significant rate, that represents a significant interrupt load on the
system.

So it actually makes sense to go with a serial printer.  In fact, I am
very surprised that the PC world went back to parallel printers.

Stuart

In article <361589A6.2EB9@concentric.net>, Stuart Brook wrote:
>There is good reason on a PDP-11 not to run too many parallel printers
>at once ... they are character interrupt devices ... One interrupt per
>character ... And because a parallel printer chugs the data out at a
>significant rate, that represents a significant interrupt load on the
>system.
>
>So it actually makes sense to go with a serial printer.  In fact, I am
>very surprised that the PC world went back to parallel printers.

You write as if "parallel printer" == "one interrupt per character",
and "serial printer" == "buffering".

Faulty reasoning.  There is no reason you couldn't build a parallel
printer controller with buffering.  I am surprised that in this day
and age, not that parallel printers are still used, but that the
controllers still produce one interrupt per character.

And historically there were plenty of serial controllers, like the
wonderful DZ, with one interrupt per character...

>There is good reason on a PDP-11 not to run too many parallel printers
>at once ... they are character interrupt devices ... One interrupt per
>character ... And because a parallel printer chugs the data out at a
>significant rate, that represents a significant interrupt load on the
>system.
>
>So it actually makes sense to go with a serial printer.  In fact, I am
>very surprised that the PC world went back to parallel printers.

I remember writing the software to drive a very high speed page
printer from an 11/04 under RT11 v2. The interface was a standard
LP11 board and because ready was asserted almost immediately after
each character was written until the printer buffer was full the
driver looped for a whole page. Hence there was only one interupt
per page. I cannot recall having to modify the driver to do this.
9600 baud serial comms would not have been anything like fast enough.


J.C.B.Sharp
London
jcbs@obtfc.win-uk.net

Mike Haertel wrote:
>
> In article <361589A6.2EB9@concentric.net>, Stuart Brook wrote:
> >There is good reason on a PDP-11 not to run too many parallel printers
> >at once ... they are character interrupt devices ... One interrupt per
> >character ... And because a parallel printer chugs the data out at a
> >significant rate, that represents a significant interrupt load on the
> >system.
> >
> >So it actually makes sense to go with a serial printer.  In fact, I am
> >very surprised that the PC world went back to parallel printers.
>
> You write as if "parallel printer" == "one interrupt per character",
> and "serial printer" == "buffering".
>
> Faulty reasoning.  There is no reason you couldn't build a parallel
> printer controller with buffering.  I am surprised that in this day
> and age, not that parallel printers are still used, but that the
> controllers still produce one interrupt per character.
>
> And historically there were plenty of serial controllers, like the
> wonderful DZ, with one interrupt per character...
-----
True enough ... The DH type interfaces being DMA output were so much
better.

True enough, a hardware buffered printer controller would also make some
sense ... as would a DMA controller.

Other Good Things(tm) would be data compression to printers :-)

Stuart

In article <slrn71cifc.563.mike@ducky.net>, Mike Haertel wrote:
>Faulty reasoning.  There is no reason you couldn't build a parallel
>printer controller with buffering.  I am surprised that in this day
>and age, not that parallel printers are still used, but that the
>controllers still produce one interrupt per character.

Actually, in the PC world you're lucky to get _any_ interrupts at
all from the parallel port.
--
Roger Ivie
Design Analysis Associates
75 West 100 South
Logan, UT  84321
mailto:rivie@daa-utah.com
phoneto:(435)753-2212

Well, FWIW, we rarely have more than one printer at a time actually
printing.  There is no detectable performance impact on the terminal users
when a print job is running (multiple file sorts using the ESDI hard disk
are noticable).  As stated above, both the serial (DL) and parallel (LP)
interfaces produce one interrupt per character (on a PC, the serial ports
may use polled I/O, which would be even worse, especially in a multi-user
environment).

Les

Newsgroups: alt.sys.pdp11,vmsnet.pdp-11,comp.sys.dec,comp.sys.dec.micro
Subject: Re: RT-11/TSX-PLUS Year 2000 Compliant Application Programs
Summary:
Expires:
References: <3613A881.ED0E72FC@idirect.com> <slrn71cifc.563.mike@ducky.net> <36165A05.52ED@concentric.net> <3616ac57.0@emerald.silicon.net>
Sender:
Followup-To:
Distribution:
Organization: D Bit, Troy, NY
Keywords:
Cc:

In article <3616ac57.0@emerald.silicon.net>,
Les LaZar [Zoltech Corp] <Les_LaZar@csi.com> wrote:
>As stated above, both the serial (DL) and parallel (LP)
>interfaces produce one interrupt per character (on a PC, the serial ports
>may use polled I/O, which would be even worse, especially in a multi-user
>environment).

That's a tricky thing with emulation -- making sure the PDP-11 sees
character-at-a-time interrupts at a useful rate even when the PC physical
port driver is doing lots of buffering and getting very few real interrupts.


From: rivie@rivie.daautah.com (Roger Ivie)

>Actually, in the PC world you're lucky to get _any_ interrupts at
>all from the parallel port.

True enough when there's >1 LPT port, since they all tend to be set for
IRQ7.  So you need to be ready to choose between interrupt operation, and
polled I/O using timers, extra pain!

John Wilson
D Bit

Hi Jerome, nice to read from you again ...

I think we should avoid - in time - that somebody reinvents the wheel.

So, it would be useful to have a list of the tools that are Y2K compliant
already. You know what you have done so far and can name your contributions
thereto. I did a bit too, consisting of 2 applications and 1 operating
system:
- Ian Hammond's DAY.SAV for RT-11 and compatibles (Ian doesn't seem to run a
website, but I know his e-mail address)
- my BRXDOS.SAV for RT-11 and compatibles
<http://ourworld.compuserve.com/homepages/MosesEle/brxdos.htm>
- DEC's RT-11 V 5.5
<http://ourworld.compuserve.com/homepages/MosesEle/year2k.htm>

Regards
MOSES <http://www.MosesEle.de>

Jerome Fine schrieb in Nachricht <360F9334.A0336496@idirect.com>...
>TO:  All Current Users of RT-11 Application Programs
>
>I have been approached by a number of companies to fix the
>bugs in their  RT-11/TSX-PLUS  application programs, in
>particular with regard to Year 2000 Bugs, but all bugs
>...
>start the initial discussion within the news group where
>more suggestions will be available than I may be able
>to recommend or be aware of.
>...
>Jerome Fine
>RT-11/TSX-PLUS  User/Addict
>Year 2000 Solutions for RT-11 Legacy Applications
>(Sources not always required)
>

>Les LaZar [Zoltech Corp] wrote:

> Well, FWIW, we rarely have more than one printer at a time actually
> printing.  There is no detectable performance impact on the terminal users
> when a print job is running (multiple file sorts using the ESDI hard disk
> are noticable).  As stated above, both the serial (DL) and parallel (LP)
> interfaces produce one interrupt per character (on a PC, the serial ports
> may use polled I/O, which would be even worse, especially in a multi-user
> environment).

Jerome Fine replies:

The E11 emulation under W95 on a PC allows the parallel port to be
used directly via:
"ASSIGN   LP0:   LPT1:"
The serial PC ports may be used as:
"ASSIGN   TT1:   COM1:"
"ASSIGN   TT2:   COM2:"
And I suppose etc., except that I have never had access to a PC
with more than 2 COM ports.  Nor have I had the occasion to invoke
the DHV11 emulation as opposed to the DLV11 emulation which
is illustrated above.

As far as overhead is concerned, since a Pentium II 400 MMX PC
likely results in a speed of about 5 * PDP-11/93, I doubt that
there would be any problems in running your application from the
CPU speed point of view.

The only question is how you are going to handle the Year 2000
Compliance aspects.  From an Application point of view, RDM
should be flexible enough to take care of the situation and I
presume you will be taking care of that aspect yourselves.  From
the operating system point of view, TSX-PLUS V6.5 is Y2K
compliant.  If you never use any of the RT-11 utilities like
DIR, then you will not care.  One minor aspect if you stay
with your real PDP-11 hardware is that the backup tape
sounds like a TK25 which will need a very minor Y2K set of
patches if you are using the version with the file structure code.
Since you are using a TSX-PLUS device driver at this point,
I can provide those patches if you wish.  In addition, you haven't
said which program is used for backup.

While I agree that now may be the time to shift out of the PDP-11
code and OS, you may want to shift to PC hardware first and
shift applications one by one into the PC environment rather
than all at once.  Since I am unable to help in respect of that
kind of shift, you are going to have to evaluate that with other
help.

So your 3 options are:

(a)  Maintain your present hardware and software, but shift to
      Y2K compliant OS and applications.
(b)  Shift the OS and applications to Y2K compliant first
       followed by a shift to PC hardware  OR  visa versa.
(c)  Shift all the software and hardware to a PC environment.

I can help with both (a)  and  (b)  and have extensive experience
with both.

Sincerely yours,

Jerome Fine
RT-11/TSX-PLUS  User/Addict
Year 2000 Solutions for Currently Running RT-11 Applications
(Sources not always required)

> While I agree that now may be the time to shift out of the PDP-11
> code and OS, you may want to shift to PC hardware first and
> shift applications one by one into the PC environment rather
> than all at once.

I've never seen anyone successfully migrate in that manner, because once
the code is operating in the new environment, the relief of not having
to worry about it is too great ... and they just carry on as before,
until the new host becomes unreliable, when the quest starts all over
again!

On Mon, 5 Oct 1998 12:51:08 +0100, "MOSES"
<100021.2047@compuserve.com> wrote:

>Hi Jerome, nice to read from you again ...
>
>I think we should avoid - in time - that somebody reinvents the wheel.
>
>So, it would be useful to have a list of the tools that are Y2K compliant
>already. You know what you have done so far and can name your contributions
>thereto. I did a bit too, consisting of 2 applications and 1 operating
>system:
>- Ian Hammond's DAY.SAV for RT-11 and compatibles (Ian doesn't seem to run a
>website, but I know his e-mail address)
I didn't know that! I've been looking at some of my PDP-11 stuff for
Y2K compliance recently for some customers. I'm always surprised when
I hear people are still using the product, particularly when I get new
product inquiries.

SHAREplus, the operating system, was heavily based on VMS, so it
already had a lot of four digit date stuff. I hope to be able to say
more after Christmas. But, I still don't have any documentation on how
the RT-11 "era" mechanism works.

My email address is ian@hammo.com. Web site will come later.

ian hammond

acyb007@ibm.net (ian hammond) writes:

>SHAREplus, the operating system, was heavily based on VMS, so it
>already had a lot of four digit date stuff. I hope to be able to say
>more after Christmas. But, I still don't have any documentation on how
>the RT-11 "era" mechanism works.

Hi Ian - The era information is the high-order two bits of the date
word.  Previously reserved, they now indicate the year offset for
the date.  00 = 1972, 01 = 2004, 10 = 2036, 11 = 2068, for a maximum
year 31 years beyond that - 2099.

					Megan Gentry
					Former RT-11 Developer

+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL   | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group |          (home):  mbg!world.std.com |
| Compaq Computer Corporation    | addresses need '@' in place of '!'  |
| 110 Spitbrook Rd. ZK03-2/T43   | URL:     http://world.std.com/~mbg/ |
| Nashua, NH 03062               | "pdp-11 programmer - some assembler |
| (603) 884 1055                 |  required." - mbg                   |
+--------------------------------+-------------------------------------+

ian hammond wrote:
>
> On Sat, 10 Oct 1998 17:18:35 GMT, mbg@world.std.com (Megan) wrote:
>
> >acyb007@ibm.net (ian hammond) writes:
> >
> >>SHAREplus, the operating system, was heavily based on VMS, so it
> >>already had a lot of four digit date stuff. I hope to be able to say
> >>more after Christmas. But, I still don't have any documentation on how
> >>the RT-11 "era" mechanism works.
> >
> >Hi Ian - The era information is the high-order two bits of the date
> >word.  Previously reserved, they now indicate the year offset for
> >the date.  00 = 1972, 01 = 2004, 10 = 2036, 11 = 2068, for a maximum
> >year 31 years beyond that - 2099.
> >
> >                                       Megan Gentry
> >                                       Former RT-11 Developer
>
> Megan, you've just reminded me why I loved RT-11 so: why make it
> complicated. What did those tee-shirts used to say: "Who says you
> can't love something that's small, fast and easy-to-use."
>
> Still, I'm not quite sure what I'll tell my grandkids about fixing up
> the problem for 2099.

Heehee ... If V5.7 is the next version due to ship early Nov. 1998, then
what version will the one to fix the Y21C be called ?  V57.7 ?

Come to that, who's for betting how long PDP-11s will survive.  In 1987
when I joined Digital, we were talking 5 years at the outside.  In 1993
when I joined Digital's PDP SW engineering we were talking 4 years at
the outside.  But they're still going strong.  We've given up talking
about how long PDP-11s are going to last!

Stuart

On Sat, 10 Oct 1998 17:18:35 GMT, mbg@world.std.com (Megan) wrote:

>acyb007@ibm.net (ian hammond) writes:
>
>>SHAREplus, the operating system, was heavily based on VMS, so it
>>already had a lot of four digit date stuff. I hope to be able to say
>>more after Christmas. But, I still don't have any documentation on how
>>the RT-11 "era" mechanism works.
>
>Hi Ian - The era information is the high-order two bits of the date
>word.  Previously reserved, they now indicate the year offset for
>the date.  00 = 1972, 01 = 2004, 10 = 2036, 11 = 2068, for a maximum
>year 31 years beyond that - 2099.
>
>					Megan Gentry
>					Former RT-11 Developer

Megan, you've just reminded me why I loved RT-11 so: why make it
complicated. What did those tee-shirts used to say: "Who says you
can't love something that's small, fast and easy-to-use."

Still, I'm not quite sure what I'll tell my grandkids about fixing up
the problem for 2099. 


ian hammond
========================================
"walking on water wasn't built in a day"

Stuart Brook <sbrook@concentric.net> writes:


>> Megan, you've just reminded me why I loved RT-11 so: why make it
>> complicated. What did those tee-shirts used to say: "Who says you
>> can't love something that's small, fast and easy-to-use."

Actually, the t-Shirts read:

	"Who says you can't love something that's
	 small and finishes fast."

:-)

>Come to that, who's for betting how long PDP-11s will survive.  In 1987
>when I joined Digital, we were talking 5 years at the outside.  In 1993
>when I joined Digital's PDP SW engineering we were talking 4 years at
>the outside.  But they're still going strong.  We've given up talking
>about how long PDP-11s are going to last!

When I worked for the RT group, we had no less than 2 managers hired
ostensibly to manage the group to retirement since -11s had a limited
future...

The group, and -11's in general , outlived the tenure of both of them...

					Megan Gentry
					Former RT-11 Developer

+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL   | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group |          (home):  mbg!world.std.com |
| Compaq Computer Corporation    | addresses need '@' in place of '!'  |
| 110 Spitbrook Rd. ZK03-2/T43   | URL:     http://world.std.com/~mbg/ |
| Nashua, NH 03062               | "pdp-11 programmer - some assembler |
| (603) 884 1055                 |  required." - mbg                   |
+--------------------------------+-------------------------------------+

>ian hammond wrote:

> On Sat, 10 Oct 1998 17:18:35 GMT, mbg@world.std.com (Megan) wrote:
>
> >acyb007@ibm.net (ian hammond) writes:
> >
> >>SHAREplus, the operating system, was heavily based on VMS, so it
> >>already had a lot of four digit date stuff. I hope to be able to say
> >>more after Christmas. But, I still don't have any documentation on how
> >>the RT-11 "era" mechanism works.
> >
> >Hi Ian - The era information is the high-order two bits of the date
> >word.  Previously reserved, they now indicate the year offset for
> >the date.  00 = 1972, 01 = 2004, 10 = 2036, 11 = 2068, for a maximum
> >year 31 years beyond that - 2099.
> >
> >                                       Megan Gentry
> >                                       Former RT-11 Developer
>
> Megan, you've just reminded me why I loved RT-11 so: why make it
> complicated. What did those tee-shirts used to say: "Who says you
> can't love something that's small, fast and easy-to-use."
>
> Still, I'm not quite sure what I'll tell my grandkids about fixing up
> the problem for 2099.

Hi Ian,

Just wanted to add my little bit - I will add more in a week or two.
It is possible to extend the DATE value another 32 years beyond
2099 by using the values in the month field that at present are
not being used.  I would feel very much against such a procedure
which would, I feel, excessively complicate the whole DATE value
issue, especially since this solution ONLY adds another 32 years.
With the advent of not ONE, but TWO emulators for all PDP-11
OSs (the E11 emulator by John Wilson and the Supnik emulator
by Bob Supnik), it is just possible that RT-11 may still be in "use"
in some manner in 2100.

Note as Megan Gentry has requested, Mentec has authorized the
use of V5.3 of RT-11 ONLY under the Supnik emulator, and that
even real PDP-11 hardware (which in many cases already had an
RT-11 license) may not be used on a hobby basis at this time
with V5.3 of RT-11.  However, I am aware that even DEC allows
know ("bugs") in RT-11 versions to be modified or as I interpret
their statement, to be fixed, since if they are being modified, I hardly
think that not fixing the ("bugs") is what would be intended.

Incidentally, of all the superb things done in RT-11, who was the
fellow back in 1972 who dreamed up the order of the fields
in the DATE value as:  MONTH  /  DAY OF MONTH  /  YEAR??
Even in the DIR utility, they had to do a re-order of the fields
when a display in "/ORDER:DATE"  is requested.  I realize that
a more reasonable order of:  YEAR  /  MONTH  /  DAY OF MONTH
would still not solve the 2100 problem, but at least RT-11 could have
been Y2K compliant right from the beginning - or at the very least,
there would have been a seamless transition from the point of view
of the algorithm - just start outputting a 4 digit year and the problem
would be solved.  Other than this one rather trivial aspect, I still find
RT-11/TSX-PLUS to be superb.  Eventually, I hope to be able
to release a PATH  HANDLER (ala the MS-DOS  PATH name
or the VMS logical name list).  While the storage aspects of being
able to reference multiple directories under a single reference are
no longer as important (e.g. PH3:  => LD5:,  LD3:,  DU1:, DU0:)
due to much larger hard disk drives being available, I still hope
that it will be a valuable addition.

Has anyone reading these groups thought of a method of extending the
DATE value beyond 2100 - other that what I suggested which would
last for ONLY another 32 years?  I suggest that this time, a concerted
effort be made that would allow at least another 1000 or even 10,000
years - you just never can tell.  Obviously, another word or two or
even three will be needed and since space will no longer be a major
problem, I suggest that the different ideas be batted around for a
decade or two until some consensus is reached.  At that point, the
changes could be made for posterity and since I would hope that
all of RT-11 could be released into the public domain by 2020 or
at the very least by 2036 (WHEN THE PRESENT DATE VALUE
BECOMES NEGATIVE - I INTEND TO WATCH MY MONITOR
DISPLAY THE OCTAL VALUES OF THE DATE AND TIME
AND  SEE  THE  ROLLOVER  OCCUR  IN  REAL  TIME -
I only hope that I have the understanding to know what I am watching
when I am 97 - let alone be around to enjoy the event).

Sincerely yours,

Jerome Fine
Year 2000 Solutions for Currently Running RT-11 Applications
(Sources not always required)

Jerome ...

Your naivte is showing again ...

Hell, in 1972, nobody ever thought that PDP-11s would be around in 2000!
Why should they have designed for it ?  There was probably some valid
reason for the structure of the date word.  Heavens, they probably
didn't even think *they'd* be around in 2000!  Certainly nobody was
thinking 2000 then!

Stuart

Jerome Fine <jhfine@idirect.com> writes:

> Eventually, I hope to be able
> to release a PATH  HANDLER (ala the MS-DOS  PATH name
> or the VMS logical name list).

Bill Walker's UCL+ already does this - available from the usual
places (Uppsala University, Sunsite, etc)...

Billy Y..

On 12 Oct 1998 07:44:22 PDT, Stuart Brook <sbrook@concentric.net>
wrote:

>Jerome ...
>
>Your naivte is showing again ...
>
>Hell, in 1972, nobody ever thought that PDP-11s would be around in 2000!
>Why should they have designed for it ?  There was probably some valid
>reason for the structure of the date word.  Heavens, they probably
>didn't even think *they'd* be around in 2000!  Certainly nobody was
>thinking 2000 then!

I guess you are referring to this passage in Jerome's post:

  Incidentally, of all the superb things done in RT-11, who was the
  fellow back in 1972 who dreamed up the order of the fields
  in the DATE value as:  MONTH / DAY OF MONTH / YEAR??

It took me ages to work out the utterly obvious about this date
layout: it's just the U.S. date format, set in silicon.

The author probably had a non PDP-11 background, since it is cast from
right to left, rather than from left to right, which would have been:

	YEAR / DAY-OF-MONTH / MONTH

But the really crazy bit was that it had an unused two-bit field,
leaving the date expressed in 14 bits:

	UNUSED / MONTH / DAY-OF-MONTH / YEAR

Thus, to come a little closer to answering the question "Who was the
fellow back in 1972", I would suggest it was one of the two or three
programmers who came across from the 12-bit PDP-8 OS-8 group. They
were probably out of their mind with joy at escaping the 12-bit limit.
Indeed, they might been a little lost in 16-bits. And the PDP-8 did
number bits from right to left.

But the PDP-8 developers would have known about the date problem. I
don't know what the OS-8 date format was, but it must have been pretty
small because it ran out of space years ago. The story goes that DEC
released a beta version with the extended date to a few select sites.
A few months later DEC put the final version on the market. To their
surprise, almost nobody purchased the new version, even though they
needed it desperately to fix the date problem. The penny finally
dropped that the PDP-8 community had already developed their own
informal distribution mechanism that did not require DEC's assistance.

As to the actual name of the developer? Years ago I had the names of
the original developers, garnered from the V1 sources, but I guess
those floppies have had a slow but noble disintegration somewhere.
Ashes to Ashes. Rust to Rust.



ian hammond
==============================================================
"things are more like they are now than they ever were before"



 

But what did you do in a company that had already worked out that 16
bits was too small, even before the machine was finally released?

Stuart Brook wrote:
> Hell, in 1972, nobody ever thought that PDP-11s would be around in 2000!
> Why should they have designed for it ?

Indeed, they knew quite well the problem was there.  They
even documented that there would be a problem come Y2K.  Yet
they didn't lift a finger to fix it.  (Reminds me of all
the C/Unix applications being written today that will die horribly
in the beginning of 2038.)

To quote from the pre-5.7 sources for DIR:

;+
; SD
; This routine handles user specified dates for /D, /J, and /K.
; Along with the rest of RT, it quits working January 1, 2000.
; NOTE:
;       This routine is called by SWJK.  It must not modify R2.
;-

To quote from the 5.7 sources for DIR:

;+
; SD
; This routine handles user specified dates for /D, /J, and /K.
; Along with the rest of RT, it now continues working through
;	December 31,2099!
; NOTE:
;       This routine is called by SWJK.  It must not modify R2.
;-

--
 Tim Shoppa                        Email: shoppa@trailing-edge.com
 Trailing Edge Technology          Voice: 301-767-5917
 7328 Bradley Blvd                 Fax:   301-767-5927
 Bethesda, MD, USA 20817

In article <3623696C.4DDC6F13@trailing-edge.com>,
Tim Shoppa  <shoppa@trailing-edge.com> wrote:
>Indeed, they knew quite well the problem was there.  They
>even documented that there would be a problem come Y2K.  Yet
>they didn't lift a finger to fix it.  (Reminds me of all
>the C/Unix applications being written today that will die horribly
>in the beginning of 2038.)

Only the ones that write structs direct to disk in binary form.

The rest will just take a recompile.

--
In hoc signo hack, Peter da Silva <peter@baileynm.com>
 `-_-'   "Heb jij vandaag je wolf al geaaid?"
  'U`
         "Tell init(8) to lock-n-load, we're goin' zombie slaying!"

Peter da Silva wrote:
>
> In article <3623696C.4DDC6F13@trailing-edge.com>,
> Tim Shoppa  <shoppa@trailing-edge.com> wrote:
> >Indeed, they knew quite well the problem was there.  They
> >even documented that there would be a problem come Y2K.  Yet
> >they didn't lift a finger to fix it.  (Reminds me of all
> >the C/Unix applications being written today that will die horribly
> >in the beginning of 2038.)
>
> Only the ones that write structs direct to disk in binary form.
>
> The rest will just take a recompile.

I would imagine that a lot of COBOL programmers in the 1960's
had the same attitude towards the Y2K problem - "Oh, somebody
will fix that later ... all they have to do is just add two more
digits to the year field and recompile!"

--
 Tim Shoppa                        Email: shoppa@trailing-edge.com
 Trailing Edge Technology          Voice: 301-767-5917
 7328 Bradley Blvd                 Fax:   301-767-5927
 Bethesda, MD, USA 20817

>Stuart Brook wrote:

> Your naivte is showing again ...
>
> Hell, in 1972, nobody ever thought that PDP-11s would be around in 2000!
> Why should they have designed for it ?  There was probably some valid
> reason for the structure of the date word.  Heavens, they probably
> didn't even think *they'd* be around in 2000!  Certainly nobody was
> thinking 2000 then!

Jerome Fine replies:

Stuart, if you would think first and reply later, you might realize that my
observation about the order of the fields in the DATE value had little to
do with Y2K problems and almost everything to do with a natural sort
order.  Even in the DIR utility, the 3 fields had to be re-ordered when
the user eventually was allowed to:   "DIR/SORT:DATE"
Why not have just done the order of the fields for such a situation
in the first place.  I do realize that the command became available
10 years later, but that is not the point.  In addition, I also mentioned
that this aspect was about the only poorly planned detail in RT-11,
a compliment with I think is richly deserved.

Plus your point of view is the very reason that I hold the computer
industry in such low regard with respect to how both management
and programmers think about planning for future problems.  At any
time up to 1980, all of RT-11 could have been made Y2K compliant
with so little effort that it dismays me as to why it was not done.
Even as late as V5.4G in December 1988, a Y2K effort would
have proven that DEC really cared about their users and realized
that just because other companies were waiting (a game that DEC
had played in the past - was it OS/8 with the PDP-8?) to implement
Y2K solutions far ahead of the need, DEC could have done RT-11
far ahead of time.  By 1988, I had already pointed out to a major
customer of mine at the time (one which I still have) that Y2K
modifications were already required for systems which were
estimated to still be needed in 2008.  Done at the time, the cost
would have been about 5% of what was needed to eventually
use a PC and completely re-write the code.

The computer industry is, in my opinion, very much to blame
for taking such a short-sighted approach.  RT-11 in particular
was just one example of both the lack of foresight as well as
the attitude, especially by large companies like DEC and IBM
at the time, but also by smaller ones as well, that the user
could always be conned into paying - as seems likely the case
right now - to fix bugs in the code that should have been and
obviously, like RSTS/E, could have been fixed many years ago.

So, you are not personally responsible for the lack of a present
Y2K in RT-11, but from other comments in your previous
post on this thread, it seems that you at least agreed with the
assessments in 1987 and 1993.  What I really don't understand
is why DEC did any Y2K work at all for V5.6 that was released
in August 1992 if that was the case.  If I were a betting person,
I would lay odds that much more Y2K work was done at the
time which did not make the V5.6 release and that the developers
figured that the next and final release in 1995 would provide
job security for another 3 years.  Except that sales of RT-11
had fallen so much at that point since the previous release of
V5.5 in October 1989 that DEC decided to and effectively
did disband the whole RT-11 development team just at the
point that V5.6 was being released in 1992 - from what I
have heard.  The only thing that would convince me otherwise
would be the sales figures and profit for the RT-11 group
for the 10 years from 1982 to 1992.  Since you, and by now
no one else has either, don't have that information for the
now bought-out DEC (which could therefore not hurt DEC
anymore), the discussion is likely best stopped right here.

So while I have been involved with RT-11 for more than 20
years, all the way back to V2.0 of RT-11, I have only been
saddened at the way DEC seem to milk RT-11 at the end.
But I know of one user who got even in the years from 1986
to 1988 when DEC was releasing a new version almost every
3 or 4 months.  This institution bought the update service for
RT-11 products for 2 years to be supplied on RL02 disk packs.
Like clockwork every 3 or 4 months, DEC shipped 2 RL02
disk packs worth more per year than the cost of the update
service.  I remember hearing that V5.4F and V5.4G were
only to fix bugs.  In 1988, that institution decided that the
PC would be the way to go in the future for small scale
systems.  No more development was done on the PDP-11
system and I received the parts from the last one around 1995
after I had supported it for about 5 years.  I still have a
few of the parts, but I suspect I will have to discard them
in a few years when I switch to a emulator running on a PC
because I can no longer run RT-11 on real PDP-11 hardware.
Hopefully, by that time there will be Y2K versions of RT-11
available for everyone - both commercial and hobby users.

Sincerely yours,

Jerome Fine
Year 2000 Solutions for Currently Running RT-11 Applications
(Sources not always required)

Tim Shoppa <shoppa@trailing-edge.com> writes:

>Indeed, they knew quite well the problem was there.  They
>even documented that there would be a problem come Y2K.  Yet
>they didn't lift a finger to fix it.

That's unfair and untrue.  Comments like that which you quote
below were warnings for us... we tried to take care of such
things when we could in future releases.  But the fact is that
the importance of it never exceeded the cutoff point on our
to-do lists when we planned new releases.  And as I said in
another post, the users never asked for it -- so it wasn't
important to them either.  (I have copies of the wishlists from
several DECUS symposia I attended)

>To quote from the pre-5.7 sources for DIR:

>;+
>; SD
>; This routine handles user specified dates for /D, /J, and /K.
>; Along with the rest of RT, it quits working January 1, 2000.
>; NOTE:
>;       This routine is called by SWJK.  It must not modify R2.
>;-

					Megan Gentry
					Former RT-11 Developer

+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL   | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group |          (home):  mbg!world.std.com |
| Compaq Computer Corporation    | addresses need '@' in place of '!'  |
| 110 Spitbrook Rd. ZK03-2/T43   | URL:     http://world.std.com/~mbg/ |
| Nashua, NH 03062               | "pdp-11 programmer - some assembler |
| (603) 884 1055                 |  required." - mbg                   |
+--------------------------------+-------------------------------------+

In article <362388D7.4E2BA351@trailing-edge.com>,
Tim Shoppa  <shoppa@trailing-edge.com> wrote:
>I would imagine that a lot of COBOL programmers in the 1960's
>had the same attitude towards the Y2K problem - "Oh, somebody
>will fix that later ... all they have to do is just add two more
>digits to the year field and recompile!"

Since the problem isn't "recompiling", it's finding where to add the two
extra digits, I'm not sure that you're making the point you think you're
making. If a bigger time_t is something that scares you, then you haven't
done enough ports with MUCH bigger problems than that.

I have a bigger problem with the buggers who wrote code that "knows" an
integer and a pointer are the same size. Actually, my biggest gripe is
with compiler vendors who come up with "long long" for their 64-bit ports
because they don't have the guts to break all the "all-the-world's-a-VAX"
code out there.

But then that's something I've been griping about since 1980 when I first
tried to port PDP-11 code to 4.1BSD. They should have made "long" a 64
bit value on the first VAX port, and the issue would never have arisen.

(instead we'd be griping about the 128 bit problem now)

Anyway, after shepherding some code from PDP-11 UNIX, to RSX-11 and VMS,
to Xenix-286 and MS-DOS, to SunOS, then to Digital UNIX and Solaris...
another recompile is nothing. Dealing with word-size problems is a minor
issue: a halfway decent compiler and lint will do most of the work for you.

Admittedly I've only ever used two 36-bit platforms, and only one of them
was 1s-complement, so my porting experience is mostly limited to power-of-
two word sizes... but at least C makes an attempt at hiding those details:
if I never have to decide whether some "BIN FIXED(35)" really *needed* to
be 36 bits wide again it'll be too soon. Whoever made it so easy to
microspecify data types in PL/I should be shot.

At least Intel didn't pick up that insanity in PL/M. Porting all that code
from PL/M on RMX-86 to C on SunOS and Digital UNIX was tough enough. Even
WITH piles of automated translation code.

--
In hoc signo hack, Peter da Silva <peter@baileynm.com>
 `-_-'   "Heb jij vandaag je wolf al geaaid?"
  'U`
         "Tell init(8) to lock-n-load, we're goin' zombie slaying!"

>Megan wrote:

> Jerome Fine <jhfine@idirect.com> writes:
>
> >Stuart, if you would think first and reply later, you might realize that my
> >observation about the order of the fields in the DATE value had little to
> >do with Y2K problems and almost everything to do with a natural sort
> >order.  Even in the DIR utility, the 3 fields had to be re-ordered when
> >the user eventually was allowed to:   "DIR/SORT:DATE"
> >Why not have just done the order of the fields for such a situation
> >in the first place.  I do realize that the command became available
>
> That is perfect 20/20 hindsight.  It does no good.  The fact that a
> use was found for needing it in a different format doesn't mean a
> thing, since someone could just have easily found a use for the data
> in the form in which it was designed.

Jerome Fine replies:

I think in programming, it is also called instinct.  Knowing when to
set up code in a certain manner so that it will work well in 10 years
is only developed as an artistic sense of what seems the correct
way to do something as opposed to the wrong way.  Most of
that code I have seen in RT-11 was in the former category.
But in a few cases (and I have likely had to release a few such
abominations myself when a bean counter accountant decided
that tax considerations dictated the release schedule as
opposed to when the job was actually done - which meant
that the final cost of completing the work out of town was
5 time higher), the stupid errors were just plain stupid.  And
in some cases, even though the release notes said the error
(which had existed for over 5 years) had been corrected, the
bug was still there.

> >Plus your point of view is the very reason that I hold the computer
> >industry in such low regard with respect to how both management
> >and programmers think about planning for future problems.  At any
> >time up to 1980, all of RT-11 could have been made Y2K compliant
> >with so little effort that it dismays me as to why it was not done.
> >Even as late as V5.4G in December 1988, a Y2K effort would
> >have proven that DEC really cared about their users and realized
> >that just because other companies were waiting (a game that DEC
> >had played in the past - was it OS/8 with the PDP-8?) to implement
> >Y2K solutions far ahead of the need, DEC could have done RT-11
> >far ahead of time.  By 1988, I had already pointed out to a major
> >customer of mine at the time (one which I still have) that Y2K
> >modifications were already required for systems which were
> >estimated to still be needed in 2008.  Done at the time, the cost
> >would have been about 5% of what was needed to eventually
> >use a PC and completely re-write the code.
>
> Having been part of the RT-11 development team for almost 15 years,
> I can tell you that over the years, y2k support was never even asked
> for by the users!  If it was so important, and any idiot should have
> done it correctly and should have seen a need for it, then why did
> so many users fail to even ask for it.

Since this customer I referred to needed very high quality work done,
their QA department was rather important.  In some cases, a bug
in the code which might be as unlikely as one chance in 100 trillion
had the potential to kill 10 million people.  Or if the chance was only
one in 10 million and a person could be injured, that was still considered
too important to ignore.  As opposed to some companies who even
suppressed an event in which a person was fatally injured due to
a software malfunction triggered by an operator error, or at least
that is how I hear the incident was reported.  And how is it that the
companion OS called TSX-PLUS had the Y2K code added in 1991?
And if Megan Gentry was not exposed to requests for Y2K code,
why were two major utilities made Y2K compliant in V5.6 and
many, if not all, of the subroutines in SYSLIB.OBJ were made
Y2K compliant as well.  I notice that you included my reference
to this aspect later in your responses, but you totally ignore that
V5.6 had substantial Y2K compliant work done.  WHY?
And when was V5.6 actually ready for release.  If the community
that had beta versions were allowed to comment as to when the
actual V5.6 that was released and the beta versions that were out
in the field were substantially the same, there might be a bit of
a discrepancy in the dates - I understand that the official V5.6
release date was August 1992.

As for users not asking for Y2K compliance, I remember having
a conversation with Jim Metsch back in 1989 in which I
specifically asked two important questions:
(a) There was a bug in SRCCOM with regard to how
     much memory was available for an output buffer.
     2 pairs of instructions were in the wrong order
     so that when VBGEXE was used, the extra memory
     was still not available.  I asked if future versions
     of RT-11 could have the bug fixed if the corrections
     were sent.  The answer was one word, two letters
     and the first letter was "N".
(b) I asked when the code would be Y2K compliant
     and I was told there were no plans to do so at
     that time.

I also have read of what happened with OS-8 on the PDP-8
and the DATE corrections.  Are you still so sure that management
actually passed all the requests on to the development team?

> If they had, we would have put it on our lists of things to do which,
> in case you didn't know, *always* got pared down due to marketing or
> timeing constraints.

I think that you just emphasized the point I was trying to make.

> >The computer industry is, in my opinion, very much to blame
> >for taking such a short-sighted approach.  RT-11 in particular
> >was just one example of both the lack of foresight as well as
> >the attitude, especially by large companies like DEC and IBM
> >at the time, but also by smaller ones as well, that the user
> >could always be conned into paying - as seems likely the case
> >right now - to fix bugs in the code that should have been and
> >obviously, like RSTS/E, could have been fixed many years ago.
>
> see above.  Yes, it could have been fixed, if it was deemed
> important -- but it wasn't, not even by the users.

But, then why was any Y2K work done at all for V5.6?

> >So, you are not personally responsible for the lack of a present
> >Y2K in RT-11, but from other comments in your previous
> >post on this thread, it seems that you at least agreed with the
> >assessments in 1987 and 1993.  What I really don't understand
> >is why DEC did any Y2K work at all for V5.6 that was released
> >in August 1992 if that was the case.  If I were a betting person,
> >I would lay odds that much more Y2K work was done at the
> >time which did not make the V5.6 release and that the developers
> >figured that the next and final release in 1995 would provide
> >job security for another 3 years.  Except that sales of RT-11
>
> And you would lose... I was part of that final release, V5.6...
> and what was in V5.6 was what was available.  There wasn't
> any code held back for V5.7 (or v5.6a, or whatever).  We didn't
> have the time to do *extra* code, let alone the code which was
> required to fulfill the goals for the V5.6 release.  Yes, we
> hoped that we would be working on a V5.7, but we also doubted
> it since we were ramping up at that time also doing support of
> Ultrix/{Vax,Mips}

Why not keep at least 2 or 3 people working on RT-11?  Unless
sales of V5.5 were so bad by 1992 that management figured that
V5.6 would not improve the situation.

> >had fallen so much at that point since the previous release of
> >V5.5 in October 1989 that DEC decided to and effectively
> >did disband the whole RT-11 development team just at the
> >point that V5.6 was being released in 1992 - from what I
> >have heard.  The only thing that would convince me otherwise
> >would be the sales figures and profit for the RT-11 group
> >for the 10 years from 1982 to 1992.  Since you, and by now
> >no one else has either, don't have that information for the
> >now bought-out DEC (which could therefore not hurt DEC
> >anymore), the discussion is likely best stopped right here.
>
> I do remember that during a part of the early and mid 80s, we
> were the highest selling of the -11 OSes.  We regularly checked
> the charts being kept by a group up on ML5-5 at the time.

It is interesting - you answer the questions in a manner that
doesn't contain any numbers, so it can't be checked.  And you
totally ignore the important part of the question - how many
V5.6 H-kits, and all the other QJ013-XX products,
were being shipped for each month starting in 1985 to 1995?
I agree you don't know the exact numbers, but I hardly think
that a release of such numbers could hurt DEC anymore.
So even a relative number would be useful.  If I were a betting
person, I would lay odds that sales of RT-11 products slumped
in 1991 or before and V5.6 was released by the skin of its teeth.

> >So while I have been involved with RT-11 for more than 20
> >years, all the way back to V2.0 of RT-11, I have only been
> >saddened at the way DEC seem to milk RT-11 at the end.
> >But I know of one user who got even in the years from 1986
> >to 1988 when DEC was releasing a new version almost every
> >3 or 4 months.  This institution bought the update service for
> >RT-11 products for 2 years to be supplied on RL02 disk packs.
> >Like clockwork every 3 or 4 months, DEC shipped 2 RL02
> >disk packs worth more per year than the cost of the update
> >service.  I remember hearing that V5.4F and V5.4G were
> >only to fix bugs.  In 1988, that institution decided that the
>
> Mostly, the 'a', 'b', ... 'g' releases were bug fix releases.
> They were NEVER, to my knowledge, new support releases.  That
> was reserved for minor-number releases or, more commonly,
> major-number releases.
>
> Please, don't presume to know what was going on behind the
> scenes.

Please define the category of new support or only as a bug fix for:
(a) Partitions in MSCP disk drives - V5.3 1985
(b) MSCP MU tape drive - V?.?
(c) 64 partition in MSCP disk drives - V5.5 1989
(d) I/D space for programs as a minor-number release V5.6 1992
     Was that done as RSX-PLUS in RSX?

I don't know what was going on behind the scenes - why don't
you supply us with a few of the interesting items?

In general, I have always thought that the RT-11 development team
did a superb job under the constraints that they seemed to be
working under - a management team that was unresponsive
to users to start with and interested, along with upper DEC
management, only in canning the OS at the end.  RT-11
deserved better.  It was and still does have potential which
I doubt will even be realized.

Sincerely yours,

Jerome Fine
Year 2000 Solutions for Currently Running RT-11 Applications
(Sources not always required)

In article <701msk$ksc@web.nmti.com>,
Peter da Silva <peter@baileynm.com> wrote:
>Since the problem isn't "recompiling", it's finding where to add the two
>extra digits, I'm not sure that you're making the point you think you're
>making. If a bigger time_t is something that scares you, then you haven't
>done enough ports with MUCH bigger problems than that.

I hope you're picturing a port to a different OS with a bigger time_t,
because if you're thinking of duplicate libraries and/or system calls
existing side by side on the same system with different sizes of time_t,
it isn't going to be as much fun as you make it sound.

>I have a bigger problem with the buggers who wrote code that "knows" an
>integer and a pointer are the same size. Actually, my biggest gripe is
>with compiler vendors who come up with "long long" for their 64-bit ports
>because they don't have the guts to break all the "all-the-world's-a-VAX"
>code out there.

What C really needed was a way to just say straight out "I want an unsigned
integer of at least ___ size", like the FORTRAN INTEGER*2/INTEGER*4/etc.
but maybe extended a little.  Instead we get in this silly situation where
different compilers of the same language for the same machine, use different
sizes for basic data types, you can't count on anything.

>But then that's something I've been griping about since 1980 when I first
>tried to port PDP-11 code to 4.1BSD. They should have made "long" a 64
>bit value on the first VAX port, and the issue would never have arisen.
>
>(instead we'd be griping about the 128 bit problem now)

Integers will *never* be big enough.  There are really two main categories of
things in computers:  (a) a bunch of things, and (b) a potentially infinite
number of things.  Using your favorite size of integer to count (a) isn't a
problem, but people keep thinking that the *next* time we increase the word
size it will be enough for (b)...  Some things *should* be done with multiple
precision math!

John Wilson
D Bit

Peter da Silva wrote:
>
> In article <362388D7.4E2BA351@trailing-edge.com>,
> Tim Shoppa  <shoppa@trailing-edge.com> wrote:
> >I would imagine that a lot of COBOL programmers in the 1960's
> >had the same attitude towards the Y2K problem - "Oh, somebody
> >will fix that later ... all they have to do is just add two more
> >digits to the year field and recompile!"
>
> Since the problem isn't "recompiling", it's finding where to add the two
> extra digits, I'm not sure that you're making the point you think you're
> making. If a bigger time_t is something that scares you, then you haven't
> done enough ports with MUCH bigger problems than that.
> I have a bigger problem with the buggers who wrote code that "knows" an
> integer and a pointer are the same size.

I've dealt with that issue as well.  I'm not necessarily saying that
the Y2038 problem will be harder or easier than integer/pointer
equivalence
issue - this is something that will clearly vary on a case-by-case
basis,
just as solutions and difficulties of Y2K fixes vary on a case-by-case
basis.

I've been trying to steer the discussion away from the techincal
solutions - which I'll agree exist already, and certainly could be
implemented right now on may platforms - and towards the fundamental
attitude that "Yeah, the way we released it it'll break in year nnnn,
which
is only a few decades away, but it'll be easy for somebody to fix it in
the
future."

You're pointing out to me that Unix and C programmers have the tools and
ability to avoid the Y2038 problem, if they so choose.  Yet platforms
and packages which die horribly in the beginning of 2038 are being sold
and pushed as the preferred solutions now, and few (if any) companies
have any detailed statments available on the Y2038 issue and exactly
when
and how they'll deal with it.  I see the situation as entirely
analogous to how the Y2K problem was thought of until it began
appearing in the headlines a couple of years ago: Cobol programmers
also had the tools and ability to avoid the Year 2000 issue 30 years
ago, but software with the Y2K problem continued to be the rule, rather
than the exception, for a very long time.  Again, everyone knew it
would be a big problem in the future, but that didn't mean that anyone
actually went to the effort to fix it before it became a big problem.

I'm not saying that this attitude is morally wrong, or anything that
strong.  I fear that Megan took it as an insult when I gave an example
of this sort of attitude in RT-11 development in the early 1990's
regarding the Y2K problem in RT-11 5.6, and I certainly never intended
my example to insult anyone's skills or attitudes.
I'm just saying that this attitude is extremely common and widespread,
and
exactly what got us into the Y2K situation in the first place.

--
 Tim Shoppa                        Email: shoppa@trailing-edge.com
 Trailing Edge Technology          Voice: 301-767-5917
 7328 Bradley Blvd                 Fax:   301-767-5927
 Bethesda, MD, USA 20817

In article <3624b343.0@news.wizvax.net>, John Wilson <wilson@dbit.com> wrote:
>In article <701msk$ksc@web.nmti.com>,
>Peter da Silva <peter@baileynm.com> wrote:
>>Since the problem isn't "recompiling", it's finding where to add the two
>>extra digits, I'm not sure that you're making the point you think you're
>>making. If a bigger time_t is something that scares you, then you haven't
>>done enough ports with MUCH bigger problems than that.

>I hope you're picturing a port to a different OS with a bigger time_t,

If "a different OS" includes "the same OS except for a bigger time_t", yes.

>because if you're thinking of duplicate libraries and/or system calls
>existing side by side on the same system with different sizes of time_t,
>it isn't going to be as much fun as you make it sound.

I've been through this for the change to off_t between 4.3 and 4.4BSD,
including patching the kernel so that the 4.4 Netscape binary would run
on the 4.3 system. I think I've still got the web page I set up for that
patch online somewhere. New system calls were introduced for the new sized
objects, with the old ones stubbing through to the new ones. New libraries
that called the new calls with the original names, with a new major
version number. It's not really difficult if you take a minimal amount of
care... it's conceptually simple and the process can be highly automated.

--
In hoc signo hack, Peter da Silva <peter@baileynm.com>
 `-_-'   "Heb jij vandaag je wolf al geaaid?"
  'U`
         "Tell init(8) to lock-n-load, we're goin' zombie slaying!"

Jerome Fine <jhfine@idirect.com> writes:

> I think in programming, it is also called instinct.  Knowing when to
> set up code in a certain manner so that it will work well in 10 years
> is only developed as an artistic sense of what seems the correct
> way to do something as opposed to the wrong way.

Well.. I work from the specifications my clients provide (the expected
service life of a system is significant in determining how cost-effective
it is) and none of them had any idea they'd still be on the same platform
10-15 years later, nor did I.  The PDP-11 is a pretty rare exception to
what usually happens in the world of data processing...

> > Having been part of the RT-11 development team for almost 15 years,
> > I can tell you that over the years, y2k support was never even asked
> > for by the users!

That's true although I was also using TSX and when S&H added the
extended date code they said it was per what DEC was planning so
having not even thought about it much prior to that I figured it
was already in progress - not that I'd have requested it in any
case at that point in time..

> And how is it that the
> companion OS called TSX-PLUS had the Y2K code added in 1991?

TSX uses all of RT-11's utilities and libraries.  S&H only had to add
a few lines of new code to impliment their end of it all.  It couldn't
have taken more than an hour or so.

> Why not keep at least 2 or 3 people working on RT-11?  Unless
> sales of V5.5 were so bad by 1992 that management figured that
> V5.6 would not improve the situation.

All this speculation about the past doesn't mean much now - lots of
DEC's marketing will forever remain a mystery to me (although their
engineering has always been way above average) but Mentec has people
working on it and from what I can see they have handled it all quite
well.  Problem solved...

Billy Y..

>billy@mix.com wrote:

> Jerome Fine <jhfine@idirect.com> writes:
>
> > Eventually, I hope to be able
> > to release a PATH  HANDLER (ala the MS-DOS  PATH name
> > or the VMS logical name list).
>
> Bill Walker's UCL+ already does this - available from the usual
> places (Uppsala University, Sunsite, etc)...
>
> Billy Y..

Jerome Fine replies:

Thanks very much.  I will look it up ASAP.  Can you please
pin down which SIG tape it might have been on?

However, what I was really referring to was a pseudo device
handler which could be used like the VMS logical name list.
In that regard, for example, any compiler or other language
processor could use PH5: to specify the directory of a set
of source files.  As in VMS, the .LOOKUP would automatically
become recursive and look for the specified file(s) in a
specified set of directories in the specified order.  Since this
feature could also be used for just running programs, it would
act just like the PATH name in MS-DOS.  I agree that a
UCL+ with such a feature is great, but I had the language
processors more in mind in the case of an application
that would be produced from hundreds of files.  Thus:
PH5:  =>  LD5:,  LD3:,  DU6:,  DU3:
If the primary production files were held on DU3:
as a WRITE  PROTECTED disk drive and a
secondary set of finalized (ready for production)
source files were held on DU6:, then LD3: and LD5:
could be test directories at various levels of
implementation.  I think this is the essential nature of how
the logical name list is handled in VMS.  The the same
command file with:   "ASSIGN   PH5:   SRC:" could
be used to drive the re-build of the newest test version
of the application.  And PH6: might be used to do the
LINK.  The only restriction would be that the PATH
(pseudo device) HANDLER would be restricted to
doing only the .LOOKUP request.  All other requests
using PH: would be handled in the same manner as
the stub code contained in the handler and could be
similar to how the NL: handler did the requests or
just give an error return.  The key point is that only the
.LOOKUP request would be able to generate the
recursive searches of the specified directories.

While I agree that there is likely very little demand for
such a feature at this point in the history of RT-11,
10 years ago it would have been very helpful.  And
20 years ago when disk storage space was at such
a premium, a PH: might have been seen as a
necessity - just as LD: is now.

Sincerely yours,

Jerome Fine
Year 2000 Solutions for Currently Running RT-11 Applications
(Sources not always required)

In article <36249640.328249D1@trailing-edge.com>,
Tim Shoppa  <shoppa@trailing-edge.com> wrote:
>I've been trying to steer the discussion away from the techincal
>solutions - which I'll agree exist already, and certainly could be
>implemented right now on may platforms - and towards the fundamental
>attitude that "Yeah, the way we released it it'll break in year nnnn,
>which is only a few decades away, but it'll be easy for somebody to
>fix it in the future."

The Y2038 problem is not at all similar to the Y2K problem. Why? Y2K
problems have many causes, and there's no unique tag that can be used
to track them down, so they have to be taken on a case-by-case basis.

It's like the integer-size problem, in that fixing it is a completely
mechanical process of tracing time_t values. You could do it with an
emulator and tag bytes and a code coverage tool. You could fix it with
the same tool. It doesn't require human intervention at any point.

I've had arguments with people working on DOS and Xenix code, pointing out
16-bit dependencies, and then people writing Sun or 386 code, where they
had 32-bit dependencies. The integer-size problem shows the same mindset,
and it's much much more pervasive than the time_t problem or even the Y2K
problem... it just doesn't hit everyone at once.

--
In hoc signo hack, Peter da Silva <peter@baileynm.com>
 `-_-'   "Heb jij vandaag je wolf al geaaid?"
  'U`
         "Tell init(8) to lock-n-load, we're goin' zombie slaying!"

Jerome Fine <jhfine@idirect.com> writes:

> Can you please
> pin down which SIG tape it might have been on?

It's in the 11S109 "Best of RT" (Spring, 1989) SIG tape but a more recent
version is available by anonymous ftp from -

  ftp.update.uu.se:/pub/pdp11/rt/uclpls/*

or with a bit more typing here in North America at -

  sunsite.unc.edu:/pub/academic/computer-science/history/pdp-11/rt/billy/
   uclpls_dsk/*

Billy Y..

Megan wrote:
> We essentially has a list of things which were deemed *required* for
> V5.6, and we rated them according to riskyness and time to implement.
> After all that was done, we presented our time estimates.  The response
> to this was a specification of how long we had... which was about half
> the time required (if I remember correctly).

Knowing the differences between RT-11 5.5 and 5.6, I have always been
surprised that 5.6 wasn't given an integer-number
(i.e. 6.0) release number.  The elimination of an entire monitor,
the introduction of several new monitors, split I&D support, and many
other *major* accomplishments, accompanied by the necessary
modifications
to the system macro library necessary to support the new features.
By no means was it just a "service" release consisting of some bugfixes
and a few new features - it was clearly an astonishing amount of effort.

> So lots of stuff had to go.

Which raises the question: what wasn't put in?  And what do people now
want to be put into RT-11 5.8 that isn't in 5.7 - i.e. what's the
"wish list"?

--
 Tim Shoppa                        Email: shoppa@trailing-edge.com
 Trailing Edge Technology          Voice: 301-767-5917
 7328 Bradley Blvd                 Fax:   301-767-5927
 Bethesda, MD, USA 20817

Jerome Fine <jhfine@idirect.com> writes:

>Stuart, if you would think first and reply later, you might realize that my
>observation about the order of the fields in the DATE value had little to
>do with Y2K problems and almost everything to do with a natural sort
>order.  Even in the DIR utility, the 3 fields had to be re-ordered when
>the user eventually was allowed to:   "DIR/SORT:DATE"
>Why not have just done the order of the fields for such a situation
>in the first place.  I do realize that the command became available

That is perfect 20/20 hindsight.  It does no good.  The fact that a
use was found for needing it in a different format doesn't mean a
thing, since someone could just have easily found a use for the data
in the form in which it was designed.

>Plus your point of view is the very reason that I hold the computer
>industry in such low regard with respect to how both management
>and programmers think about planning for future problems.  At any
>time up to 1980, all of RT-11 could have been made Y2K compliant
>with so little effort that it dismays me as to why it was not done.
>Even as late as V5.4G in December 1988, a Y2K effort would
>have proven that DEC really cared about their users and realized
>that just because other companies were waiting (a game that DEC
>had played in the past - was it OS/8 with the PDP-8?) to implement
>Y2K solutions far ahead of the need, DEC could have done RT-11
>far ahead of time.  By 1988, I had already pointed out to a major
>customer of mine at the time (one which I still have) that Y2K
>modifications were already required for systems which were
>estimated to still be needed in 2008.  Done at the time, the cost
>would have been about 5% of what was needed to eventually
>use a PC and completely re-write the code.

Having been part of the RT-11 development team for almost 15 years,
I can tell you that over the years, y2k support was never even asked
for by the users!  If it was so important, and any idiot should have
done it correctly and should have seen a need for it, then why did
so many users fail to even ask for it.

If they had, we would have put it on our lists of things to do which,
in case you didn't know, *always* got pared down due to marketing or
timeing constraints.

>The computer industry is, in my opinion, very much to blame
>for taking such a short-sighted approach.  RT-11 in particular
>was just one example of both the lack of foresight as well as
>the attitude, especially by large companies like DEC and IBM
>at the time, but also by smaller ones as well, that the user
>could always be conned into paying - as seems likely the case
>right now - to fix bugs in the code that should have been and
>obviously, like RSTS/E, could have been fixed many years ago.

see above.  Yes, it could have been fixed, if it was deemed
important -- but it wasn't, not even by the users.

>So, you are not personally responsible for the lack of a present
>Y2K in RT-11, but from other comments in your previous
>post on this thread, it seems that you at least agreed with the
>assessments in 1987 and 1993.  What I really don't understand
>is why DEC did any Y2K work at all for V5.6 that was released
>in August 1992 if that was the case.  If I were a betting person,
>I would lay odds that much more Y2K work was done at the
>time which did not make the V5.6 release and that the developers
>figured that the next and final release in 1995 would provide
>job security for another 3 years.  Except that sales of RT-11

And you would lose... I was part of that final release, V5.6...
and what was in V5.6 was what was available.  There wasn't
any code held back for V5.7 (or v5.6a, or whatever).  We didn't
have the time to do *extra* code, let alone the code which was
required to fulfill the goals for the V5.6 release.  Yes, we
hoped that we would be working on a V5.7, but we also doubted
it since we were ramping up at that time also doing support of
Ultrix/{Vax,Mips}

>had fallen so much at that point since the previous release of
>V5.5 in October 1989 that DEC decided to and effectively
>did disband the whole RT-11 development team just at the
>point that V5.6 was being released in 1992 - from what I
>have heard.  The only thing that would convince me otherwise
>would be the sales figures and profit for the RT-11 group
>for the 10 years from 1982 to 1992.  Since you, and by now
>no one else has either, don't have that information for the
>now bought-out DEC (which could therefore not hurt DEC
>anymore), the discussion is likely best stopped right here.

I do remember that during a part of the early and mid 80s, we
were the highest selling of the -11 OSes.  We regularly checked
the charts being kept by a group up on ML5-5 at the time.

>So while I have been involved with RT-11 for more than 20
>years, all the way back to V2.0 of RT-11, I have only been
>saddened at the way DEC seem to milk RT-11 at the end.
>But I know of one user who got even in the years from 1986
>to 1988 when DEC was releasing a new version almost every
>3 or 4 months.  This institution bought the update service for
>RT-11 products for 2 years to be supplied on RL02 disk packs.
>Like clockwork every 3 or 4 months, DEC shipped 2 RL02
>disk packs worth more per year than the cost of the update
>service.  I remember hearing that V5.4F and V5.4G were
>only to fix bugs.  In 1988, that institution decided that the

Mostly, the 'a', 'b', ... 'g' releases were bug fix releases.
They were NEVER, to my knowledge, new support releases.  That
was reserved for minor-number releases or, more commonly,
major-number releases.

Please, don't presume to know what was going on behind the
scenes.

					Megan Gentry
					Former RT-11 Developer

+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL   | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group |          (home):  mbg!world.std.com |
| Compaq Computer Corporation    | addresses need '@' in place of '!'  |
| 110 Spitbrook Rd. ZK03-2/T43   | URL:     http://world.std.com/~mbg/ |
| Nashua, NH 03062               | "pdp-11 programmer - some assembler |
| (603) 884 1055                 |  required." - mbg                   |
+--------------------------------+-------------------------------------+

Jerome Fine <jhfine@idirect.com> writes:

> The only thing that would convince me otherwise
> would be the sales figures and profit for the RT-11 group
> for the 10 years from 1982 to 1992.

I recall John Crowell getting the 100,000th RT-11 license
somewhere in the mid-1980s.  I haven't checked lately but
in the recent past Tektronix was still selling RT-11 based
videotape edit systems too.

Billy Y..

In article: <700ae7$aea@web.nmti.com>  peter@baileynm.com (Peter da Silva) writes:
>
> In article <3623696C.4DDC6F13@trailing-edge.com>,
> Tim Shoppa  <shoppa@trailing-edge.com> wrote:
> > (Reminds me of all
> >the C/Unix applications being written today that will die horribly
> >in the beginning of 2038.)
>
> Only the ones that write structs direct to disk in binary form.
>
> The rest will just take a recompile.


The 4 or 5 C applications I've looked at (various operating systems) would have
all failed - as in exhibited incorrect behaviour with varying degrees of seriousness
of consequences - on Jan 1st 2000. So I don't think I'll worry about 2038 just yet.


--
Roger Barnett
Natron Software Maintenance Ltd, York, England

"OpenVMS is today what Microsoft wants Windows NT v8.0 to be"
Compaq Web Site, 22-Sep-1998   (but no longer there)

Tim Shoppa <shoppa@trailing-edge.com> writes:

>Peter da Silva wrote:

>You're pointing out to me that Unix and C programmers have the tools and
>ability to avoid the Y2038 problem, if they so choose.  Yet platforms
>and packages which die horribly in the beginning of 2038 are being sold
>and pushed as the preferred solutions now, and few (if any) companies
>have any detailed statments available on the Y2038 issue and exactly

The point is that everyone focuses on a specific year as the failure
year.  Yes, Unix has the 2038 date, RT had the 2004 date, other systems
had some other date which was the end of their integral epoch.  The
problem is that things start breaking for various reasons at different
times.  Y2K is simply a very noticable one... but I've also noticed
comments in other OSes about odd years which weren't the end of an
epoch, but were the end of when the routine worked properly.

Also, once it was cast in stone, and the decision (for RT) was made
to keep each release as backward compatible as possible, it became
hard to change it.  In fact, the decision to change an interface
(on those rare occasions when we did), was based on how integral
the interface or data structure was to the majority of programs.
If it resulted in more than (some variable threshhold) of rebuilds,
we had to reject it and find some other way, such as having both
interfaces available, or make a data-structure dual-modal.

>I'm not saying that this attitude is morally wrong, or anything that
>strong.  I fear that Megan took it as an insult when I gave an example
>of this sort of attitude in RT-11 development in the early 1990's
>regarding the Y2K problem in RT-11 5.6, and I certainly never intended
>my example to insult anyone's skills or attitudes.

I'll admit it did feel that way to me... I was there 'at the end', and
some things which occurred were not pleasant.

We essentially has a list of things which were deemed *required* for
V5.6, and we rated them according to riskyness and time to implement.
After all that was done, we presented our time estimates.  The response
to this was a specification of how long we had... which was about half
the time required (if I remember correctly).  So lots of stuff had to
go.

Some of the Y2K stuff which was already in the V5.6 release was done
simply because someone was in the module to do something else.  But
it wasn't assured to be tested.  So, for example, one of the modules
had the code, but it was conditionalized out.  (I know of only one
case of that in the V5.6 sources).

Finally, I *had* to avoid talking about specific sales levels, since that
is not my place to report.  If the corporation wished to report it, it
was up to them.  Even numbers from the past -- I don't believe that I
have the authority to be specific.

We did have a great team of people over the years... One developer, after
having been in the group for a while, commented to me that, "When [he]
worked at a prior job, *he* was the RT guru.  But when [he] joined the
RT development team, [he] was just one of a bunch of gurus."

I will always have very fond memories of the time I spent being a member
of that team.

					Megan Gentry
					Former RT-11 Developer

+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL   | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group |          (home):  mbg!world.std.com |
| Compaq Computer Corporation    | addresses need '@' in place of '!'  |
| 110 Spitbrook Rd. ZK03-2/T43   | URL:     http://world.std.com/~mbg/ |
| Nashua, NH 03062               | "pdp-11 programmer - some assembler |
| (603) 884 1055                 |  required." - mbg                   |
+--------------------------------+-------------------------------------+

peter@baileynm.com (Peter da Silva) writes:

>I've had arguments with people working on DOS and Xenix code, pointing out
>16-bit dependencies, and then people writing Sun or 386 code, where they
>had 32-bit dependencies. The integer-size problem shows the same mindset,
>and it's much much more pervasive than the time_t problem or even the Y2K
>problem... it just doesn't hit everyone at once.

I've always had problems with the size dependencies inherent in C.  And
the fact that what I thought were fixed sizes turned out not to be has
been the biggest problem.  I agree with someone else's comment that they
should simply have had 'intxx' mean an integer of an arbitrary number
of bits (I'd even accept that arbitrary number being some multiple of
an integral number).

					Megan Gentry
					Former RT-11 Developer

+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL   | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group |          (home):  mbg!world.std.com |
| Compaq Computer Corporation    | addresses need '@' in place of '!'  |
| 110 Spitbrook Rd. ZK03-2/T43   | URL:     http://world.std.com/~mbg/ |
| Nashua, NH 03062               | "pdp-11 programmer - some assembler |
| (603) 884 1055                 |  required." - mbg                   |
+--------------------------------+-------------------------------------+

On Wed, 14 Oct 1998 18:15:05 -0400, Jerome Fine <jhfine@idirect.com>
wrote:
<snip>
>However, what I was really referring to was a pseudo device
>handler which could be used like the VMS logical name list.

<snip>
>While I agree that there is likely very little demand for
>such a feature at this point in the history of RT-11,
>10 years ago it would have been very helpful.  And
>20 years ago when disk storage space was at such
>a premium, a PH: might have been seen as a
>necessity - just as LD: is now.

All the RT-11 compatible operating systems produced by HAMMONDsoftware
(STAR-eleven, SHAREeleven, SHAREplus and VRT) had exactly that
functionality 10 and (almost) 20 years ago. And you're right, we and
our customers couldn't live without it. (I believe we had the
functionality before VMS.)

As for other people seeing it as a necessity, I'm not so sure. I seem
to remember doing a little product with this functionality for RT-11,
but it didn't sell a lot -- in fact, I don't think we sold a single
copy. Perhaps "necessity" gets redefined by a price tag.

But then again, I still don't believe that millions of DOS (and
Windows) users didn't feel the need for logical names. I couldn't do
anything useful with the system until I implemented a shell and a
front-end strategy to put them back in. But even logical names are
clearly not a necessity. 

BTW: Under RT-11 it's not necessary to have the logical names mapped
via RT-11's name table because one can always hook the EMT's directly
(there are even street legal ways to do this via the E16 list,
although the flow-chart might bring tears to your eyes).   


ian hammond
=======================================
"mothers are an invention of necessity"

>ian hammond wrote:

> On 12 Oct 1998 07:44:22 PDT, Stuart Brook <sbrook@concentric.net>
> wrote:
>
> >Jerome ...
> >
> >Your naivte is showing again ...
> >
> >Hell, in 1972, nobody ever thought that PDP-11s would be around in 2000!
> >Why should they have designed for it ?  There was probably some valid
> >reason for the structure of the date word.  Heavens, they probably
> >didn't even think *they'd* be around in 2000!  Certainly nobody was
> >thinking 2000 then!
>
> I guess you are referring to this passage in Jerome's post:
>
>   Incidentally, of all the superb things done in RT-11, who was the
>   fellow back in 1972 who dreamed up the order of the fields
>   in the DATE value as:  MONTH / DAY OF MONTH / YEAR??
>
> It took me ages to work out the utterly obvious about this date
> layout: it's just the U.S. date format, set in silicon.
>
> The author probably had a non PDP-11 background, since it is cast from
> right to left, rather than from left to right, which would have been:
>
>         YEAR / DAY-OF-MONTH / MONTH
>
> But the really crazy bit was that it had an unused two-bit field,
> leaving the date expressed in 14 bits:
>
>         UNUSED / MONTH / DAY-OF-MONTH / YEAR
>
> Thus, to come a little closer to answering the question "Who was the
> fellow back in 1972", I would suggest it was one of the two or three
> programmers who came across from the 12-bit PDP-8 OS-8 group. They
> were probably out of their mind with joy at escaping the 12-bit limit.
> Indeed, they might been a little lost in 16-bits. And the PDP-8 did
> number bits from right to left.

I think I understand your explanation, it is the context I feel I
am missing - is your answer meant to be humorous or tongue
in cheek?  I would have hoped that by the time anyone had even
a week of programming experience on the PDP-11, they would
surely know the order of the bits.  Perhaps since I had already been
programming for 50,000 hours by the time I had met a PDP-11
for the first time, I likely took to the instruction set like a duck to
water.  And even the prior experience (some 15 years earlier)
of working with 36 bits systems or (some 5 years earlier) with
64 bit systems have not prepared me for the utter simplicity
of working with the PDP-11 instruction set.

> But the PDP-8 developers would have known about the date problem. I
> don't know what the OS-8 date format was, but it must have been pretty
> small because it ran out of space years ago. The story goes that DEC
> released a beta version with the extended date to a few select sites.
> A few months later DEC put the final version on the market. To their
> surprise, almost nobody purchased the new version, even though they
> needed it desperately to fix the date problem. The penny finally
> dropped that the PDP-8 community had already developed their own
> informal distribution mechanism that did not require DEC's assistance.

I was given essentially the same explanation about 10 years ago by
a fellow from whom I purchased a car load of old Qbus compatible
hardware.  He wanted the write-off for accounting purposes as he
was shifting to non-PDP-11 systems.  I wonder if history is repeating
itself.  I was told that with OS-8, the users had requested DEC to
fix the bug so often that the users finally gave up and some of the
gurus in OS-8 just did it themselves.  Finally, when it was past the
time when the fix was needed, DEC woke up and did the official
patch.  Evidently, the needs of the user community did not filter
up through the grape vine and the management of the group was
such that no one bogged down in the details of doing bug fixes
noted that it was already too late for the DATE problem when
it was finally handled.  These days, commercial companies insist
that such problems be fixed well in advance and some have already
done so.

> As to the actual name of the developer? Years ago I had the names of
> the original developers, garnered from the V1 sources, but I guess
> those floppies have had a slow but noble disintegration somewhere.
> Ashes to Ashes. Rust to Rust.

Do you still have the floppies - sometimes the date can still be read.
Please don't toss them!!

> ian hammond
> ==============================================================
> "things are more like they are now than they ever were before"

This phrase seems familiar - where did the quote come from?
Is it in the RT-11 sources?  And who made the statement?

> But what did you do in a company that had already worked out that 16
> bits was too small, even before the machine was finally released?

I don't quite understand?  Is this in reference to the PDP-11?
For many applications such as process control, the PDP-11 was
an ideal system.  The cost was OK for the time when DEC was
selling it and the low volume/high market model of selling was
how all the other computers were being sold as well.  By low
volume, I am referring to the millions of systems per month
of today.

Sincerely yours,
Year 2000 Solutions for Currently Running RT-11 Applications
(Sources not always required)

In article <F0uJ2A.3zo@world.std.com>, Megan <mbg@world.std.com> wrote:
>peter@baileynm.com (Peter da Silva) writes:
>>I've had arguments with people working on DOS and Xenix code, pointing out
>>16-bit dependencies, and then people writing Sun or 386 code, where they
>>had 32-bit dependencies. The integer-size problem shows the same mindset,
>>and it's much much more pervasive than the time_t problem or even the Y2K
>>problem... it just doesn't hit everyone at once.

>I've always had problems with the size dependencies inherent in C.

I haven't found a better language for *avoiding* size dependencies, IF
YOU WRITE YOUR CODE AWARE THAT NOT ALL COMPUTERS HAVE THE SAME WORD SIZE.

In fact the more the language specifies the size of an object, the more
trouble I've had porting code. PL/I, where you specify it down to the bit
level, is among the worst. PL/M and Fortran-IV, where you only specify the
size in terms of words or bytes, are better. In C you can completely
isolate the word size dependencies to a header file where you define your
size-specific types (int32, unsigned16, etc) and let the compiler pick an
appropriate word size for the rest.

Because 99% of the time, the size you want depends on so many other things
that are more closely related to the computing environment than the code
you're working on. Having the default sizes driven by the hardware's
programming model means you don't end up with code that requires multiple
word arithmetic for all your integer calculations (because that's what
you need to run Unisys 1100 code with 36-bit integers on a 32-bit machine)
or having your array indexes have to be rewritten (because all of a sudden
DCL OFFSET BIN(17) isn't enough)...

Good programming in languages that allow you to specify things that tightly
means you end up recreating the equivalent of the C type structure for all
your generic values anyway... having to know the sizes of things that closely
is the special case.

--
In hoc signo hack, Peter da Silva <peter@baileynm.com>
 `-_-'   "Heb jij vandaag je wolf al geaaid?"
  'U`
         "Tell init(8) to lock-n-load, we're goin' zombie slaying!"

In article <7050j4$ict@web.nmti.com>,
Peter da Silva <peter@baileynm.com> wrote:
>I haven't found a better language for *avoiding* size dependencies, IF
>YOU WRITE YOUR CODE AWARE THAT NOT ALL COMPUTERS HAVE THE SAME WORD SIZE.

Let me qualify this... I'm talking about system programming languages here
because that's what I do. In other domains you get to use [1] things like Lisp
and Smalltalk where types are derived from the class system, instead of
the hardware.

[1] Meaning, you should get to use. It's unfortunate that C is as good as
    it is... if it had been less successful at the system level it wouldn't
    have been picked up and misapplied so much in application software,
    and we would have avoided the dual horrors of C++ and Java [2].

[2] Hey, people, syntax matters. C syntax IS NOT GOOD for high level object
    oriented code, damnit.

--
In hoc signo hack, Peter da Silva <peter@baileynm.com>
 `-_-'   "Heb jij vandaag je wolf al geaaid?"
  'U`
         "Tell init(8) to lock-n-load, we're goin' zombie slaying!"

Tim Shoppa wrote:

> Knowing the differences between RT-11 5.5 and 5.6, I have always been
> surprised that 5.6 wasn't given an integer-number
> (i.e. 6.0) release number.  The elimination of an entire monitor,
> the introduction of several new monitors, split I&D support, and many
> other *major* accomplishments, accompanied by the necessary
> modifications
> to the system macro library necessary to support the new features.
> By no means was it just a "service" release consisting of some
> bugfixes
> and a few new features - it was clearly an astonishing amount of
> effort.

     When I asked the Developers this exact question (before 5.6 was
released), I was
essentially told that [and here I'm paraphrasing, these are my words and
interpretation]
"If Management Ever Knew We Were Doing A Major Release, They'd Never
Allow It".

     You are certainly correct that RT-11 5.6 is TOTALLY different from
RT-11 5.5.
Of the three 5.5 monitors, only two are present in 5.6, and four new
monitors came to
light.  Lots of things that I believe the Development Team wanted to do
did, in fact, get
done, though not all of the "bells and whistles" were added (for
example, the hooks for
making Supervisor libraries, and actually using Supervisor mode for
something, is there,
but you kind of have to "roll your own" to figure out how to get it to
work.)

     So it really should be RT-11 6.0.  Maybe (since the rumored 5.7 is
not yet out) the
next release could be labelled RT-11 6.1?  [I'm only 50% kidding ...]

Bob Schor
Last Known Chair, RT-11/TSX+ Working Group, US DECUS
Last Known (to me) DECUS Presenter of RT-11 5.6 Symposium material

Bob Schor <bschor@vms.cis.pitt.edu> writes:

>     When I asked the Developers this exact question (before 5.6 was
>released), I was essentially told that [and here I'm paraphrasing, these
>are my words and interpretation] "If Management Ever Knew We Were Doing A
>Major Release, They'd Never Allow It".

I can confirm that...

					Megan Gentry
					Former RT-11 Developer

+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL   | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group |          (home):  mbg!world.std.com |
| Compaq Computer Corporation    | addresses need '@' in place of '!'  |
| 110 Spitbrook Rd. ZK03-2/T43   | URL:     http://world.std.com/~mbg/ |
| Nashua, NH 03062               | "pdp-11 programmer - some assembler |
| (603) 884 1055                 |  required." - mbg                   |
+--------------------------------+-------------------------------------+

On 15 Oct 1998 14:30:56 GMT, Peter da Silva <peter@baileynm.com> wrote:
>In article <7050j4$ict@web.nmti.com>,
>Peter da Silva <peter@baileynm.com> wrote:
>>I haven't found a better language for *avoiding* size dependencies, IF
>>YOU WRITE YOUR CODE AWARE THAT NOT ALL COMPUTERS HAVE THE SAME WORD SIZE.
>
>Let me qualify this... I'm talking about system programming languages here
>because that's what I do. In other domains you get to use [1] things like Lisp
>and Smalltalk where types are derived from the class system, instead of
>the hardware.
>
>[1] Meaning, you should get to use. It's unfortunate that C is as good as
>    it is... if it had been less successful at the system level it wouldn't
>    have been picked up and misapplied so much in application software,
>    and we would have avoided the dual horrors of C++ and Java [2].
>
>[2] Hey, people, syntax matters. C syntax IS NOT GOOD for high level object
>    oriented code, damnit.

I'd even go so far as to say it is BAD for applications coding in general.
But how does one fight an entire educational system and product structure?

>
>--
>In hoc signo hack, Peter da Silva <peter@baileynm.com>
> `-_-'   "Heb jij vandaag je wolf al geaaid?"
>  'U`
>         "Tell init(8) to lock-n-load, we're goin' zombie slaying!"

jg
--
These opinions are my own and not necessarily those of Pebble In The Sky.
http://ourworld.compuserve.com/homepages/joel_garry   Remove nospam to reply.
mailto:joel_garry@compuserve.nospam.com  Available for Oracle DBA work.

On Wed, 14 Oct 1998 08:23:18 -0400, Jerome Fine <jhfine@idirect.com> wrote:

>>Megan wrote:

>> I do remember that during a part of the early and mid 80s, we
>> were the highest selling of the -11 OSes.  We regularly checked
>> the charts being kept by a group up on ML5-5 at the time.

Megan:

As one who was counted in that chart as an RT, I must say I only bought
the thing to upgrade it to RSTS.  I don't know what percentage of machines
that sort of thing happened on, but I knew of several - enough to think
of it as an ordinary occurrence.  Just like MS counts me, when I really
intend to only run Linux.

Jerome:

Incidentally, I always like the DECUS feedback sessions with developers,
and wish more companies would do that today, rather than just being black
holes.  I get the idea from some of your comments that you never saw
those sessions.

Megan:

Those sessions had a failing, and that was, good ideas that were too far
ahead of the time were rejected, when they should have been placed in a
longterm wish queue.  And of course, placing _all_ the blame on users not
asking for it is a bit of a copout.  But like any democratic process, it's
the worst process except for all the others.  :)

jg
--
These opinions are my own and not necessarily those of Pebble In The Sky.
http://ourworld.compuserve.com/homepages/joel_garry   Remove nospam to reply.
mailto:joel_garry@compuserve.nospam.com  Available for Oracle DBA work.

In article <slrn72dmkf.6cl.joelga@pebble.org>, joelga@pebble.org (Joel Garry) writes:
>
> I'd even go so far as to say it is BAD for applications coding in general.
> But how does one fight an entire educational system and product structure?
>


  There's always hope...I mean, at one time, Pascal was supposed to
replace all languages for all uses...don't see much talk about
it these days..maybe the same thing will happen to C & C++...

Lee K. Gleason N5ZMR
Control-G Consultants
gleason@mwk.com