Conference 7.286::digital

    Interesting that you should notice that picture.  It doesn't look
    anything like our data centers.  At least not within the last five
    years.
                                                                
    We run all of our data centers with Digital Equipment Corporation
    computers exclusively.  The only place you will find an I*M is in
    engineering where they study them.  (I suppose there *might* be an
    exception somewhere).

I would be very surprised to find that Digital processes payroll for 
120,000+ employees on anything other than a mainframe.  Other than
the old DEC 10, etc, line,  we don't build mainframes.

Anyone know for sure what we use?

Bob

    RE:.2
    Yes, we do build mainframes!  What else do you call a VAX 8800?
    
    I worked in DIS from 1980-85.  They used lots of DEC-10s, and phased
    in VAXes.  Not a blue box in the shop.  For a while, the corporation
    seemed to be growing too fast to do our own DP, but we kept up,
    and with VAXclusters can handle big jobs like the rest of them.
    (We just can't do it with magtape, only disk, and with terminals
    instead of punch cards.  Hardly a real disadvantage!)

    Look closely at the picture...looked like KL10s and RP03s to me...

  >  I would be very surprised to find that Digital processes payroll for 
  >  120,000+ employees on anything other than a mainframe.  Other than

    
    Don't under-estimate our computers.  Why do you need a mainframe
    to to payroll...  An 8800 could handle it, as could an 8700, probably
    even an 8530.  In the end it would just take longer to run...
    
    A IBM 4341 is considered a mainframe by many, but an 8530 has more
    CPU horse power than it.  An MVII has just a little less (correct
    me if I am wrong).  Size of box/peripherals has a lot to do with
    it for most people.

    Funny...I always thought that our 8974 and 8978 were our entry into
    the Mainframe market.
    
    Could I be wrong?
    
    Doug

    No, DIS uses Digital computers.
    
    It is the mindset (like .2's) that they get from IBM.

        And Digital does not do a 120,000+ payroll on one computer. Europe
        et al, do their payrolls locally...
        
        q
        

    I heard a while ago (say 3 years) that we are the only major computer
    corporation that uses *only* our own gear to do *all* of our internal
    computing functions.
    
    Naturally that doesn't count the odd PC or even mainframe which
    are used for engineering, demos, etc.  But all of our internal
    production work is DEC based.
    
    Makes sense to me!
    
    K.

    By the way....U.S. payroll was processed on  a 4 node cluster. When
    I left the group in May '88 it consisted of 2 8700's and 2 785's. In
    fact, some customers were impressed that we processed 80k + checks
    a week on the cluster.
    
    						Paul
    						(former payroll cluster sys mgr)

    Why so much CPU power is needed to process checks?  I mean isn't
    it just a matter of updating, copying and printing?
    
    Enquiring engineers want to know :-) :-).
                                                
    Eugene

        re .-1
        
        Well, one takes the input. i.e. Timesheet. The computers then have
        to cross post all the project specific person hours to those
        projects. Shift loadings, overtime etc etc all cause variations
        which have to be checked. Taxes have to be calculated (across
        several states). Print 80,000 payslips is hard work, even for a
        large print engine. Vacation records need to be updated. Automatic
        payments to dozens of different banks need to be collated and
        organized. etc etc....
        
        q
        

Well!   Apologies to all Deccies for insinuating that we might use a
mainframe to do our payroll.... we are obviously an exception to the
rule!  Good for us!

A couple of points...

   I don't consider the 8800 series of computers "mainframes."  That
was not their intended design, although the definition of a "mainframe"
is somewhat vague.  The industry still considers them to be super-mini's.

   Also, payroll is not so much a CPU intensive task, as an I/O intensive
task, hence the desire to use a mainframe, rather than a supermini or cluster
thereof.

   I think it's great that DEC uses its own equipment for its payroll.

   I also think that if I were runnning a company of 120,000+ employees, 
and was not in the business of making computer systems, I would use a 
mainframe.   Thats the right tool for the job.

   Mainframes DO have their place... otherwise we wouldn't be trying to 
