From: jmfbahciv on
In article <64zKh.153484$5j1.81907(a)>,
Stephen Fuld <S.Fuld(a)> wrote:
>jmfbahciv(a) wrote:
>> But the question here isn't about style but why (or how)
>> these managers assumed that customers could be dicated to
>> as if they were subordinates.
>Come on Barb. You know the answer to that.


> They assumed that because
>it was a good assumption because it was quite often true for over the
>previous three decades! When these managers were coming up, IBM was so
>dominant that they *could* dictate to customers and most of them would
>"obey". Note that I am not commenting on the value or goodness of the
>situation, nor of its applicability to the different environment of the
>DEC marketplace (where it clearly wasn't nearly as effective), just
>answering your question. :-)

It made us a lot of money. IBM didn't mind because we were their
anti-monopoly cushion.

>I am making the assumption
>> that most managers knew that products were being made and
>> sold to other people.
>Yes, but in small enough numbers that they could be largely ignored.

I sometimes wonder if you moved them all to a mill environment
if that kind of self-maintained ignorance would be erased.


From: jmfbahciv on
In article <45faca01$0$1342$4c368faf(a)>,
Peter Flass <Peter_Flass(a)> wrote:
>jmfbahciv(a) wrote:
>> There were many sane ways to move customers from the one product
>> line to the other, IF that was a goal. The choice was the most
>> insane method. This was part of the IBM thinking that was
>> injected (sorry, Lynn) into middle management. IBM customers
>> were used to being ordered around "for their own good".
>Maybe in some respects, but many would say the reason for IBM's success
>was that it always tried to maintain backwards-compatibility. A program
>from the earliest 360 days (executable, not just source) will run the
>same today on the most recent version of the hardware and OS. That's 42
>years of compatibility!

That is NOT maintaining backwards compatibility. You create a
design that simply won't _break_ old code. Then you don't have
to spend a single maintenance dollar on your customers' old

I am assuming that you are using the word 'maintenance' very
loosely but it cannot be used this way if you are designing
tomorrow's CPU.

This is the most important point of the design. Everything else
is bits and bytes. If you have to maintain your customers' old
code (which includes all of your old code), you'll go bankrupt.

From: jmfbahciv on
In article <mddwt1g4wcp.fsf(a)>,
Rich Alderson <news(a)> wrote:
>jmfbahciv(a) writes:
>> In article <etbjul$b66$1(a)>, johnl(a) (John L) wrote:
>>> Well, sure, you could keep running your old 18 bit programs, just like
>>> on a 386 you can keep running your old 16 bit 286 programs. But if
>>> you wanted to use the larger address space,
>>> you had to rewrite your
>>> programs, and since segmented address spaces sucked as badly then as
>>> it does now, we didn't. Where I was (Yale) we moved to 4BSD on a Vax.
>> I don't understand. Why did you have to change code to run on
>> a -20 when the backplane was installed? There was nothing, other
>> than your local requirements, that forced you to change code.
>*This* is what I was talking about in previous posts: Not using a changed
>architecture with an expanded instruction set, but using the old architecture
>with expanded memory.
>Let's say you have a CAD program that runs on the PDP-10. Call it SUDS, for
>the sake of argument. The amount of work that can be done in an 18-bit space
>is sufficient for some time, but eventually you need to do work on a board
>larger than will fit into your system.
>So you have to revise SUDS to use "extended addressing" and "non-zero
>so that your board representations can be held in memory. But this means
>you have to rewrite a lot of nonobvious parts of SUDS, because the
>only allows addressing of non-zero sections from non-zero sections, and in
>a section, where addresses are not 18 bits but 30, certain common
>do not work, for example AOBJN, the most common loop type.
>(For those not familiar with the PDP-10, AOBJN _A_dds _O_ne to _B_oth halves
>the accumulator (AC) specified, and if the resulting value is _N_egative, it
>_J_umps to the 18-bit address specified in the instruction. It is frequently
>used to loop over table entries: The number of table entries, negated, is
>in the left half of the AC and the address of the first entry is put in the
>right half, and the AC is used as an (18-bit) index register to reference the
>table entries in the loop body. At the bottom of the loop, AOBJN AC,LUPTOP
>you're now pointing at the next entry at the top of the loop.
>In extended sections, 30-bit addresses in ACs interfere with AOBJN, so all
>loops of this kind have to be rewritten. A number of other gotchas of
>stripe exist.)
>And that's why some people left the PDP-10 behind, Barb.

The -10 already had "segmentation" in its philosophy. You
didn't run any code without GETSEGing. So I don't understand
how you expected an enhancement to make segment boundaries

Given: 72-bit words--

I would assume (if the instruction was implemented)
that the equivalent of the PDP-10's AOBJN
would work on 72 bits or whatever. But this is the kind
of thing that needs to be thought about when designing
the extensible piece.

Now, for the sake of the new design piece of this thread,
why was that code using AOBJNs?


From: jmfbahciv on
In article <m3wt1hp4vk.fsf(a)>,
Anne & Lynn Wheeler <lynn(a)> wrote:
>John Ahlstrom <AhlstromJK(a)> writes:
>> See:
>> Virtualizing the VAX architecture
>> Preliminary Design of a VAX-I1 Virtual Machine Monitor Security
>> Kernel. Technical Report DEC TR-126, Digital Equipment Corporation,
>> Hudson, MA, ...
>> - Similar pages
>> A Retrospective on the VAX VMM Security Kernel
>> 45 {45} P. A. Karger, "Preliminary design of a VAX-11 virtual machine
>> monitor security kernel," Digital Equip. Corp., Hudson, MA,
>> Tech. Rep. ...
>> - Similar pages
>> [ More results from ]
>may have been somewhat/totally coincidental ... but when POK convinced
>corporate that the vm370 development group (at the time, located in
>the old SBC bldg. in burlington mall) had to be shutdown (including
>the product) and everybody moved to POK help get MVS/XA out the door
>.... some number of people didn't moved ... and several round up at
>DEC (workng on what was to become vax/vms)

All of this cancelling stuff...when did this happen? I don't want
a year; I want a contect of the state of the economy at the time.
(I don't know a better way to write the question).

>Endicott managed to salvage some of the mission and keep the product
>from totally being canceled.
>a few recent posts mentioning the event:
> How to write a full-screen Rexx
> IBM S/360 series operating systems
> more shared segment archeology

I was always amazed that the Ultrix group survived. I don't know
how they did it. As one story that JMF used tell went...maybe they
gave better blow jobs.

From: Peter Flass on
jmfbahciv(a) wrote:
> The Alpha was getting started to become a "raional"
> system. VAX was junk. Then, as with TOPS-10, DEC essentially
> canned VMS. Custoemers who were very happy with VMS on Alpha
> saw the signs and did the intelligent thing and moved to another
> architecture. This was in the 90s.

I liked the VAX architecture very much. It was really a
"programmer-oriented" instruction set, maybe one of the last. VMS just
wasn't a TOPS-10/-20 replacement system.