Conference 7.286::digital

	Customers were excited by the fact that this was a leading-edge
	machine. Lots of things about it were new, powerful and attractive.
	32-bit data; 32-bit addressing which brought with it a virtual
	address space much larger than the physical memory (as opposed to
	the PDP11 series where the opposite was true); very considerable
	processing speed; the RAMP features for reliability and maintainability;
	and the versatility of the machine (after a while). It took the lid
	off.

	Having worked in support at the UK CSC, I can tell you one of the
	things that burned a lot of customers - and me - and still does.
	In the PDP11 world, there were large classes of customers who were
	running BASIC-PLUS and BASIC-PLUS-2 applications on RSTS/E. We never
	provided an off-the-shelf conversion facility to VAX. The best we
	could offer was VAX BASIC (which however differed in many significant
	ways from the RSTS/E version). In time a few tools (like VAX SCAN)
	came along. In time, too, a lot of software houses came along with
	off-the-shelf services to convert those "stranded" RSTS/E users
	to run in C on a UNIX(tm) machine. In most cases we lost those
	customers.

	The moral - find out what significant numbers of customers want and will
	pay for, and make sure it's there. The customer should sign, and pay -
	Digital should take care of the rest. How it's done is an implementation
	detail.

	/Tom

The development of VMS took place in an intensly "political" atmosphere
within engineering that, I believe, led to a number of problems.  These,
as the preceeding reply pointed out, resulted in customers migrating to
non-Dec hardware and software.  Here are a few that I remember -- I hope
for the sake of my pension that you don't repeat this history:

-- The commercial product line did not fund Vax/VMS development, as it
   was aimed at a laboratory/real-time market (or was it the other way
   around?)  Consequently, as noted, there was no effort made to offer
   RSTS/E and RT-11 users a migration path.  Such a path would have
   included the ability to mount RSTS/E disks and a native Basic-Plus
   "as we know and love it" -- since Basic-Plus was an interpreted language,
   a language re-implementation would have been pretty simple..

-- We made a similar mistake with Unix.  Now, at the time, Unix was mostly
   a university curiousity.  According to what I've read, several senior
   VMS developers examined Unix, decided it was a toy, but "implemented
   all it's good ideas in VMS."  We are still paying for this hubris:
   VMS has about 6 incompatible text file formats -- which means that
   text cannot be written by one program and read by another with any
   certainty and many of the simple features of Unix (protability, pipes,
   cheap sub-processes, file-name expansion, universal time base) are missing.

-- "Development in a vacuum" -- the major decisions about VMS were made
   without effective input from the field.  To a great extent, this was
   unavoidable, but I suspect it went too far.  The base note -- assuming
   it is not too late -- is a good idea.

I suspect that if you conceive Alpha as a super-VMS (or even as a super-Unix),
you will create a niche product for a niche market.  On the other hand,
I don't know if there is a good way of ensuring flexibility and future
growth, while retaining compatibility with existing applications.

One tiny thing you could do (in VMS) that will solve 80% of my personal
frustration would be to "fix" every utility program, editor, and language,
so that all text files are written in "stream-linefeed" (Unix compatible),
Also, all file copy programs should work on *every* file without tweaking.

Martin.
(ex: RSTS/E corporate software support)

First, I'm very glad someone thought of this.

People wanted cross compilers - they wanted to be able to do their development
on the "new whiz-bang fast" machine that they could run on the "solid as a rock
we bet our business on this and it works" old machine, while they gained
experience and trust in the new one. 

As far as I know, the first DEC supplied cross compiler to run on VMS and
generate code for the PDP-11 happened in 1990. And compatibility mode wasn't 
the answer, as BASIC-PLUS  and BASIC-PLUS-2 didn't run in compatibility mode, 
and any language that did, ran as slow in compatibility mode as it did on a 
real PDP-11. When VAX BASIC V2 and BASIC-PLUS-2 V2 were developed jointly,
there should have been a requirement for a native mode VMS compiler that
generated PDP-11 code.

But the above is really a symptom of the fact that people wanted to be
able to take their current applications from their old machine, and run 
them on the new, day after the  new machine arrives, with no work. 
Best case, just move the images, and everything runs (with all the speed
of the new machine) next best, just recompile and link my application.
Otherwise you run into having to run the old stuff while the old sources
are re-worked to run on the new.

Solve this problem and you've made the biggest help I think you can make.

I remember as a customer developing an application on a 780 that was to
run on an 11/02 (RSX-11M) calling DEC to ask if the images I TKB'd ran and
tested on the VMS compatibility mode could be brought to the RSX-11 M 11/02
and work, and getting the answer "We don't know". Let's have a different
answer this time around.

				Tom_K

				ex BP2 developer
				current PDP-11 C developer

    BLISS/PDP (cross-compiler from VAX to PDP-11) is a _lot_ older
    than 1990--I was using it in 1982 to develope F77DEBUG.
    
    But BLISS is a special case!
    
    		-John Bishop

	Mention of TKB under VAX/RSX reminds me - about that time I was
	in the CSC, and we had a RSTS team, an RSX team, a small RT11
	team, and a VMS team. I was in the VMS team, and all this TKB
	stuff really baffled us.

	Assuming you accept the input of .2 and .3 and attempt to provide
	really thorough-going cross-support, please do not ommit to make
	sure there is support in place, including a nucleus of mature
	experts who are experienced in VAX and trained in Alpha. In other
	words, please don't try to support something with people who have
	never done it before and can't set it up now.

	I know Customer Services is in another universe, but there is a
	gateway called CSSE - there may even be others.

	/Tom

re: .0

I was a customer during that timeframe and was involved in a few large
PDP => VAX conversions.  I think .1 has hit the main problem area dead center.

As .1 said, there were a very significant number of customers running BASIC-
PLUS and/or BASIC-PLUS II under RSTS/E.  I was one of these.  We felt like
Digital was trying to force us to other hardware vendors.  The RSX folks got
their own emulator that would run non-prived code unchanged from day 1.
All we could do was convert our BASIC code to VAX BASIC by hand.  It was years
before we even got a translator, but by then most of us had already written
TECO-macro translators.  Heck, EG&H even came out with a Runtime System
emulator.  One site I was at used the product.  It ran the code on a 780 at
about the speed of an 11/40, but it worked.  I and a team of about 4 other
people, spent almost a year converting every kind of program imaginable.
Like .1, I am mad and embarrassed that we treated those customers like that.

DO NOT DO THIS AGAIN.

The most important thing Digital did right was to preserve the customers
investment in I/O devices.  I know of shops with clusters of 6xxx boxes
and 1 86xx box to get to their UNIBUS disks.

DO THIS AGAIN IF AT ALL POSSIBLE.

