From: Brian Inglis on
On Sat, 31 Mar 07 11:41:25 GMT in alt.folklore.computers,
jmfbahciv(a)aol.com wrote:

>In article <1ptr03dlr4i094g32r3aflhsg8e12ing85(a)4ax.com>,
> Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote:
>>On Thu, 29 Mar 07 13:29:12 GMT in alt.folklore.computers,
>>jmfbahciv(a)aol.com wrote:
>>
>>>In article <tl7n03h8uppujai6ck0ap794okqulb9i71(a)4ax.com>,
>>> Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote:
>>>>fOn Wed, 28 Mar 07 11:16:23 GMT in alt.folklore.computers,
>>>>jmfbahciv(a)aol.com wrote:
>>>>
>>>>>In article <46099974$0$18859$4c368faf(a)roadrunner.com>,
>>>>> Peter Flass <Peter_Flass(a)Yahoo.com> wrote:
>>>>>>jmfbahciv(a)aol.com wrote:
>>>>>>>
>>>>>>> And I'm telling you, again, that DEC did not have the infrastructure
>>>>>>> to handle that support. DEC's main business was not retail-ish.
>>>>>>>
>>>>>>
>>>>>>Even IBM decided they didn't want to be in this business.
>>>>>
>>>>>I've spent quite a bit of my thinking time trying to figure out
>>>>>how to do the single task of software support with 200 million
>>>>>systems. I still don't have it. Micshit is trying by using the
>>>>>internet and edictive practices. That's not working either.
>>>>>
>>>>>Number one rule is to not ship security holes and have a backout
>>>>>plan when you do.
>>>>>
>>>>>I haven't thought of any way to do this. Micshit's answer is an
>>>>>"as is" which was anathema to the manufacturers of the past.
>>>>
>>>>Ahem, manufacturers didn't do software support: they did production and
>>>>maintenance.
>>>
>>><ahem> But DEC did do software support for the products it did
>>>ship. This was part of our corporate folklore. It would ahve
>>>been unthinkable to sell millions of _systems_ with no followup.
>>>It simply was not in our blood to do this. If the customers
>>>wanted us to leave them alone, we did. However, the reverse
>>>was never true.
>>>
>>>>A few inhouse staff did the software support, complained to the
>>>>manufacturer occasionally, mostly got some response, rarely got changes
>>>>made, if it followed the strategic direction (on the mini products).
>>>>The same model would have worked for personal workstations, with the
>>>>customer being responsible for most support.
>>>
>>>That implies that all sources are shipped with the toy. You
>>>people are talking about a product line that made acquiring sources
>>>a miracle.
>>
>>DEC did not ship sources for their popular PDP-11 OSes,
>
>Since when?
>
>> we had to work
>>with the documented system interfaces, but they were pretty good for
>>most purposes.
>>
>>>>DEC FE supported their terminals
>>>
>>>Terminals did not run OSes. We knew how do hardware in that
>>>number but not systems. Do you understand the difference
>>>between a piece of gear and a _system_?
>>
>>Do you understnad the difference between supporting hundreds of
>>mainframe systems on a few hardware bases and thousands of mini systems
>>on a variety of hardware bases?
>
>Do you understand that support a PC base would have been giving
>direct corporate support to each and every person who had accounts
>on the mainframes? Not only would we have to "train" all users
>to be sysadmins, but they would also have to be trained to be
>field service, operator, systems analyst, etc.
>
>>IMHO the mini people really had to have had their ducks in a row to deal
>>with the volume.
>>Remember there were independent industry mags for at least some of the
>>popular mini OSes.
>
>This has nothing to do with supporting the _systems_ that we sold.

The distinction is that the customers supported the systems, and shared
information thru industry mags: DEC supported the customers, via DEC and
the customers' support staff.

Your definition of systems includes only the DEC hardware and software:
useful customer systems (typically) contained much more hardware and
software than DEC provided or supported.

There was a lot of non-DEC hardware and software on DEC systems that DEC
didn't support: the customers' support staff worked with non-DEC support
staff to support the hardware and software that (in most cases) did the
real work of the business.

DEC supplied and supported only part of the infrastructure, and were not
responsible for making or keeping the rest working.