build one.

        My 2.44 yen

                    Bob

    Many of the last notes seem to dwell on the terms mainframe, mini,
    midi, maxi, and the presence or not of the adjective super.
    
    Those terms, and their combinations, may be useful for marketing
    purposes, but they are not useful technical terms. It is very hard to
    get people to agree on the definitions, and whatever the definitions
    are, they change rapidly with time.
    
    For example, why was it reasonable for the Digital payroll to be done
    on a DECSYSTEM-10 "mainframe", and not on a VAX-8800 "supermini" (or
    whatever non-"mainframe" term you like) when the 8800 has more
    capability? 

    re .14
    
    Tom, you've fallen into your own trap - what exactly is "capability"?
    
    Jon

>>    For example, why was it reasonable for the Digital payroll to be done
>>    on a DECSYSTEM-10 "mainframe", and not on a VAX-8800 "supermini" (or
>>    whatever non-"mainframe" term you like) when the 8800 has more
>>    capability? 

For the same reason it was possible to do payroll on a System 360 and not
on a PDP-8.

Bob

    
    re .-1;
    
    The key word is "reasonable", not possible. It's possible to do
    payroll on a TRS-80, if you want to do it once a month!
    
    What the term "reasonable" implies is more one of acceptance, not
    technical feasibility. It also implies acceptance by upper management
    and other non-technical folk. 
    
    Saying a mainframe is the right system for the application without
    strictly defining what a mainframe is sounds an awfull lot like a
    marketeer talking. Certainly no technical meat there!
    
    Why is a system (not just ours but anyones?) with more speed and
    system throughput than accepted low-end mainframes not considered one?
    Sounds like an image problem to me. Too many high-paid "Mainframe
    experts" would have to justify their pay!
    
    Ray
    

    Re .13:
    
>   I don't consider the 8800 series of computers "mainframes."  That
>was not their intended design, although the definition of a "mainframe"
>is somewhat vague.  

    Well Ken Olsen does.  And so do I.  I would like to hear what
    definition you use that excludes 8800's and even more importantly
    VAXClusters from being mainframes.  It certainly was their intended
    design.
    
>   Also, payroll is not so much a CPU intensive task, as an I/O intensive
>task, hence the desire to use a mainframe, rather than a supermini or cluster
>thereof.

    I assure you that large VAXclusters have I/O capabilites that would
    leave most 'mainframes' (by your thinking) in the dust.
    
    I currently am on the system management team of a customers VAXcluster
    that has more CPU than most 'mainframes', more disk space, lots
    more I/O bandwidth, more connectivity, more applications, etc. 
    And it supports a larger user population than any mainframe I have
    ever heard of.  And this is this customers SECOND largest cluster!
    Their largest is 50% bigger than this one.
    
    --  Barry

    
    We may in fact compete with mainframes, but few people outside DEC
    believe we build them anymore.  And few people realize we ever did.
    LCG built the only channel architecture systems I can recall.
    To most people you can no more call an 8800 a mainframe than you
    can call a MAC 2, or PS/2 a minicomputer.
    
    Incidentally, I doubt we make anything that can match the aggregate
    I/O throughput of the big Sierra's.  Let's not take our own marketting
    too seriously, ok?
    

    Re: .17
    
    Applaud.
    
    Re: .18
    
    Quite right.  I myself will not make a comparison between an 8800
    and a mainframe, however, when you start talking about clusters...
    that's where the competition is.
    
    DIGITAL's thrust of competition in the marketplace has been to
    cover the computing range from small minicomputer (ie. the MicroVAX
    2000) all the way up to a Mainframe "size" machine (ie. the 8978).
    Then the kicker of course...the same exact operating system runs
    on every single one!  No other company in the industry can say that!
    
    Now, the 8978 may not be considered by certain "experts" in the
    industry as a mainframe, but it's purpose was to directly target
    that market!
    
    I guess it all comes down to what was said earlier about what you
    consider a mainframe...if by definition a mainframe has to have
    a processor architecture with more than 32 bits...then a VAX ain't
    it.  But then, a VAXcluster just might be more powerful than certain
    mainframes...   *;'}
    
    Sorry for the rat-hole...but I just had to vent it,
    
    Doug

    Mainframe - noun.  A physically large and difficult to use computer
    system that requires an absurd number of technical people to maintain.
    See also, IBM
    
    Bob

>    consider a mainframe...if by definition a mainframe has to have
>    a processor architecture with more than 32 bits...then a VAX ain't
>    it. 

	By that definition am IBM 360 or 370 isn't a mainframe either.

			Alfred

    re: .19
    
    A VAXcluster is a channel architecture system.  The HSC50 is just
    as much a channel as the DF10 was: it reads and writes memory without
    CPU intervention.
    
    What is the aggregate I/O throughput of the big Sierra's?
        John Sauter

    How to classify a computer based on its processing power is
    quite a difficult task.  What was once a mainframe task can
    now be easily performed by a processor that sits on your desk.
    Besides what is one company's supermini is equivalent in power
    to a different company's supermicro or even minisuper!
        
    No, a different measurement is needed.  I humbly propose the
    following taxonomy:
    
    pc = A computer that you can buy over the phone without even
        first seeing it.  FedEx people deliver it.

    mini = A computer that when you buy it, you take it out
        of the shipping box by yourself though you probably
        won't want to service it yourself.

    supermini = Is distinct from a mini because someone else will
        unbox it for you though you will have to carry the cardboard
        out by yourself.
    
    mainframe = If you have one, it means that not only does
        someone unbox it for you but various people stay around
        afterwards to see if all the blinking lights blink.
        In fact, they may seem like they have taken up residence.
        The unboxing specialist may very well be wearing better
        clothes than you do.

    supercomputer = Anything that is more powerful than last
        year's supercomputer, ad infinitum.  You can tell when
        you have bought a supercomputer because school children
        are always arriving on field trips to see it.  It is
        often situated in a glass-walled room and administered
        to by people actually wearing 1950's SciFi lab coats.

    re .24:
    
    Here are my definitions:
    
    PC --  Do game playing word processing and nothing else.  Any machine
           that runs DOS.
                           
    Work Station -- Do windows to bigger machine.
    
    Mini -- Machines you archive the files you never use.
    
    SuperMini -- Machines that do any real work on batch/background
                 and usually takes overnight.
    
    Mainframe -- Machines engineers do not want to use.
    
    Supercomputer -- Machines that only run FORTRAN.
    
    :-) :-).                      
    
    Eugene
                                                        

    My father (who had used computers from their infancy) and I (who
    "got" an HP45 in 11th grade in 1975) had tremendous arguments about
    whether HP41 "handhelds" were in fact computers. This whole subject
    is such a good definition of rathole that .24 is the best antidote
    - a humorous alternative viewpoint. I concur completely with .24.
    It really indicates, irregardless of this year's leaps in added
    mips, what level of computing you are at. 
    
    And no, I didn't think the HP41 was really a computer. But did it
    matter? 
    
    erik
    

    Re .19:
    
>     Incidentally, I doubt we make anything that can match the aggregate
>    I/O throughput of the big Sierra's.  Let's not take our own marketting
>    too seriously, ok?

    Perhaps you've heard of VAXclusters?
    
    I think that its a real shame our own employees take IBM's marketing 
    so seriously.  No wonder so few of our customers know better.
    
    I stand by what I said.  I work at a customer VAXcluster site whose 
    aggregate I/O throughput is greater than 90% of the worlds IBM
    "Mainframe" systems.  Thats not marketing, thats a fact.  In fact
    I really wish that our marketing organization would pay more attention
    to this.

Like I said, there are a lot of ways to carry 100lbs of sand...

You can use a 100lb sack, or twenty 5lb sacks ... And it all comes down 
to trade offs.  Vaxes are not the be-all and end-all of computing, and are
not the "right solution" for all situations.   To try to argue otherwise 
is not reasonable.

As with all computing solutions, there are tradeoffs.  If you use a 100lb
sack, you only have to load one sack, but if it breaks, you're in trouble,
and if you only have 40lbs of sand, you're inefficient.

If you use twenty 5lbs sacks, you are not in as much trouble if one sack 
breaks, but you have to handle loading multiple sacks, and you're in
trouble if you need to get 10lbs in the same sack...

I hate IBM marketing BS as much as anyone, but you can't argue with the 
power of a 3090-600.   Fortunatly, we can argue the price/performance
for customers who don't need that much horsepower in one shot.