Bob

    I've been in two environments where Digital was involved with a
    transition to new technology.  One was at a university and the other
    was while I worked at a nuclear plant.
    
    At the nuclear plant there were both VAXen and PDPs.  A VAX 11/780 that
    was there kept the group I was working with from buying everyone PCs at
    the time.  It was because there was definite need for PCs on occasion
    but it was hard to justify putting one on every engineer's desk.  So,
    we set up accounts on the VAX.  We had a VT100 that all engineers could
    get access to.  That allowed the engineers that wanted occasional
    access to a PC to be able to do most of what they wanted to do and
    wound up saving the company money.  There were also PDPs, but we never
    had to do much with those.
    
    We had a Honeywell printer that was slow, expensive and terribly
    unreliable.  We were able to convince the control room to go to an
    LA100.  It was much cheaper, faster and easier to maintain.  For this
    application it was okay if the printer occasionally went down if we
    could fix it.  As I recall, they kept ample replacement parts on stock.
    They also enclosed it in a sound-proof box and cut a hole in one of the
    existing counters for the paper.  That last task might have been the
    most expensive part of the transaction because it was done with on-site
    union labor.  But, they were quite pleased with the results.
    
    Both of these situations showed where the customer happily went with
    Digital over existing technology because Digital cost them less and
    gave them more bang for the buck than the alternatives.
    
    At the university, we had a PDP (we named it Dino) that was used for
    development purposes.  We also had LSI-11s and access to a VAX.  And,
    there was a Rainbow that was cute but which nobody every did much more 
    with than display a map of the United States.  Students were told that
    they had to buy pre-formatted disks for the Rainbow.  These could only
    be bought at the Bookstore.  I think they went for $10 a disk. 
    Students abandoned the idea of using the Rainbow because of the high
    cost.  (This is from memory, so don't quote me.)  The PDP was mostly used
    for classes where students wanted to get to the guts of the machine.
    The LSI-11s were used in more advanced OS classes.  The VAX was used
    for "real" work in C and LISP.  The DIGITAL machines were used heavily
    because you had to pay more to use the IBM mainframe.  Toward the end,
    however, more and more of the teachers and students went to IBM PCs.
    This is because these machines allowed them to do what they wanted to
    do for about the same cost but in their own homes or offices.  VAX
    terminals were available but you still had to go where the computers
    were in rooms that were often locked after hours.
    
    In the university, folks moved away from the IBM mainframe because of
    cost.  They moved to Digital because of bang for the buck (except for
    the Rainbow).  And, they moved to PCs because of better access and 
    comparable bang for the buck.
    
    These lessons tell me that folks will migrate to a new system when you
    can show them that you deliver good bang for the buck and throw in more
    benefits like better access.  I suspect that the vast amount of
    software for PCs has grabbed market there because the bang for the buck
    was regarded as about the same.  
    
    The folks that used PDPs at the university and at the nuclear plant
    both had very specific applications where the PDPs shined.  They didn't
    go to VAXen for these applications but for general or new applications.
    They stuck with the old hardware for as long as it served the purposes
    of the initial applications.  They looked to Digital because it
    delivered best bang for the buck and was sufficient for general and new
    applications.  In general, the software packaged with VMS was
    sufficient for most applications and software became more of an issue
    with students who wanted to play games and do their own marketable
    software development.
    
    
    Steve

    This is gonna be fun!  My involvement was not in the time frame you
    spec'd.  Rather, I am right now, today, still involved in PDP-11 to VAX
    migration/conversion efforts.  That ought'a tell you how well the
    effort has progressed over yeah, these past 13 years.
    
    I am the Service Product Manager for PDP-11 software, and have been
    intimately involved in these efforts for for years.  I was also a
    member of the PDP-11 Migration Task force for a year in 89/90.  I 
    will mostly relate my experiences, and you will have to judge whether
    or not it is relevant to  your program.
    
    First off..I hope that there will simply be no issue of converting
    existing applications...period.  If software is not totally
    transparent, then I would suggest that you will experience almost
    exactly the same problems the PDP-11 world is today.  Now for some
    specific comments:
    
         - Be prepared to support the existing VAX-VMS installed based
           well into the 21st Century.  You will find incredible inertia.
           We are TODAY still discussing the need for on-going PDP-11
           support for at least another ten years.
    
         - There are still today over 100,000 installed PDP-11s (no one
           knows for sure how many)...There are 65,000 hardware and
           software support contracts.  Thousands of PDP-11s are STILL
           being sold each year.  As a matter of fact, the PDP-11 PBU
           has been the Corporation's most profitable unit for several
           quarters recently.
    
         - Do not expect potential customers to share your excitement
           about the new platforms.  They will be much more concerned about
           how long you are going to support what they have now.
    
         - Be VERY careful with migration messages.  Ten's of thousands
           of PDP-11 users heard our message, finally became convinced of
           the need to migrate...and went to IBM and other vendors.
    
         - Expect a significant amount of "co-existence".  Customers will
           migrate/convert at their own speed.  This is a bet-your-business
           decision, and we will have little influence.
    
         - Tens of thousands will be running third-party applications on
           prior versions of VMS (ULTRIX?).  Will the new platform support
           these older applications??  You had better hope so, or write
           off thousands of potential customers.
    
         - Don't TALK about migration programs.  If you are not prepared
           to aggressively fund and support (long term) REAL programs,
           with REAL deliverables, don't even start talking about
           migration.
    
         - Expect third parties to jump on the wagon to take advantage of
           customer uncertainties.  Also expect them to provide better
           migration packages than we will.
    
         - When the best marketing team you can put together, does the best
           analysis possible of how migration will take place, TRIPLE THE
           TIME FRAME, and cut the unit forecast IN HALF!  You won't be
           off by more than 100% then.
    
         - Be very careful about retiring existing products.  The
           areas/geographies will generally ignore these (I'm talking
           services here.)
    
         - Be aware that even the PDP10/20 ten-year effort didn't/isn't
           running that smoothly.  There is still strong, imbedded inertia.
    
    It seems to me that in our enthusiasm for new architectures, we get all
    carried away, and to a real extent start believing our own marketing
    hype.  Don't expect customers to be storming the Thompson Street
    parking lot waiving purchase orders.  A lot of them will be very
    cautious and even intimidated by the new systems.  They are going to
    feel pressured.  They are going to want very, very specific commitments
    for long term (10-15 years) service and engineering support.  Thousands
    of them are going to consider alternatives to DEC.  Thousands more are
    gonna ignore the whole thing.
    
    A final thought...and I don't know if it is relative to your project.
    Thousands of PDP-11 users who did convert to VAX....were very
    disappointed.  They found their applications ran better on PDP's.
    
    Hope this helps...and lot'sa luck.  Dick
                             

One point that ought to me made to customers wary of how long VAX
and or VMS will be supported:

	For God's sake, we *still* are supporting PDP-11's with
	new hardware, new releases of the operating systems and
	layered products! You can expect us to support VAX/VMS 
	to be supported at least as long after Alpha is released
	as the PDP was (is) being supported after the VAX was released.


re .4


	But did (could) customers buy BLISS/PDP? To avoid a rathole,
	feel free to answer by mail....


			Tom_K

    re .10, BLISS/PDP
    
    It was a product, and I have vague memories of total sales on
    the order of ten units a year.  It was killed (no longer a 
    product, not even much support internally) about 1987.
    
    		-John Bishop

    Shake out the "newness". 
    
    Even if you call it a VAX, and don't mention one word about MIGRATION,
    somebody like Gartner Group will announce that this is a new
    architecture, and scare the b'jesus out of the customer. 
    
    You're right, Dick: This IS going to be fun. Let's take a lesson from
    the FORD TAURUS and listen to customers at the same time that we
    design. It's not a SALES/MARKETING issue, but a fundamental design-
    for-SELLABILITY issue. 
    
    Even today, one of my customers refuses to PAY FOR a S/W layered
    product until it is installed, running, and making people happy. 
    
    When I was a customer migrating from RSTS in 1979, I recommended buying
    the DECsystem 20 instead of VAX, because of the reliability of the
    CODASYL DBMS. We wanted maturity instead of glitz. 
    
    DEC learned a lesson: A native tool set, applications, and enlisted
    CMP's are essential to sell to the commercial market. (ULTRIX didn't
    heed the lesson - it took some time to get tools for RISC.) So let's be
    open with our CMP's about our direction, learning as we learn, much the
    way that FORD did with the Taurus. 
    
    Keep in mind that this is a different world than in 1979. What lesson
    can we really apply to the current marketplace that was true a decade
    before?

I was involved at several customers with the transition between
RSX-11M/M+ to VMS in the early 80s. One of the biggest issues
was the decision to either "port" or "convert" an application.
The difference is one of level of effort to change the application
to take advantage of the new enviornment's characteristics.

We had quite a few applications that were simply ported over to
VMS and therefore still had all the design decisions that were 
made under RSX. These seldom ran well and often were the
cause of friction between Digital consultants like myself and the
customer but they were still done because of time and dollars.

Those applications that were converted almost always were more
sucessful. The problem here was that there were few formal
classes or even material to be used in that conversion. Helping
a customer convert over required educating them on the different
design choices one made under VMS vs. RSX. At that time there
were no seminars like there are now around designing applications
for VMS and therefore the customer had to stumble his way
through a somewhat difficult learning process. 

We need to have courses designed to help the customer make
the right choice and guide them in the process of converting. It's
a matter of fact that no matter how compatible the new systems
are they will have their own strengths and weaknesses. We need
to help the customers understand them from day one. 

-Ray

I suspect you are going to run into a lot of RSTS people who have very
unhappy thoughts about the transition to VMS. I'm one of them. If you
have customers you consider important either have a conversion plan,
and a good one, at Day One or be prepared to see them *never* move to
the new platform.

At the time VAX and VMS came out I was a Software Specialist supporting
commercial OEMs. Those that were not RSTS shops were CTS-300 (RT-11)
shops. We had nothing for them for years in the VAX space. People wanted
a good BASIC or COBOL. We offered neither. We offered BASIC PLUS 2 and a
slow COBOL. As a real "BASIC PLUS bigot" I still think we have a ways to 
go in the BASIC space BTW. There are still a lot of RSTS shops that aren't 
going to move to VAX BASIC. The conversion is difficult if you haven't gone 
to BP2. And even still there is a lot to overcome.

Remember the commercial space. Just because initial introduction is
geared to technical/scientific (and I don't know that that is the Alpha plan
but it sure was for VAX and VMS) plan for the future. Few at DEC may like 
it but you are going to need a good COBOL (if only to steal from other
vendors) and PASCAL. You may want to do some market research on, yes I'm
serious, RPG. I keep seeing want adds for RPG programmers and running into
people outgrowing their RPG based IBM systems. Also database is important
and "vaperware" is going to kill you in that space. Initially the only really
good VMS compiler was FORTRAN. I suspect that most of the Alpha work will
be for FORTRAN and C. I hope I'm wrong as there are an awful lot of other
languages used in the commercial area and if people *have* to re-write to
go to Alpha they might just as well look at IBM or U*ix systems from 
someone else.