A similar support model would have been applicable to any hardware that
DEC sold to business customers, including LSI-11 based desktop
workstations.

It was the software that other people wrote and supported that made DEC
systems popular and useful, at least in business, and the DEC part
mattered only so far as it made it easier and more profitable for those
others to do so, on DEC rather than other platforms.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
From: Brian Inglis on
On Sat, 31 Mar 07 12:13:54 GMT in alt.folklore.computers,
jmfbahciv(a)aol.com wrote:

>In article <tlvr03lc4tta7uc53787pi8aa0gc4ikdpm(a)4ax.com>,
> Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote:
>>On Fri, 30 Mar 07 12:12:22 GMT in alt.folklore.computers,
>>jmfbahciv(a)aol.com wrote:
>>
>>>In article <573r7kF2arf8qU1(a)mid.individual.net>,
>>> =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote:
>>>>> OK, then my question goes back to Jan and Barb. Why was a full sysgen
>>>>> required or recommended for the situations you guys were talking about?
>>>>> Wouldn't partial gens do the job without the need for the large
>>>>> resource commitment Jan talked about?
>>>>
>>>>At least for the first 10 years or so, VAX/VMS wasn't structured in a
>>>>sufficiently loose way to make this feasible, IMO - we're talking the core
>of
>>>>the OS here,
>>>
>>>Yes, I'm talking about that, too.
>>>
>>>> of course, not all of the utilities etc. that constitute the bulk
>>>>of the code. However, if you needed to make an interface change at the
>>>syscall
>>>>level, you'd need to recompile everything.
>>>
>>>Really? Most of TOPS-10's rebuilds had to do with hardware changing,
>>>not software. Oh, I see. ARe you talking about adding a new
>>>syscall? That would be a new feature; it's safer to do a complete
>>>rebuild, especially if the syscall had anything to do with disk
>>>I/O user-mode code interfaces.
>>>
>>>
>>>>
>>>>And anyway, I can't think of a problem that would have required a rebuild.
>>>>Significantly upgrading a subsystem, like the batch or print job
>management,
>>>
>>>Nah, on the -10 that was at the app level.
>>>
>>>>would have been much easier with the source - but as I said, DEC customers
>>>>never considered such things until (too) late, in contrast to IBM's
>>>customers.
>>>
>>>Our device tables, command tables, and all fields associated with them
>>>were generated by macros based on the questions answered at MONGEN
>>>time (a program that queried the sysmanger what hardware and software
>>>features he wanted to put on his computer system). The best
>>>way to make any changes to those would be to do it the "right way".
>>>Fumble fingers can destroy machines.
>>
>>Without the sources, you'd just dump the tables, define your own macros
>>to create the entries, and add new entries to the tables; find where the
>>table origins were loaded, and patch the code to load the new origins.
>
>And now you've just overwritten code. In the biz, it's called
>buffer overflow.

It's called system maintenance: patching the system to add
functionality.
Buffer overflow is a bug caused by amateurs masquerading as programmers.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
From: Brian Inglis on
On Sat, 31 Mar 07 12:51:53 GMT in alt.folklore.computers,
jmfbahciv(a)aol.com wrote:

>In article <970s03tmilpgk1503irit6169vprteghtf(a)4ax.com>,
> Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote:
>>On Thu, 29 Mar 07 12:39:33 GMT in alt.folklore.computers,
>>jmfbahciv(a)aol.com wrote:
>>
>>>In article <460a8553$0$8961$4c368faf(a)roadrunner.com>,
>>> Peter Flass <Peter_Flass(a)Yahoo.com> wrote:
>>>>jmfbahciv(a)aol.com wrote:
>>>>> In article <460a471e$0$28137$4c368faf(a)roadrunner.com>,
>>>>> Peter Flass <Peter_Flass(a)Yahoo.com> wrote:
>>>>>
>>>>>>Morten Reistad wrote:
>>>>>>
>>>>>>>
>>>>>>>Just watch the pain unfold when Vista cannot run your application.
>>>>>>>With binary-only, Microsoft products you will have a similar experience
>>>>>>>as we had when DEC folded on us. There is no Plan B in this scenario.
>>
>>>>>>>>>The lesson from DEC is that it can happen.
>>>>>>>>>
>>>>>>>>>Always have a Plan B.
>>>>>>>
>>>>>>As I already said, my plan B is Linux.
>>>>>
>>>>>
>>>>> However, there are a lot of system owners who cannot use that
>>>>> as their Plan -anythings because they are not in the software
>>>>> biz.
>>>>
>>>>I got excited when I heard Dell was going to (again) ship retail PCs
>>>>with Linux. Then I contacted support and found out they're going to
>>>>pre-load some dumb version of DOS, and sell Linux separately. While
>>>>everyone here would have no trouble installing a new OS, non-M$ systems
>>>>will continue to lag until they're available pre-loaded and
>>>>pre-configured. M$ knows this, and I'm sure their fingerprintes are all
>>>>over everything.
>>>
>>>When JMF was dying (1994) and needed a laptop in order to speak, I
>>>tried to order one from Dell. I was told that it would take
>>>six months to install Unix. I'm an auld OS babe and smelt the
>>>rat.
>>
>>>I have not tested this part of the OS biz since then.
>>
>>My first Linux install was 30 minutes from opening the Slackware CD
>>wrapper to running the OS with an alternate boot to DOS/Windows.
>>It then took longer just to config a customized kernel to support needed
>>drivers and eliminate unnecessary ones; the kernel source rebuild took
>>much longer.
>>
>Sigh! Even a moby IBM install from scratch didn't take six months.

Between a day and a week, depending on:
whether you'd seen/read the manuals before,
whether you knew yet what devices you were actually going to be running,
whether anything else was running on the first level virtual machine,
availability of the tape drive for your virtual machine to write or dump
a bootable tape.

Like everything IBM, you first have to get your head around why they're
going about things that way, understand the terminology acronyms and
numbers, get over the denial etc. stages to acceptance, and then
actually doing it is relatively simple, as long as you understand all
the details of where you should accept/use defaults, as the values
aren't really used or don't matter, and where you must override
defaults, as the values used are critical, to have a usable system.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
From: Brian Inglis on
On 29 Mar 2007 18:11:18 GMT in alt.folklore.computers,
nmm1(a)cus.cam.ac.uk (Nick Maclaren) wrote:

>
>In article <MPG.2075a1a27f7217af98a25a(a)news.individual.net>,
>krw <krw(a)att.bizzzz> writes:
>|>
>|> > Of course. IIRC, IBM had a crisis in the 80s(?); the reason it
>|> > survived that one was due to having enough money to carry them
>|> > through.
>|> >
>|> The '70s were pretty bad. I remember walking out to the P'ok
>|> production floor and seeing only one or two processors in final test
>|> with "Departent of Agriculture" (going to a three-letter government
>|> agency, sure) in the '70s. The 303x came out in '80 and things were
>|> hopping around P'ok, at least, for the next decade.
>
>That was a bit misleading. IBM was outsourcing quite a lot of its
>actual production by then - to places like Glasgow (if I recall),
>though still IBM subsidiaries.

Havant (UK) and Yasu (Japan) for 3033; Boeblingen for some 4300
processors: Greenock was only ever terminals (maybe later some kind of
PC) AFAIR. Peripherals were pretty widespread.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
From: Brian Inglis on
fOn Wed, 28 Mar 2007 13:01:55 -0400 in alt.folklore.computers, Charles
Shannon Hendrix <shannon(a)widomaker.com> wrote:

>On Sun, 25 Mar 07 13:19:33 GMT
>jmfbahciv(a)aol.com wrote:
>
>> >We would have been better served by a 8way or 16way PDP11, or a
>> >networked cluster of them.
>>
>> That was Husvedt(sp?). He swore he would make it physically
>> impossible to multi-anything.
>
>Were there any projects at all that at least got started thinking about SMP
>or clustered PDP-11 systems?

RSX-11 on PDP-11/70MP and 11/74 (up to quad with CIS):
http://www.classiccmp.org/pipermail/cctech/2006-February/057197.html

>> They were. The product line lasted that long because they
>> were the stopgap. The OS development of the -11s were the
>> way DEC^WDigital "trained" their future VMS developers
>> and (probably more important) learned corporate folklore.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply