Conference 7.286::digital

    Re .-1
    
    What's the surprise in finding out that customers don't know what
    Digital's strategy is? Hell the people that know (assuming there is
    senior management that knows, I sometimes wonder) won't even share it
    with employees.
    
    Dave

    re:.1
    While I generally agree with the sentiments, I am a bit concerned about
    the way the "Folgers' switch" was pulled with the VMS Xterms.  I also a
    Unix-non-fan, and regularly use TCP/IP over VMS via Motif, including
    using DWDOS to bring up DECterms using DR-DOS on my home 386 from my
    office VAXstation.  But if I found out that Digital had pulled the wool
    over my eyes, and I were a Unix weenie, then I'd probably not say,
    "Hey, this VMS is pretty good stuff!  I think I'll buy some!"  Instead,
    I'd say, "Hey, these DEC guys are incorrigible!  They've even managed
    to put a front end on it that looks like Unix, and tried to fool us
    here at SC92!  How can we ever trust them for Unix support?"
    
    Of course, judging by the way the company's been acting lately, our
    Unix support may soon be no better than that.

    re. .3
    
    Nobody pulled the wool over anyone's eyes - intentional or otherwise.
    We handed out a brochure in the mailroom that decribed everything -
    H/W, S/W, Networking. The people that were surprised assumed they were
    using UNIX and never read the brochure. I don't believe ANYONE who was
    at the conference would tell you we tried to snooker them in any way. 
    
    NO ONE!
    
    Gene.

    re:.4
    Hey, no offense intended!
    
    From the way it was described, I didn't read it as being something in a
    brochure that people didn't believe.  Indeed if you say out front that
    it's VMS, then it's all the better.
    
    Just to prove the point, in places like this, I'd like to see both VMS
    and Unix mixed together.  With labels so people can tell them apart,
    but the labels placed so that they have to look.  "Hmmm, let me guess. 
    (looks under keyboard) Hey, it's VMS!"  OR something like that.
    
    I must have misunderstood the report...

    re .3 and .5
    
    Hang on a second - you need to remember why we did this whole thing in
    the first place!  
    
    The report was about the e-mail room, not a trade show booth.  The
    e-mail room was not a marketing showcase or marketing arena.  The
    marketing happened down on the trade show floor.  In our e-mail room, 
    people did real work on their systems back home without *any* marketing 
    hype.
    
    Gene and I and a bunch of other people provided a service for
    conference attendees to use.  We chose what products to use based on a
    bunch of important factors:
    
    	o what we could get
    	o what we knew how to make work
    	o what wouldn't cost an arm and a leg
    
    Nobody fooled anybody or pulled any wool over anyone's eyes.  We
    provided X-window and electronic mail access to the home systems of
    conference attendees.  This was a service, not a product demonstration. 
    The products we used to provide this service are really irrevelevent to
    a user, except for an academic discussion.
    
    - Greg Scott

I noticed you had no X terminals. Next time, take some VXT 2000's.
They require less configuration than workstations, and are cheaper.
We should show these, too. They are quite capable of talking TCP/IP.
You could have both virtual (uses InfoServer for paging) and physical
(no paging) terminals available.

    re. .7
    
    I'll defer the "why no X-terminals?" question to Greg Scott. He is the
    one who decided on the VLCs. He should be in here in a day or so. One
    of the overidding decisions on why the VLCs was that they could more
    easily be re-sold. At order time I knew of two local accounts that were
    interestd in buying some VLCs around the end of Nov.
    
    Gene.

    The reason I didn't want X terminals is, they are a real pig on their
    host.  You just can't put enough memory in your host to support a large
    number of X terminals.  And when your page file fills up, the whole
    world just dies.
    
    We had a VAXstation model 90 with 64 MB memory for a boot server.  With
    10 VXT X-terminals, each with one DECterm window, Motif Session Manager,
    and whatever else needed for a Motif session, we would have sucked down
    that 64 MB on the boot server really fast.  So to fix that, we would
    have needed more memory on the server - maybe something like 128 MB or
    so.  (OK, so maybe 128 MB is overkill at 8 MB per user times 10 users -
    but better a little too much memory then a little bit not enough!)  We
    also needed a backup server in case the primary failed.  So this would
    have needed more memory also.  
    
    CPU-wise, I don't believe we would have seen much gain in logins or
    performance by having an X terminal farm.  DECwindows login is an
    intense exercise.  My gut feel is, 10 of 'em concurrently would have
    put a good sized load even on a M90.  As it was, the VLCs we used were
    not speed demons for login, even with a bunch of sharable images
    installed in DECram.  (I probably didn't install enough of 'em.  It's
    amazing how many sharable images depend on how many other sharable images!)
    
    The compromise would have been to have 2 or 3 "hosts", along with maybe
    a spare, all LAVC'd together.  We could have spread the X terminal load
    over these hosts and had an acceptable configuration.  But now we would
    still have had to configure a cluster *and* we would have had the added
    complexity of the X-terminals.  I didn't spend any time doing
    performance modeling or detailed cost analysis, but my gut feel says
    the price for this configuration would have been close to the price of
    the config we chose.  
    
    - Greg

    
    >Sometimes DIGITAL SHINES!!
    
    reminds me of a dictionary definition...
    
    nova  n., pl.- vae or vas
    
    A variable star that suddenly becomes very bright and then dims over a
    period of time.
    

re Note 2250.1 by HAAG::HAAG:

>    All of the workstations ran OpenVMS V5.5-2, DECwindows MOTIF V1.1, and a 
>    TCP/IP "stack" donated by TGV Multinet, Inc. 

        I note that you used TGV Multinet's TCP/IP rather than
        Digital's own Ultrix Connection (UCX) (or whatever it's now
        called).

        What is the reason?  Does this weaken the message?

        Bob

    re .-1
    
>        I note that you used TGV Multinet's TCP/IP rather than
>        Digital's own Ultrix Connection (UCX) (or whatever it's now
>        called).

>        What is the reason?  Does this weaken the message?

    No, it strengthens the message.  There really *is* a third party market
    for products that run under OpenVMS.  Customers have a choice of
    several TCP/IP packages they can run under OpenVMS and each choice
    gives certain good capabilities.  That's what "OPEN" is all about.  We
    should be willing to try competing third party software products when
    we believe they have capability for a particular job that our product
    lacks.
    
    That's why we we didn't use UCX.  It didn't have all of the
    capabilities we needed for this job.  
    
    We chose TGV Multinet because it's really popular at the University of
    Minnesota and everyone there told us what a great product it is.  The
    Minnesota Supercomputer Center (MSC) hosted SC92, and MSC is affiliated
    with the University of Minnesota.
    
    Lots of people gold Gene and I that Multinet has all the goodies
    expected from a robust TCP/IP implementation and that they really work. 
    We found alot of 'em.  For example, TRACEROUTE.  This is a nifty little
    command to trace the path to any host on the internet.  Really useful
    when people can't get to their home systems - just TRACEROUTE over
    there and see where the hang-up is along the way.  We found problems on
    the east coast one day due to storms.  San Diego and southern
    California had problems another day.  We had some people from computer
    vendors who couldn't get in; found they had gateways that guard the
    entry into their internal networks just like we do.
    
    In general, when somebody couldn't get to their host system - and most 
    systems were 10-30 hops away - TRACEROUTE would prove that our end of
    things was OK and would help diagnose the problem between our end and
    the remote end.
    
    All in all, I think we made the right choice.
    
    - Greg

    My reply about X-terminals caught the attention of the VXT folks.  For
    the record, I didn't mean to slam their product.  I don't have any
    experience with the current products, the VXT2000s.  I've heard from
    several sources that our VXT2000s are great products and I believe
    that.  But I can't say first hand either way because I haven't had an
    opportunity to try one.
    
    My estimate of 8 MB per X-terminal user may have been a little high -
    OK, maybe a lot high.  I've never been one to skimp on memory or disk.
    After looking on my workstation at the processes required for an
    X-window session, it looks to me like it would take 3-5 MB per head.
    
    Anyway, without any experience with VXTs, and being the natural
    arch-conservative I am, I decided to use what I knew would work and
    work well.  I still think it was the right call.
    
    - Greg

    
    ....and how much more equipment could we sell if the sales people
    knew ALL our products?  Because they haven't "had the opportunity
    to try one".
    
    We could be selling "solutions", not just hardware!
    
    No offense to sales people, I know there are too many products for
    them to know everything....but then isn't that what RSS was supposed
    to be for?