Bob

    The problem with your analogy is that is does not apply to VAXes
    and 3090's and the applications that we are talking about in the
    topic.
    
    The only thing that is critically affected by single-CPU power VS.
    multi-CPU power is single-stream turnaround time.  Ie. when you
    must get something out as fast as possible and you cannot multi-stream
    it and you are willing to shutdown everything else on your system
    to get it done.
    
    With years of experience in commercial programming I know of no
    commerical or accounting type application that requires that.
    Almost ALL financial applications are ideal candidates for
    multi-streaming and parallelization.  And it that case 10 6-mip
    cpu's are just about as good as 6 10-mip cpu's.
    
    Everything else is just IBM's marketing hype.

    re .29
    I got my M.S. at the Center for Supercomputing R&D in Illinois,
    and my impression about supercomputer is that there is a very limited
    number of scientific problems that need true supercomputer performance.
    If this is also true in the commercial market (as you said), wouldn't
    everyone go out and buy lots of uVAXen or Sun's and cluster them
    together rather than buy big systems.  I mean the MIPS/dollor
    is much higher with the low end systems.
    Eugene
    

    MIPS per doller isn't the only consideration.  For commercial
    applications, I/O bandwidth is also critical, and sometimes printer
    speed as well.
    
    Another important consideration is, or should be, development and
    maintenance time.  Commercial data processing shops generally have
    a large backlog of development and maintenance that is waiting to
    be done.  A computer system has (or should have) increased value
    if it lets them cut their backlog without increase in personnel.
        John Sauter

Now that sounds like *OUR* marketing hype!   Really, gang... I own stock...
I'd love to see the commercial world come around to our way of thinking, and
I think we are on the right track.

However, that doesn't explain the continuos increase in mainframe sales in
the commercial marketplace.  Someone's buying them... there must be a reason!
IBM's marketing?  Probably accounts for a lot of it.   But there still must
be applications that justify the use of mainframes vs clusters of minis, at
least in the perception of the customer, if not in reality.   So I think our
job is to change that perception.

However, we have to avoid the position that says "We can do anything a 
mainframe can do"... because the customer isn't going to buy it.  Even if
it were true.   

Bob

    I agree with .32, but I can't help think that, although there may be
    SOME good reasons for buying I*M, the most predominant one I've seen in
    the I*M ships I've been associated with in the field is summed up in a
    saying I heard once:
    
    		DON'T CHANGE: INERTIA IS A TERRIBLE THING TO WASTE
    
    The best reason to buy I*M is cause you've already bought one (and
    brainwashed the staff, and gotten the high up politicos indebted to
    you, etc., etc.)
    
    Jim
    

    re .33
    This reminds me a conversation I once had with a professor who used
    to work in the industry.  He gave me the followig senario:
    
    Suppose you work in a commercial company as a computer expert, and
    your boss tell you to shop a computer for the company.  If you buy
    an I*M, and later the computer screw you up, you boss will say:
    "Dam, I*M sucks".  On the other hand, if you choose some other vendors
    and the computer later screw you up, you boss will probably say:
    "You are fired".  Of course, this is an extreme senario, but....
    
    Eugene
                         

Fortunately, the old adage that "No one ever got fired for buying IBM..."
no longer carries as much stigma as it used to.  There are, as .-2 said,
many reasons to preserve the status quo... the most obvious of which is 
the investment in custom software.  

For some good reading on why mainframes, particularly the Blue ones,
are doing so well in the industry, as well as a good inside look at how
IBM does business, I highly recommend a book called "Big Blue:  IBM's 
Use and Abuse of Power", by Richard Delameter.   The author was an
economist with the US Department of Justice, who worked for 8 years on 
the IBM antitrust case.   That case, incidentally, was mysteriously 
dropped shortly after the Reagan Administration came to power.

If all of our customers read this book, we wouldn't be having this 
conversation... 8-)