Also field training is going to be important. Don't do it the way VAX 
training was done. Training was all or nothing. Either you got the whole 8
weeks or you got nothing. So it was often dolled out to "favorites" in 
some field offices. If you were not on the "in" list or considered a key
candidate for SW Consultant you knew nothing about VMS for the first
year or two or longer. This made it very hard to support your existing
customers and if they didn't see a pressing need to look at VAX system
they (the customers) didn't ask. As a support person you had no idea of what
or how to sell it either. Make sure that all or at least most field people
get some level of training very early in the game. You'll have to limit
who gets the whole thing before volume shipments but everyone who deals with 
a customer should have some knowledge, beyond the SALES UPDATE, quickly. 
People who feel left out at the beginning will take a while to get turned 
on to selling and supporting something.

One thing that seemed to work very well in the New York office was getting
an actual VAX in the office early. District management committed to a
product line that if they got a VAX they could sell X amount of systems.
And they did. Benchmarks and demos were key to the technical sell and the
management sell. We could show that the systems actually existed. The people
in the office got enthused as well. More so once the demo system arrived.

The NY District also had Gordon Bell come down and do a "show and tell" for 
key customers. I was on the fringes and heard various comments. Some were 
worried that he spoke too much and would scare people away. Others thought 
that he gave himself so much credibility by letting on to the down sides that
people believed the good he said. You may want to check with others who
were involved in those presentations (I can give a name or two if you send
mail) and see what they thought and how it worked out in the long run. Think
about having high level people who were involved (ie. engineering VPs and
Corp Consulting Engineers rather then sales VPs) go on the road to talk to
a lot of customers.

    Be careful about setting expectations. Benchmark a lot. I knew
    customers who didn't got to VMS because it would have taken 2-3 11/780
    to get the same performance they were getting with 50 users on an
    11/70. Others were getting great response time on smaller 11s running
    CTS-300 and people who suggested they look at VAXes at 3 times the
    money for the same performance plus a major conversion tab really looked 
    stupid. Remember that no product is the answer for everybody. Don't
    tick off people who don't need Alpha today if you can help it.

		Alfred

re Note 1390.12 by PNTAGN::LAMBKE:

>     Keep in mind that this is a different world than in 1979. What lesson
>     can we really apply to the current marketplace that was true a decade
>     before?

        Yes, it may turn out that whole classes of users and
        applications that were relevant in the PDP-to-VAX migration
        over a decade ago have long since gone in directions that
        Alpha may not go, e.g., personal computers.

        Bob

>        * A PDP-11 compatibility mode of performance equal to the then-highest 
>          performance PDP-11, the 11/70. 
    
    I read this wrong the first time. I thought it said "performance far
    less then the .. 11/70". Compatability mode was only rarely, and I'm
    giving the benifit of the doubt here, equal to the 11/70. Sorry but
    that was as far as I could tell a myth. IN fact as I said before even
    native mode sometimes a VAX wasn't as fast as an 11/70. Time sharing on
    the early VAX/VMS systems was incredably bad. Especially compared to
    a well tuned  and configured RSTS or CTS-300 system. This time if we
    say "compatibility mode of performance equal to " it better be true.
    
>        * For some time our VAX product set and was heavily dominated by 
>          compatibility mode versions.
    
    This was a major liability as I remember. People did not want to buy
    a machine that would do less but cost more. And unless FORTRAN was
    what they wanted to do that was what we were selling. I remember some
    customers getting down right upset at salespeople over this one.
    
    				Alfred

I was developing internal applications for PDP-11 RSTS/E BASIC+ at the time
the 11/780 first appeared.  I'm certain that at that time the incentive to
develop new internal applications for VAX systems, or to migrate existing
applications, was largely strategic.  We needed to demonstrate to ourselves
& customers that it was feasible to develop/migrate VAX applications.  And,
it was exciting to be working with new technology.  There was certainly an
expectation that a VAX application would perform better, but this expectation
was not always met.  I recall that the program-size restrictions and the code-
overlaying that were a regular part of PDP-11 applications were not missed by
many for long.

I'd take *some* exception to notions that the RSTS->VAX transition was
particularly difficult.  For BASIC+ developers, there was ample warning
from DEC for us to develop RSTS/E BASIC+2 applications, with assurances that
BASIC+2 code would port to VAX BASIC easily if certain RSTS-specific
system-service calls were avoided.  Seems to me that these advisories were
published about a year before the 11/780 appeared, and that my group was
adequately experienced with BASIC+2 by then.  I was very pleased at how easy the
transition turned out to be, for new application development.  Also, there
was a (BASIC+)->(BASIC+2) translator that was really useful; not perfect
by any means, but very helpful.  And, on the whole, the VMS environment
is about as 'user-friendly' as RSTS/E.

That was my experience at developing new applications during that period.
As for the application porting problem, things weren't so easy.  There
were/are a whole lot of BASIC+ applications (some of mine!) written so as
to be coupled pretty tightly to a RSTS/E PDP-11, before one knew better.
I believe these applications lost a lot of value during this period.

Hopefully, application developers are much less naive now.  Portability
to some extent as been a tenet of applications development for a long time.
Guidelines and source-code translators are essential and will help.
Object-code compatibility should be a non-goal.  It'd be taken for granted
that a user-friendly environment will be provided.

Re VAX/PDP performance:

	I was still a customer when the VAX was new and checked the 11/780
    specs very carefully.  It did INTEGER arithmatic and basic operations as
    fast as an 11/70 but its floating point ability were more in line with an
    11/40.  There was also some screwieness in the tape drive interface that
    got a lot of negative comment.

    I'll add a few perspectives.  During the VAX time period I was a
    customer, a vendor, a member of corporate support and a PL in a
    layered product group.
    
    VAX-11/780 rather than PDP-99.  It set expectations that this was
    a new architecture and that it was not going to mean 32-bit 11M.
    the -11 did however imply a familyness.
    
    It was not a PDP-11 emmulation it was RSX emmulation.  We lost a
    lot of RT and RSTS customers over this.
    
    From the outside, it was the hottest box DEC made.  Keeping up with
    the Jones was a big selling factor THEN.
    
    As an 11 emmulator it was Slooooow.  Perception.
    
    The UBA and MBA on the SCI was a great move.  Perpherials inventment
    was preserved.
    
    Third party development was not strong.  Most ran in compatibility
    mode and failed to perform even as well as PDP-11 native
    implementations.
    
    VMS V1.0 was a place holder.  I saw lots of early VAXes consuming air
    conditioning but little else.  VMS V2.0 was more robust.  VMS also
    had an identity problem.  Was it commercial biased or Real-time
    biased.  It preported to do both well and didn't deliver.  We lost
    a lot of the real time and commercial market that fell into either
    or extremes.
    
    A big selling point was the fields perception of the new machine.
    A conversation with field service was inspiring.  Only the best
    techs were getting VAX training.  It was a flagship product. DEC
    employees were honestly proud of this machine (as opposed to simply
    "positive").  
    
    More migrtation aids.  And then again even more migration aids.
    I was doing relational database development (before we had proper
    terms for it) for multiple architectures.  The sales message that
    VAX had compatibility mode had a negitive effect on the DEC target
    implementation (we built for 11M/M+ and RSTS assuming that we would
    ride the migration wave painlessly).
    
    The result was that our VMS implementation was not robust enough
    and the installed base was not big enough to justify investment.

    The hot box mentality of the 70's and early 80's sold a lot of VAXs.
    Today applications with better preformance and "openness" will do
    the selling.
    
    BASIC, FORTRAN and COBOL.  All the languages you'll ever need. 
    An example of an internal digital decision flying in the face of
    reality.  C++ seems to be the Pascal of today.
    
    A few ALL-IN-1 related comparisions.  ALL-IN-1 V2.0 was a re-write
    of the very popular V1.0.  The migration effort was very very painful.
    Integrated applications built into V1.0 would not build into V2.0.
    A loyal customer base stuck with us, but they all remember the pain.
    
    Keep the VAX line very alive.  Do not talk about the need to migrate
    (this is hitting us again with DECnet pase IV to Phase V).  We can
    not force the customers to move.  If we do, they will; to another
    vendor.  The internal VAX is great the PDP-11 is for morons mentality
    that developed around 1980-82 cost us loyal PDP-11 users that proved
    they could migrate, and it didn't have to be a VAX.
    
    Lots of field training, early.  Offer migration services at reasonable
    (fixed) cost, with timely delivery.  Provide handbooks describing the
    advantages and disadvantages of migrating, provide technical reference
    material, provide tools, provide even more trainined field people.
    
    DO NOT allow the pain that some customers and vendors will endure
    (or percieve that they will endure) be viewed as an opportunity
    to fleece the installed base for some short term service revenue. 

    I repeat, VAX/VMS is a fully supported product line that we will
    continue to grow and enhance as long as you are willing to pay $$$
    for them.
    
    We have screwed our installed base before. Though moving to another
    platform might get them screwed even worse, they will opt for variety
    before letting US screw them again. 
    
    -Kevin
    
     

>I'd take *some* exception to notions that the RSTS->VAX transition was
>particularly difficult.  For BASIC+ developers, there was ample warning
>from DEC for us to develop RSTS/E BASIC+2 applications, with assurances that
>BASIC+2 code would port to VAX BASIC easily if certain RSTS-specific
>system-service calls were avoided.  Seems to me that these advisories were
>published about a year before the 11/780 appeared, and that my group was
>adequately experienced with BASIC+2 by then.  I was very pleased at how easy 


Well, maybe it was available to Deccies, but it wasn't to us customers and the
OEM I worked for was an EFT site for BP2.

Also, just because some functionality isn't required for the new machine, it
may be essential to minimize migration problems.  One example from the BASIC-
PLUS/RSTS/E world was the detach system call.  Because of the addressing
limitations of the PDP-11, an awful lot of file update programs were written
as 2 separate programs.  The first did the data entry and simple validation.
When the data entry was complete, the first program detached itself from
the terminal, logged the user back into his account, and passed control to
the second program which did more complex data validation and the actual
file updates.  Now, VMS didn't have a detach system call, and if you looked
at it from a new design perspective, it didn't need it.  There were no
practical addressing limitations, so no one in his right mind would design
a 2-piece file update program for VMS, so who needs it.  However, if you are
a software house trying to migrate to VMS, you only had two choices:
1) Redesign and rewrite all your 2-piece update programs as 1 program.  This
is the right thing to do in the long run, but not when you are trying to get
your software running under VMS ASAP.
2) Make your front-end program do a create process system service to start
the second program and then drop to the $.  Today, using VMS V5.x, that's not
real difficult, but back then, the create process system service wasn't so
easy to use or very robust.  It was very difficult to duplicate the environment
of the front-end process for the second program.

Bob

    Great, Kevin....I absolutely agree that we should not even think about
    putting the existing VAX/VMS family to bed.  People will be wanting
    to buy "traditional" machines 10-15 years from now...they will also
    be looking for continued availability of prior version VMS (4.7), AND
    they will expect it to be supported, fully.
    
    I also agree that we should shut up about migration.  We've never done
    it effectively, and I don't see any reason why it should be different
    this time.  Let the customer decide!!
    
    I wonder, does even a small paragraph in the ALPHA marketing/business
    plan discuss the PDP-11 installed base as a potential market for ALPHA.
    We have had strong indications that VAX/VMS was perceived as an
    outdated technology several years ago, and that was one of the many
    reasons why we were seeing such obstinacy.
    
    Ought'a be very interesting to see what happens.....Dick

I have a somewhat different perspective than most of those who previously
responded.  I was a system programmer at a university that was a solid IBM
shop at the time that the VAX hardware was first program announced.  Our
sister institution (we shared some DP management) had installed a PDP-11/70
timesharing system and was very happy with it.  Thus, DEC knew we were looking
for a timesharing machine (we had been badly burned by IBM's flop with VSPC),
we would not even consider a 16 bit machine, but we did think DEC had
credibility.  A DEC salesman came to call at VAX hardware field test time and
we duly became a hardware field test site running VMS BL5.  One key thing here
is that we had no prior DEC experience and no expectations built on same.
We viewed VAX for what it was, on its own, not relative to some prior DEC
machine.

The answers to the questions, from our point of view at the time:

>     1. Here are some decisions we made.  Did they positively contribute to 
>        Digital's business? Or were they detracting? How?
>
>        * A PDP-11 compatibility mode of performance equal to the then-highest 
>          performance PDP-11, the 11/70. 

Irrelevant to us.  We didn't have any -11s.  It did mean that some of the OS
utilities got done faster (the RSX versions were used), and that was good.
In general, though, it made the system feel kind of schizophrenic at times--
the compatibility-mode utilities sometimes behaved quite differently from their
native counterparts and companions.  Overall, it was a minus, in our view.

>        * The product name "VAX". 

Definite plus in making the sale.  Our DP manager was distinctly prejudiced
against minis.  I'll never forget him coming into my office with the
ComputerWorld containing the VAX program announcement and saying, "Look at
this!  DEC just announced a real computer.  32 bits and everything."

>        * For some time our VAX product set and was heavily dominated by 
>          compatibility mode versions.

Irrelevant to us, except in that we refused to buy any layered products that
didn't run native, and there may have been some things that DEC could have had
out sooner for us if they hadn't been preoccupied with migrating PDP-11
customers and products.

>     2. What excited the customers? What did they rally around?  What made 
>        them WANT to own a VAX?

Several things impressed us:

(1) VAX-11/780 price/performance.  We were looking at two alternatives:
buying a VAX/780 or upgrading our IBM System/370-125 to a 135.  The entire
VAX system cost less than the IBM CPU upgrade, and we got a machine with twice
as much main memory that was 4 times as fast.  Plus, we got to keep our
S/370-125.

(2) The VAX instruction set.  Way ahead of IBM System/370.  A joy to program
in assembler.

(3) VAX/VMS.  The equivalent in IBM operating systems is MVS, which was way
too expensive and slow for us to consider.  VAX/VMS is also worlds easier to
system manage than the IBM operating systems.

(4) The compilers, debugger, editors, and overall software engineering
environment.  IBM had nothing like it.

(5) The reliability of the software.  It was far better than IBM's.

>     3. What aggravated the customers and slowed the buying cycle? How could 
>        we have changed this to make it work better.

We had a heavy investment in BASIC timesharing (previously done on Dartmouth's
DTSS, IBM's ITF, and Coursewriter/BASIC on IBM DOS/VS).  We had a very
unsophisticated user base and the compatiblity-mode BASIC-PLUS and BASIC/PLUS-2
environments that were available under BL5 and V1 was not acceptable.  The
BASIC issue almost lost DEC the sale, and indeed it would have if our salesman
didn't break the rules and steal a development copy of VAX BASIC for us.

The other irritating thing was field support, or should I say, the lack of it.
We had been used to the sort of hand-holding one got at the time from IBM, where
when the system crashed, the site FE (the same person who had been our
support person for years) would be there in an hour.  From DEC, we got
confused PDP-11 jocks (always a different person each time) who knew less about
VAX and VMS than we did.  We were also irritated about SPRs--in the IBM world,
filling them out is something that your IBM support person does.  Also, then,
as now, the SPR system was a black hole into which reports disappeared never
to be seen for years.

--PSW

	This topic appears to have been cross-posted in NODEMO::MARKETING
	as topic 1501.

	Although I think a lot more people read this conference, this topic
	is about as thoroughly to do with marketing as you can get, so I am
	going to reply there from now on.

	Just in case anyone hand't noticed! 8-)

	/Tom

    In government business, there's no such thing as "migration".
    Procurement regulations require a competitive procurement if the
    application software cannot be moved directly to another (newer)
    platform.
    
    As a former customer, I personally procured in excess of 100 PDP11/70
    systems. Most are still in place in a single room. There are 100s other
    PDPs (LOTs of 11/44) still humming along.
    
    The government's problem is support costs of these old machines (space,
    maintenance, etc). Many have specialized comm devices attached to
    Unibus and moving to a new bus is cost prohibitive. The 11/70s in
    particular had the MassBus providing I/O performance that even the
    current line of PDP's can't match (customer can't even migrate to a
    newer PDP much less VAX or Alpha). Some earlier notes mentioned o/s
    supportability on the newer machines. My ex employer/now customer has
    hundreds of copies of old Unix with user modified kernals.
    
    Instead of migration, I would believe the emulation or co-processor
    approach would have (could be) more successful in government. Provide
    binary compatibility for the software, equivalent performance on i/o,
    and buss compatibility for "strange" devices.

    As pointed out in previous notes - the first round of
    VAX efforts seemed to be aimed almost exclusively
    at the real time/technical world - ignoring the needs
    of commercial users.  
    
    In Europe, about two years after the introduction of VAX,
    we had to do a whole round of "commercial VAX" announcements/events
    to convince internal DEC people, customers and the press
    that we were serious about "commercial" business.
    
    Next time around, lets not ignore a major set customers.

    RE: .0
    > As we develop and evaluate our plans for Alpha, we'd like to make sure
    > we'd like to benefit from what worked in the PDP-11-to-VAX migration
    > and we want to avoid mistakes we made then. 
    
    Yes, we'll benefit from the comments of DIGITAL noters who helped sell,
    manage and service during this timeframe. 
    
    We'll also benefit from those [and I believe the VAX was and is a very
    saleable product to the NON-installed base] who migrated to the VAX
    architecture from:
    
    IBM S/34 & S/36		HP1000		GOULD MPX
    
    BORROUGHS B400		SERIES 1	PR1MOS
    
    DATABUS			MS-DOS		MODCOMP
    
    
    After all, alpha will be advertised to be an OPEN system, right?

    Please help me understand something here, people don't migrate from
    PDP-11 to VAX, they migrated from RSX/RSTS/RT to VMS. So where is the
    migration when we already have VMS booted on the Alpha? Shouldn't it be
    largely transparent to the users, and hopefully the applications.
    
    hw

>            <<< Note 1390.27 by ZPOVC::HWCHOY "Chicken on fire." >>>
>                       -< VAX or Alpha, its still VMS! >-
    
    	That's the theory isn't it? Just like Unix,ULTRIX, BSD, System V,
    etc. It's all Unix! Again that's the theory. Reality, with U*x at
    least, is something very different. Are you ready to bet your business
    that VMS on VAX and VMS on Alpha will not be a serious migration? Not
    me.
    
    Also the RSX to VMS migration was supposed to be largely transparent
    to users too. It wasn't.
    
    			Alfred

	The recent news article that talked about 'killing' the VAX didn't 
    help perceptions of this very much.  It did go on to explain the transition
    would be a long one, but it was still very alarming if you only read the
    first couple of paragraphs.

    Customers devoted to VMS want the price/performance as they see on the
    Unix side. Customers devoted to UNIX don't really care whether it's
    Alpa, SPARC or RS/6000. If you imply to the customer that they've got
    to  move to UNIX to capitalize on Price/Performance, he will. If this
    non-Unix customer sees a growth path similar to what he sees today on
    Unix, there's simply no business justification to move to Unix is
    there?

As someone who was working in a TS shop that had purchased a DECSystem20 in
1978, another must is a clearly communicated message. We were promised time
and time again that the DECSystem product was still viable and that follow-on
upgrades and processors would be produced. Needless to say, the company I
worked for is now an I*M customer today. We need a message that is clear,
consistent, and well articulated by everyone who talks to a customer.

-Terry

    This is an excellent topic. All the information here is
    quite interesting. I have a more basic concern I'd like to
    present. 


    It is my experience that there are many people concerned about
    ALPHA migration. It is a topic that appears in a lot of places.
    Take this topic for example....it has been posted in at least
    two other notes files. This is not bad, but I feel we, as a company,
    need one group who is responsible for deciding *the* corporate 
    strategy for migration.

    The question therefore is: Has an organization been chartered with the
    VAX -> ALPHA migration strategy? Is there a person or forum
    to which all migration questions/comments can be directed?


    Thanks in advance to anyone who can provide me with answers to these
    questions.

    					Ed Vogel
    

	Very interesting discussion and I hope that someone in the product
	managemen chain for Alpha is reading this... Someone who can affect	
	the outcome of what we finally see out of Spitbrook... I know that
	'they' can't comment on futures, but it would be encouraging
	to see a note from someone there saying 'We hear you, we are 
	aware of what is going on and we are addressing those issues...'

	Maybe too much to expect...
	
	Rick Beldin
	Atlanta CSC

    	Well, I'm not in product management, but "we hear you, we are aware
    of what is going on and we are addressing those issues." I'm one of the
    engineering project leaders working on Alpha/VMS, and believe me, it's
    difficult to hold back reading some of these replies...but the
    information is very sensitive, and this isn't the place for technical
    details.
    	However, the Alpha program office is very interested in these
    issues. There are people worrying about overall migration issues. Since
    we *have* learned from our past in many cases, I also think VAX systems
    will be around for a long time after Alpha comes out.
    	There is a group of people within VMS worrying specifically about
    the VAX/VMS to Alpha/VMS migration strategy...and there is enough of a
    migration to warrant the need for a strategy. There's product
    management, CSSE, documentation, engineering, etc. all involved with
    this. There have been numerous meetings with other groups to discuss
    migration tools and cross tools which I attended. I found one of the
    early replies to this note very interesting in calling for tools which
    run on Alpha/VMS which produce "stuff" for VAX/VMS, while we'd mostly
    been talking about tools which worked the other way around.
    	If you have a true need for detailed information on migration,
    there are numerous restricted Alpha conferences which deal with many
    aspects of this, the details of which are too sensitive to place in
    this conference. If you're just worried and want to vent some of that
    by stating your concerns, this seems like a good place. People are
    reading it and taking the concerns seriously.

                        -< Does management read this? >-
    
    Listening.  Thinking about BASIC & COBOL issues raised throughout
    this stream.  Engineering. ((a verb))
    
    	john henning
    	comm'l 3gl/4gl languages

    
    Re: Are the right people listening.
    
    Again, yes.  It was the Software Integration Manager, Al Avery, from
    the Alpha Program Office who started this note.
    
    The point of it is to gather information help in ensuring that we
    have the best migration plan we can have.
    
    Steve
    SQM Alpha Project Leader
    

    Perhaps some technical description (or pointers to) of what exactly the
    ALPHA is, in particularly its relation to VMS, ULTRIX and the VAX
    architecture, will help people come out with more educated concerns?
    I'm sure many of us are groping in the dark. There may well be issues
    in the VAX->Aplha migration that is not present/obvious in the
    PDP11->VAX migration.

    getting in here a bit late, having been on a longish business trip... a
    few comments, a more comprehensive reply may follow when (if) I have
    the time...(just as background, I was a DEC customer 1972 - 1975, been
    with DEC since then).
    
    Basically, a great deal of the gripes here have been about the RSTS to
    VMS migration. I don't know what the market shares of the respective
    PDP-11 operating systems were at that time - however, there are some
    differences (making many of these complaints, IMHO, irrelevant):
    
    Going to VAX, we had a many-to-one migration. No one has even mentioned
    IAS or RSX-11D here... and there were also attempts to attract former
    (then current) TOPS-10/TOPS-20 customers. This time (unless we're
    talking about RSX > -Alpha or RTSTS -> migration) there's only a
    one path to go.
    
    I don't know what the RSTS share was at the time (certainly more than
    IAS :-) - however, in [continental] Europe, RSTS was never a factor.
    Anyway, I don't think the problem exists in this form now - for all
    practical purposes, there's only VMS to migrate from.
    
    Someone mentioned TKB - this is more anecdotal now, but I think it must
    have been the most expensive program DEC has ever written! Think of all
    the time SWS people spent installing RSX systems and waiting to all the
    privileged tasks to build (during the SET /COFFEE_BREAK or
    SET/TEEBREAK...) I've never seen a linker that slow, not before, and
    not after, and on many systems (like RSX-11D, IAS, or VMS) there was no
    linking to do during installation.
    
    Also, some people said old PDP-11 applications ran 'better' on old
    PDP-11s. Sounds a bit ambigous... how does a program run 'worse'? Do
    you mean slower? Sometimes people are comparing apples and oranges
    (like programs running on PDP-11/70s with FPUs compared to 11/780s
    without FPAs).
    
    What I've seen so far re Alpha migration gives me a fair amount of
    confidence.
    
    re .23: I think the base note said so...
    

RE: .37 (ALPHA information)

Get in touch with the ALPHA program office (I think Peter Conklin is its
manager) for such info.

--PSW

At the time VAX was announced I worked for a customer.

We were very eager to find out all we could about it.  We were about to go 
for a big increase in computing requirements and VAX seemed to fit the bill 
almost perfectly.  We had also looked at DECsystem 10 and IBM mainframes, 
neither of which seemed to be best for what we needed.  After I left to 
join Digital in mid 1978 they bought several VAX systems.