Bob

    Uh, I hate to be the one to point this out . . . but, IBM systems
    work.
    
    In the high end, IBM systems have us outgunned by a large margin
    in performance (both single stream and multi-processing), in I/O
    capabilities, in Transaction Processing, in Databases, in Operating
    System (for mainframes -- minor little matters like backup, for
    example), in business applications, and in wide area networking.
    
    On the other hand, the big IBM boxes are extremely expensive, require
    a large support staff, are not especially good interactive systems,
    and are not the worlds most productive programming environment (I'm
    a VAX bigot today because I learned to program on IBM).
    
    We have a strong competitive position against IBM today, because
    of our interactive, distributed, networked systems.  We have a strong
    future, because of enhancements to our distributed systems,
    workstations, and new high end machines.
    
    But let's not kid ourselves -- IBM can do the job for the customer.

        Russell, you are mistaken on several of your points.  However, I
        will concede to you that IBM systems do things IBM's way MUCH
        better than our systems do, and IBM has managed over many years to
        build up a loyal customer base who only understand the IBM way of
        doing things, and aren't interested in changing, even if change
        would be economical.  Many people are afraid of change.
        
        Tom

    Reply .35 introduced some partisan politics into this topic.  There was
    no mystery, the government decided that there was insufficient evidence
    to proceed with the case.  The first charges in this case were filed
    during the Johnson administration by the way.

    Re: .37
    
    Tom, I'd like to know which points (to .36) your disagree with.
    
    I don't particularly like the IBM way.  I believe that Digital is
    THE only company to effectively compete with IBM because we have
    a fundementally different approach than IBM -- one that works well
    in many cases.
    
    The point I wanted to make is that IBM systems do work, and are
    able to meet customers needs -- in some cases better than Digital.
    
    Times are changing.  Digital is beginning to address the mainframe
    market (new Transaction Processing efforts, high end systems, more
    effective distributed systems, etc.).  IBM is addressing the
    departmental, VAX-class market with the AS400.
    
    Our real challange is to meet our customers needs.  If we do this
    better than IBM, we will win.  If we decide to compete against the
    3090 (in other words, focus on IBM rather than our customers needs),
    we will not be as successful.
    
    Final thought: change isn't necessarily good (nor is it necessarily
    evil).  A customer that decides to continue with an IBM solution
    may have many reasons -- including a proactive decision to invest
    resources and Attention Units in other areas -- such as manufacturing,
    new product development, corporate acquisitions, or other areas.

        Russell, you stated that IBM is better than Digital at many
        things, such as wide-area networking.  Actually, Digital is *much*
        better than IBM at wide-area networking; the EASYnet is a case in
        point.  HOWEVER, if you buy into IBM's definition of how you
        should do wide-area networking (SNA), then Digital is lousy,
        because we don't do SNA wide-area networking.  Some customers are
        so ingrained in the IBM approach to using computers to solve
        business problems that they simply won't consider using Digital's
        systems, but that doesn't mean we can't solve their problems --
        they just won't let us help, because they want us to do it IBM's
        way. 
        
        We're in violent agreement on the conclusion -- IBM does things
        IBM's way better than Digital can do things IBM's way, but
        Digital does things Digital's way MUCH, MUCH better than IBM
        can do them.  The real determinant of success will be how well
        we can satisfy our customers' business needs, not whether we
        can beat IBM at their own game while playing by their rules.
        
        Tom

    Tom,
    
    I tend to agree with you, especially on your last point.
    Unfortunately, my recent observations out here in the field shows
    IBM beating us badly in the 'meeting customer needs' department.
    
    I've been away from this conversation for a bit, so to go back in
    time a little: some earlier comments struck me as a bit smug, and
    seemed to sound like we take our own hype too seriously.  IBM beats
    us regularly, in marketing, in customer support, and in raw,
    unadulterated throughput.
    
    It's naive to think the competition is actually inferior, in the
    face of evidence to the contrary, and presumptuous to blame the
    customer for being too stupid to see our true light.  I just hope
    our competition is dumb enough to take that attitude about us.
    
    And yes, I have heard of VAXclusters.
    

    IBM does wide-area TERMINAL networking way better than we do.
    
    SNA was designed to attach block-mode terminals to centralized hosts.
    It does that well.  DNA does many other things well, but we don't
    particularly like the idea of centrlized hosts and distributed
    terminals, and we don't use their style of terminal (forms-filling),
    but for centralized OLTP, SNA is very efficient.  Async terminals
    like ours don't do well on WANs.  (Our best response, of course,
    is distributed processing; DECintact puts the terminal handling
    on a local machine and talks to the central data base using DECnet
    at its best.  But even that's a new product for us:  We have to
    sell our superior alternative to people satisfied with IBM.)

        IBM doesn't even do wide-area terminal networking better than
        we do, unless you accept their model of computing (which is,
        for the most part, OLTP) as the right one, and then they only
        do it better if you believe that the right way to implement
        an OLTP system is with block-mode terminals, relatively dumb
        controllers, and huge central systems.
        
        DECintact's ability to off-load terminal handling onto remote
        front-end systems is nothing new; we've been able to do the
        same thing with ACMS/TDMS for quite some time.  Having Digital
        support for the "Intact" style of implementing OLTP systems
        is something new, and since some of our very large customers
        depend on the "Intact" implementation, it's good for us and
        good for them that we now have a Digital-supported product
        for them to use, but it doesn't introduce new capabilities.
        And VTX with the VALU application interface can do a very good
        and very efficient job of connecting remote terminals to central
        applications in a way that makes the terminals function much
        like IBM's block mode terminals (as do DECintact or ACMS/TDMS).
        
        I would hesitate to claim that we don't particularly like the
        idea of centralized hosts and distributed terminals; many of
        our administrative systems still work that way.  It has been
        only in the last few years that we've started to provide some
        truly distributed applications, and we still don't have many
        of them.  At least part of our success in implementing such
        systems came from our historical implementation of ANF-10 and
        ANF-11 networking (on TOPS-10 and PDP-11 systems), back in
        what to many is the dark ages (pre-historical times for those
        who don't remember that far back).  ANF did a VERY efficient
        and flexible job of connecting remote terminals to large central
        hosts, and also did a reasonable job of supporting remote batch
        submission and remote printing.  What it didn't do particularly
        well was task-to-task (peer) communications, something that
        DECnet does very well, while compromising on terminal connections.
        SNA has a design center that's similar to that of ANF, and
        has many of the same drawbacks for implementing distributed
        applications.
        
        However, since so many of our customers use their systems in
        ways that are served just fine by the SNA-style of networking
        and the OLTP block-mode style of interaction, it's not much
        of a surprise that IBM can sell so many systems, since they
        are VERY GOOD at many things.
        
        Tom

re: < Note 673.43 by DR::BLINN "Don't panic!" >
        
>        DECintact's ability to off-load terminal handling onto remote
>        front-end systems is nothing new; 

True... IBM 3x74's have been doing it for years.  I disagree that they are
"dumb controllers."   

Bob

    
    re several.
    
    There seems to be a pervasive opinion about IBM mainframe customers
    as dumb or inert or fearful about change. While this may be true
    in some cases (e.g., Brophy of Travelers), most other customers
    go about their decision on a cost-benefit basis. Some of the points
    they consider are:
    
    Benefits (of switching to Digital):
    
    	- lower personnel cost
    	- lower system (HW+SW) cost (debatable depending on how you define it)
    	- lower development cost
    	- intangibles like flexibility, distributivity etc.
    
    Costs of switching to Digital are (they do exist!):
    
    	- SW conversion/rewrite cost 
           (can be substantially larger than HW investment!)
    	- re-training cost (can be large esp. if 1,000s of users have
           to be re-trained in using the application)
        - risk (new HW/SW, new vendor, untried approach etc.)
    
    Above are just some examples. When the total benefits (in terms
    of $) significantly exceed the total costs, will the management
    go for the switch. In most cases involving NEW applications, Digital
    can come ahead in these calculations (assuming that our sales and
    sales support people understand cost-justification and supply the
    necessary data to the customer!) whereas for existing applications
    (which take up 80% of DP budget anyway), it not easy to cost justify
    a switch to Digital.
    
    If you look at cases where we took marketshare away from IBM, most
    of those involved new applications. Very few conversions from
    existing mainframe applications. To get a real crack at these 
    citadels, one must hope that the existing applications will
    become obsolete fast (we can help by moving technology far ahead
    so that competitors of these customers get armed with better tools
    thus forcing the switch from target customers) or that our systems
    (HW+SW) cost so little compared to IBM or give such high added value
    that the cost of switching is recovered easily (real tough job!).  
    
    
                                   
    RV

        Perhaps further discussion of the marketing aspects of this
        topic, especially vis-a-vis IBM customers switching to DEC,
        should take place either in ASIMOV::MARKETING or KACIE::IBM.
        
        Tom
        co-moderator