I didn't actually get to use a VAX until I worked for Digital.  As a
former RSX user it was easy to see the family likeness between RSX and VMS. 
They had many common concepts.  There were three other mainstream PDP-11 
operating systems: RT11 - which I know very little about, RSTS - which was 
significantly different from RSX - the first project I worked on at Digital 
was on RSTS, and I had used it some years earlier (I wrote my very first 
program in BASIC-PLUS) and IAS which was really a different flavour of RSX 
(although I'm sure that some people will disagree).

One annoyance was that some of the compatibility mode utilities were 
restricted in their capabilities.  The move to all native mode utilities 
was a big improvement.  I ran an internal field test site for VMS V2 and it 
was the point where the VMS we know and love really came into its own.

The second project I worked on - from September 1978 to March 1980 - was to 
implement RSTS BASIC-PLUS as a second compatibility mode emulator system 
under VMS.  The development was funded by the Educational Product Line, and 
the product went to field test as "PDP-11 Instructional BASIC/VAX".  It had 
some shortcomongs - mainly because of conceptual differences between RSTS 
and VMS and the unfeasibility of implementing the special termianl modes. 

The project was cancelled about a month before the planned end of field test
on the grounds that VAX BASIC would be available sooner than originally
expected and that having two overlapping products would not be a good idea.

For the future, one thing that could be a potential problem would be 
programs that do not operate identically when recompiled to run on ALPHA 
with no source code changes.  The VAX emulator must also really be up to 
scratch.  If it doesn't produce identical results we could have real 
problems.  (The PDP-11 Floating Point emulation on the VAX could produce
different results with the EMODF/EMODD instruction.)

jb

    
    I still don't understand why everyone is talking about RSX, RSTS...->
    Aplha. Doesn't make sense! We need to talk about RSX,RSTS,...->VMS and
    how it throws light on VAX/VMS->Alpha/VMS. And of course we need to
    know a little bit about Alpha/VMS. And no one's even mentioned
    VAX/ULTRIX and MIPS/ULTRIX -> Alpha/ULTRIX. And not forgetting
    eventually Alpha/OSF-1.
    
    hw

    There is a crucial difference between the migration from the
    PDP11 and PDP10 operating systems to the (then) one-and-only
    VAX operating system -- and that's that it really was a move
    from one operating system to another.
    
    Now, the theory behind VAX/VMS to Alpha/VMS is that it's
    a hardware switch but the operating system remains the same.
    Sort of like VAX ULTRIX to MIPS ULTRIX.   Unfortunately, VMS
    was designed to be intimately wed to the VAX hardware, so
    there's going to be a lot of trauma inside the operating
    system, and (to a lesser extent) outside the operating
    system for some programs.   But the result is supposed
    to be familiar old VMS.
    
    This isn't intended to downplay the size of the problem in
    any way; just to throw a little bit of context up.
    
    (This note is not a statement of any official position I've
     heard, just my own summary of what I think is going on.)

    � This isn't intended to downplay the size of the problem in
    � any way; just to throw a little bit of context up.
    
    Exactly my concerns. We need to understand what the real problem is,
    or will be. Not that what was posted in this note isn't helpful, but
    let's not all run off and bark up the wrong tree. What I'm saying is
    that there may be another more relevant tree we should bark at, and
    let's not miss that.
    
    cheers,
    hw

It's quite possible that some of the details of the PDP-> VAX conversion are
irrelevent here, but I think we need to be very aware that we made many
customers and ex-customers very angry with how we handled it.  As one of the
other replies stated, if there is ANY conversion involved, customers will
look to other vendors.  I'm not so sure I agree with that.  I do believe that
we have a large number of customers who feel that they were burned once by
us and will be very critical of any mistake we make or any significant
conversion effort we require.

I would love to be able to take an Alpha machine, connect it to my MI cluster,
run CLUSTER_CONFIG and be ready to go.  If we can do that, I don't think we
will lose a single customer that we wouldn't have lost for some other reason,
and I would consider it a major technological feat.

Bob

    From reading this and comparing with notes on pleasing customers and
    how IBM relates to customers, I think the strategy for migration should
    be pretty simple.  We should promise each customer that we will chain* a
    tech to each Alpha platform sold to make sure that somebody is paying
    close attention to the conversion process.  The fact is that no matter
    how well we try, the customer will not believe that the conversion
    process will be easy.  But, if we truly believe it is easy we won't
    mind making such a commitment.  
    
    With a new product line, even if we lose really serious money up front
    it will pay off.  The losing approach is to wind up making a "last
    ditch" effort and spending about the same amount of money, but after
    customer's perceptions are set.  I've seen this happen with other new
    products like the TI 66/4, the Adam computer, the IBM PC Jr. and
    others.  I suspect we are seeing this losing strategy being currently 
    applied to IBMs OS/2.
    
    * By "chain" I mean meeting and exceeding the commitments that IBM
    makes to their customers as far as response time and courtesy to the
    customers.  This means that there is a person that will call the
    customer frequently just to make sure things are going okay.  This
    means that when the customer calls, this person (and no substitute)
    drops everything and comes to the site immediately, even if all he/she
    can do is show up and take a beating.  This means staying after hours
    on site until the problem is fixed.  This means having support that
    will drop everything and work after hours, too.
    
    Steve

One major problem I've seen with major announcements in the past, as
both customer and employee, is the highly negative impact of the
typical internal information blackout.  "Digital News", "Digital
Review", at al having a field day with the yet-unannounced product,
but Digital's own field people have NOTHING meaningful to say.  This
does little for their credibility after announcement day when they're
sent out to FINALLY deliver the message.

Yes, I know about PIDs, but many customers aren't looking for a
presentation.  They're simply wondering why their local Digital
representatives can't comment intelligently on what they're reading
weekly in the trade press.

With an announcement of the magnitude represented by Alpha, the field
desperately needs a "party line" detailing what CAN be said. Ideally,
there should be a series of "party line" articles leading up to the
announcement, designed to keep pace with what's being reported or
speculated in the trade papers.

In the absence of such information, you run the risk of well-meaning
people who are trying to deal openly with their customers and
maintain some credibility saying things that shouldn't be said.

-dave

    re: -.1  In other words, the transition process has already started, as
    far as the customer is concerned.  Sounds like a good many customers,
    right or wrong, may be deciding RIGHT NOW whether or not they will want 
    to move to Alpha and they are having to make the decision based on 
    information they get from outside sources.  No?
    
    Steve

    
    Re: .41
    
    > I still don't understand why everyone is talking about RSX, RSTS...->
    > Alpha.  Doesn't make sense!  We need to talk about RSX, RSTS, ...->
    > VMS and how it throws light on VAX/VMS->Alpha/VMS.
    
    Please, don't be too quick with this.  There is a BIG PDP-11 customer
    base and if signifcant numbers of them are readying to move to move up,
    then perhaps Alpha will need to address this.  I haven't heard ANY
    discussion of this among the goings on in the Alpha program.  If any
    of you have any insights to share along these lines then do it.  Up
    to now the assumption has been that it's a VAX/VMS to Alpha VMS
    migration, but perhaps that is the wrong assumption.
    
    Steve
    

    Re .34

    Hi Steve,

>    	There is a group of people within VMS worrying specifically about
>    the VAX/VMS to Alpha/VMS migration strategy...and there is enough of a
>    migration to warrant the need for a strategy. There's product
>    management, CSSE, documentation, engineering, etc. all involved with
>    this. 

>    	If you have a true need for detailed information on migration,
>    there are numerous restricted Alpha conferences which deal with many
>    aspects of this,...


    This is exactly my point. As a developer who is writing software
    for ALPHA, I need to know what migration support is needed in my
    product. I'm a member of many ALPHA-related NOTEs files, and am
    on lots of .DIS lists. What I want is *ONE* person or forum where
    I can go to get an answer to specific questions concerning corporate
    migration policy. Does this make sense?

    						Ed

    
    Re: .49
    
    This conference will bring it to the right place.  Essentially
    the ASPM (Alpha Software Program Managers) have the reponsibility
    for planning the implementation of all the programs software goals.
    ANY and ALL issues related to software on Alpha can be resolved
    by having them visible at the ASPM.  We either resolve it there,
    or route it directly to where it can be.
    
    Steve
    

    	Hi there, Ed. Yeah, I agree with you. Since the potential magnitude
    of this program is so great and needs to involve so many people to
    various degrees, there should be a straightforward means of
    distributing information. Like you said, there are numerous NOTES
    conferences, distribution lists, internal documents, and even some
    "road shows" that have been put on by various collections of product
    managers and people from the Alpha program office. This is apparently
    NOT getting the word out to everyone that needs it. So something else
    is necessary.
    	I had one other comment regarding the migration. Unfortunately, we
    can't provide technical details on Alpha in this forum. If you need
    those details in however you're involved with Alpha, then there are
    numerous forums where that information is available (unfortunately,
    there are numerous forums). As someone else suggested, start with
    the program office for pointers.
    	The purpose of *this* note is to explore all the things that went
    wrong the last time to avoid making those mistakes again. Some of those
    things will be irrelevent today. There will be new problems too that
    were never dealt with before. So these are things we can explore
    without detailed knowledge of differences between VAX and Alpha
    architectures or differences between VAX/VMS and Alpha/VMS.
    	Also, the issues for U*ix are different and could open up a can of
    worms if discussed here. In my opinion, we should just keep the
    discussion on migration to VAX/VMS from the earlier platforms.

Re .51:

	It may be a can of worms and it might not be a good idea to discuss
    it here, but SOMEONE had better be managing the U*IX VAX->Alpha move.
    Also the ELN VAX->Alpha move, the MUMPS VAX->Alpha move and all those
    other special operating systems or operating system like applications
    migrations.  That includes the RSX, and RT emulators, and hopefully 
    you can even dust off the old RSTS/E emulators and make them work.

    Re .48 ....You're right Steve.  I think that very few people in DEC
    have any concept of the massive size of the PDP-11 base TODAY.  We
    started hearing about their reluctance to migrate to VAX a couple years
    ago as they already considered VAX/VMS solutions outdated, and all it
    would mean would be ANOTHER migration a few years hence.
    
    Again, I hope the ALPHA migration planners are lookin' at 11's, but
    I'll bet you a large cup of coffee they aren't!

Getting back to the original "What'd we do wrong that we shouldn't do again?"
question of the topic  -

I was recently asked by another DECcie, when he heard that I have some
association with PDP-11 products (and after he'd gotten done laughing) -

   "What types of things are PDP-11's _good_ for?"

And I gave him my standard response -

   "Oh - trivial things, like terminal I/O."

How many people remember that one of the shortcomings of the early life of
the VAX was that it didn't support some of the great terminal MUX's that
made the 11's such powerful machines in many applications and markets?

From 77 to 82 I was with two PDP-11 engineering organizations that built
highly successful PDP-11 products that never stood a chance on the VAX.
One was TMS-11 and the other was RSTS. They didn't fail to succeed on VAX
simply because they weren't marketed there or because the VAX wasn't
targetted for their space (i.e. scientific rather than commercial). They
failed to succeed largely because the VAX was never expected to be able
to handle large numbers of directly connected terminal lines (such as was
the case in newspapers and commercial timesharing shops). You could hang
48 or 64 VT100's off an 11/70 (or less) and have no problems handling
the lines. Never happened on the VAX. (Can you say "terminal server" and
"CTERM protocol"? That's largely why these things were developed - to
satisfy the need to hang lots of users on a VAX, 'cause there wasn't any
other way to do it!)

So my suggestion would be, look at what the previous architecture is capable
of doing (where architecture = S/W + H/W + peripherals + applications + etc.)
and don't shortchange anybody with the new implementation based upon what
DEC might think is reasonable, becasue that won't necessarily answer all
the needs.

-Jack

	I was in DDP (commercial group) when VAX came out.
	All the problems with RSTS, commercial tools, etc. have been
	mentioned, and are probably not relevant.  However, there was
	a tremendous lack of information on conversion details.
	We (I) eventually generated a small book of our own on RSTS-VMS 
	Migration & Coexistence, prior to a corporate document.

	So we need DETAILS (the devil is in the details) on conversion
	requirements between VMS and Alpha as soon as possible as you
	get them, not only for customers, but for Engineering.  I work
	now for the TP Engineering Group, and we are trying to scope
	the amount of work that will be necessary for real conversion
	of our existing layered products, and we need more info --
	as you get it.  (Is there a private notes file maybe?)
	And it should all be collected so it can go to our support
	people and then to customers later.

	So far it sounds pretty good, but it can't be that good.
	We want/need to know the hitches ASAP.

	-Ken

    getting back to the transition:
    
    The PDP to VAX move was initially focused on the technical market, as
    the VAX was a great FORTRAN engine.  Now we have lots of large
    commercial customers betting their business and their financial jewels
    on VAX/VMS systems.  The installed base of commercial VAX systems is
    huge.  Helping these customers CO-EXIST with ALPHA initally will be
    more important than trying to help them migrate off VAX to ALPHA.  We
    need to crank up the warm & fuzzys for these folks as they are very
    risk (pun intended) averse.
    
    Also, during the late 80s and into the 90s, there has been a migration 
    away from VAX/VMS in certains markets to UNIX systems and PCs.  If
    ALPHA is to be successful, that migration needs to be handled.  What
    will ALPHA be doing to address the UNIX market that is growing
    multiples faster than the VAX/VMS, as is the PC & LAN market?
    
    Mark
    

    I'd like to expound a bit on one major weakness which others have
    mentioned regarding the PDP-11 to VAX migration: field support.
    
    Back in the early 80's, I worked for a software firm which needed to
    branch its product line into the VAX/VMS space.  Imagine our pain when
    we found out that the high-priced Digital "expert" sent to help us
    master the new technology knew _less_ than the little we already knew
    about the machine.  Imagine our anger when we later discovered that he
    was hired by Digital after being fired by another software house for
    incompetence.
    
    Now that I've been in EIS for 4 years, I can understand how and why
    this scenario occurred.  Normal EIS activity is business-event driven. 
    If there is no call for a particular skill set, there is normally (a)
    no training and (b) no hardware/software to play with.  The "old
    thinking" is to go and hire a new body ASAP with an existing skill set
    which matches the current business need.  Existing bodies are often
    trained via "trial by fire" -- send them out to sites uneducated and
    they will educate themselves by the time they return.
    
    In short, this sucks.
    
    I would _STRONGLY_ suggest to the powers-that-be that the ALPHA program
    include an aggressive training and HW/SW distribution program for the
    field.  There should be buy-ins, both _early_ and _strong_, from the
    appropriate EIS managers that such a program _will_ be implemented
    faithfully.  Otherwise, we will likely face some some nominal program
    (such as the local DELTA non-effort) which will accomplish a few
    trivial things, while leaving the major issues for the field bodies to
    resolve on their own.
    
    Aggressive measures can bring about results.  We had almost no one
    spun up on VAXstation software until some Engineering-based (I believe)
    program appeared which allowed our District to obtain VAXstation 3100s
    for little or no cost (I don't know the details).  Now, we have a
    number of specialists who are comfortable (at least) with VAXstations
    and have had a chance to use many of the VS-based software packages we
    offer.  We now have a fighting chance to provide _real_ service to
    accounts with VAXstations; we didn't have that chance until this past
    year, when the boxes arrived.
    
    Bottom line: get _serious_ training and resources to the field _early_!
    
    Just my loud-but-still-somewhat-humble (well, maybe not so humble 8^)
    opinion.
    
    -- Russ

    I strongly seconds Zot (-.1)'s opinion. We have nowhere to hire people
    who already knows Alpha.
    
    To reconfirm what is happening in EIS here, there is no training unless
    there is business requiring the skill set. Trial by fire is the order
    of the day, and out here in the far east, no one gets training in the
    US or Europe unless it last 1 month (unlikely), and we have nothing
    else urgent to do (even more unlikely).
    
    sorry if I sound cynical, hw
    

-------- Forwarded Message
IBM to sell VMS emulation software through cooperative software partner
MAR 12 1991 0846

- - -0- 1345GMT

  ANDOVER, Mass.--(BUSINESS WIRE)--To accommodate Digital Equipment VAX users 
that want to benefit from the new IBM RISC System 6000 UNIX workstation and 
protect their large VMS investment, Boston Business Computing Ltd., and Ki 
Research, based in Hanover, Md., announce ``vaxpax,'' bundled VMS-emulation 
software for the IBM RS/6000.

  The vaxpax product includes a VT320 emulator; a VMS command shell and 
utilities, mail interface, and text editor; and DECnet and LAT network 
capabilities.

  According to Edward J. Gaudet, BBC's marketing manager: ``Vaxpax is the 
first product for IBM's RISC platforms that offers VMS users a complete 
migration path.  Clearly, IBM is looking to gain market share in DEC's 
backyard.  The vaxpax product leverages IBM's pursuit for dominance in the 
UNIX workstation market.''

  Under the terms of the agreement, Ki Research and BBC will jointly integrate 
the following existing products into vaxpax: Ki Research's KiNET software; 
Century Software's TERM, VT320 terminal emulation software for UNIX; and BBC's 
suite of VMS-emulation software - EDT+, VCL, Vmail and Vnet.  Ki Research, an 
official IBM Cooperative Software Partner (CSP), will act as the main 
distribution channel for the product.  In addition, IBM will market vaxpax 
directly through its sales force.

  Jim Corrigan, manager partner at Ki Research, states: ``Ki Research and BBC 
are providing a substantial productivity product which will let VMS users take 
immediate advantage of the compute power of the IBM RS/6000 and continue to 
use their familiar VMS commands and utilities, VT320 terminal capabilities and 
DECnet and LAT network resources.  It's the most complete set of software 
available today that lets VMS sites benefit from UNIX while maintaining their 
overall productivity, user investment and competitiveness.''

  All products are available now.  For more information, call Boston Business 
Computing at 508/470-0444, ext. 303 or Ki Research at 301/553-0181.

  NOTE: EDT+, VCL, Vmail and Vnet are trademarks of Boston Business Computing 
Ltd.  All other product names are registered trademarks of their respective 
manufacturers.

           CONTACT:  Boston Business Computing, Andover
              Edward J. Gaudet, 508/470-0444, ext. 303
                  or
              Ki Research
              Jim Corrigan, 301/553-0181
categoryIndustry I/CPR I/SOF
categoryMarketSector M/TEC
categoryGeographic R/MA R/NY
categoryCompany DEC IBM

    Mr. Corrigan, by the way, is an ex-Digital employee (at least I believe
    it's the same guy). He used to be a network weenie in the UNY district.
    
    Al
    

    	Here I was the person suggesting we DON'T talk about Unix and Alpha
    in this note. However, it brought to mind an issue that I think we'd
    better not ignore. It's something our customers have yelled and
    screamed about in the past, particularly in the workstation space. This
    issue arose AFTER we had a VAX installed base but before the MIPS/UNIX
    strategy had really gotten off the ground.
    	We want our customers to believe we're in the Unix business as well
    as the VMS business. However, many of our customers still believe we're
    not very serious about Unix and just want to keep ramming VMS down
    their throats. It's not a universal perception, but it's out there.
    	When we've announced new VAX systems (like the 9000) over the last
    few years and have only announced VMS support (Unix later), it
    reinforces this bad perception. Our customers see Unix as a second
    class citizen at Digital and so have moved to other vendors for
    Unix-related products. The MIPS/Unix strategy in workstations/servers
    has helped that perception somewhat, but many customers are still
    skeptical.
    	The point is that we'd better have the message straight when we
    announce Alpha systems. I think it would be a GIGANTIC mistake to
    announce VMS support only or Unix "sometime later." Here's a new
    platform intended to be the new flagship to replace VAX. We'd better
    have some strong Unix messages to go along with it or the product is
    doomed.
    	I don't know what an Alpha/MIPS/Unix strategy would look like. I
    just think we need one. I think there's a real danger of screwing this
    up royally since Unix and VMS are under two different VPs now, pursuing
    two distinct strategies and targetting different customers. So a
    special effort will be needed by the Alpha program office to pull
    together a coherent model.
    	We'd better face reality in today's market and tell them what they
    want to hear, or Alpha will be too little and too late.

    I agree.  Some time ago I had a chance to speak with some of the folks
    at Thinking Machines.  They use a VAX with ULTRIX running.  They
    badmouth ULTRIX as being a poor implementation of UNIX.  What would it
    take for them to move up to Alpha?  They would probably warm up to the
    idea that Alpha is a superior platform for UNIX.  That may be true
    already.  But, the marketing of the idea needs to emphasize the
    superiority of Alpha as a UNIX platform, as being even better than a VAX.
    Otherwise, the risk is that you lose current VAX users that take the 
    Alpha/VMS release as indicating less commitment from Digital to UNIX.
    These folks might then drop VAXen altogether.
    
    Steve

    I'm confused.  The information that I have been given regarding ALPHA
    was quite clear.  ALPHA would NOT support the Ultrix operating system.
    
    Have I been misinformed?
    
    	Don

In a recently published interview, Bill Demmer said that Alpha would run both
VMS and Unix.  Our officially announced intention is that Alpha will be a VAX
replacement and it will run VMS--no mention of ULTRIX.  Make of this situation
what you will.

Personally, I think it would be damn foolish not to offer ULTRIX or some other
Unix at hardware FCS.  If we don't offer Unix on the machine, you can be sure
that SCO or somebody else will port a Unix implementation to it within a few
months of the hardware shipping.

--PSW

    "Alpha will be able to run both VMS and Unix ..."
    
    I've heard that.  But it was explained away as Unix applications will
    run on POSIX-complient VMS.  Not that Alpha would actually support an
    Ultrix operating system.
    
    Is Ultrix scheduled to be available for Alpha?  Anyone really know?
    
    	Don

    Back to basics, people.
    
    The product has certain capabilities, scarce development resources are
    being allocated, a marketing strategy is being written, etc.  For
    crying out loud, hardly a week goes by without interviews, speculation,
    etc. regarding Alpha.
    
    If there's a customer requirement that may not be part of the plan, let
    the people who want to know about these things know about it.  Stop
    asking "will it or won't it", start saying "customers need it".
    
    Of course, this is no guarantee that this process works, but it's
    better than assuming the customer requirements will all be satisfied.

    Please, PLEASE, refrain from discussing Alpha technical or
    other product-related issues here!  If you have questions about Alpha,
    contact the program office.  This is NOT the forum for discussing
    Alpha itself, and improper disclosure or remarks could possibly
    cause serious damage to the Alpha project and Digital.
    
    Please confine discussion to the general topics outlined by
    Al Avery in his base note.
    
    Thank you for your cooperation.
    
    				Steve

    
    Re: .69  Thanks, Steve.  That is right on.
    
    The Alpha Program Office is well aware that there are lots of
    issues to address.  Let me leave it at that.
    
    Steve
    

        What Steve wrote in .69 is absolutely correct.  Please DO NOT
        write anything here that discloses any specific technical detail
        of the Alpha program.  Your note WILL be deleted, but there is no
        way the moderators can assure that it will not have been mailed
        outside the conference or otherwise disclosed in ways you may not
        expect or desire.  
        
        Tom

    I know the base note's title says "PDP-11 to VAX transition", but
    are there lessons to be learned from the 11M to 11M-Plus transition
    as well?
    
    11M was perceived to be bumping against limits imposed on it
    by needing to support teeny machines and big machines.  Lo, 11M-Plus
    was born (well, the 11/74 MP might have had something to do
    with it as well!) for high-end machines only -- the 11/70 at
    first release, but other, newer machines were later supported.
    
    11M-Plus was supposed to be a superset of 11M.  Programs written
    for 11M could be taken to 11M-Plus without change (and I think
    this goal was met - at the time, I was an RSX hack, and I don't
    remember any porting problems, except for occasionally having
    to remember what the I/O database looked like when wandering
    around on the kernel stack).
    
    I seem to recall that 11M customers got a bit annoyed because some
    desirable new features were only added to 11M-Plus.  I suppose
    it looked rather like 11M had been abandoned.
    
    This is rather vague in my memory - anyone know any more 
    accurate details?
    
    The 11M/11M-Plus case is different to VAX/Alpha, in that it
    wasn't about new hardware per se, but a decision to fork
    one stream of development into two.   Nevertheless, if anyone's
    yet considering the degree to which VAX/VMS and Alpha/VMS are to
    be permitted to diverge in the future, there might be some useful ideas.
    
                                

As a customer, the company where I was working was selling oem systems with RT11
and/or RSX on them and this coumanies software on top.  We were doing
development on RSTS on a PDP-11/60 (which was supposed to grow to 11/70 memory
capabilities at the time we bought it, but as we all know it never did).

When the business grew large enough and the number of users was too many for the
11/60, we needed to decide on a new development machine.

THIS WAS, NOTE, in the time of PRODUCT LINES.

Our choice was either an 11/70 (A hot, expensive, machine compared to an 11/60,
the 11/44 was not available) or a VAX, about VMS V3.0 time frame.  Using retail
figures, the engineers opted for the VAX 11/750 and built an equivalent to and
11/70 where the 750 was cheaper for more bang for the buck (we belived and it
proved out).

Cross development was no problem, we used Oregon Software PASCAL for the 11's
which ran well in compatibility mode.

Now understand please,
	1) the VAX was recognized as a good direction to go
	2) Technically we could get more time sharing capabilities for the
	   development environment (and hopefully more reliability)
	   with the 750.
	3) This customer bought and shipped hundreds of LSI-11 and 11/23 based
	   products.

The problems started when the president of the company talked to the salesman

As an LIS 11 (11/23 also) customer, we could buy an 11/70 at a (I think) 10%
discount as a development machine.  (If we didn't want it as a DEVELOPMENT
machine, stated as such, we would have paid quantity 1 since that was a
diffrent product line).

We also could order a VAX 11/750 AT NO DISCOUNT since it wasn't considered
a development machine for the 11's.   (Through some magic, the salesman
who's account we were, managed to get us 5% off and we bought the VAX).


My messages:

1) IF THE CUSTOMER IS A VAX USER/OEM AND ORDERS/SHIPS N MACHINES A YEAR SELL
   THEM AND ALPHA, OR ALL ALPHAS AT QUANTITY N FROM THE START.  They may want
   only one or 2, but it will expose their staff/engineers and provide faster
   buy in to the new Architevure (better yet, GIVE all OEMS their first ALPHA).

2) In improving our sales strategy, DON'T EVER go to such statically separated
   product lines again.  We have enough trouble implementing cost savings in
   a "profit" center from an "overhead" center where the overall benefit would
   be positive to the corporation and "overhead" center, but negative to the
   "profit" center