Conference bulova::decw_jan-89_to_nov-90

	I guess these guys do not have such a product to offer,
	but they seem worried about it.

							Bruce

    The discussion in UNIXWORLD was centered on X-Terminals.  In fact
    the cost-effectiveness of the X-terminal approach is apparently
    one of our big concerns in deciding whether to build such a product.
    
    If a VAX 6310 can only support (say) 20 terminals, providing 0.25
    VUPS per X-terminal, are the users really going to be better off
    than if they had VAXstation 3100s?  
    
    

    
>    If a VAX 6310 can only support (say) 20 terminals, providing 0.25
>    VUPS per X-terminal, are the users really going to be better off
>    than if they had VAXstation 3100s?  

But that isn't the likely tradeoff.  What is more reasonable is the option of
a color VT340 connected to the 6310 versus a b/w X-terminal connected to the
same 6310.  The VT340 supports graphics and multiple sessions and color and
lower overhead on the host.  An X-terminal would support multiple sessions and
graphics, but might not have color and would probably load the host more.
And the X-terminal would probably cost more, maybe 50-100% more than the VT340.
(My guess based on the amount of memory I'd expect, say 4 meg to make up for
no virtual memory).

Now, which would you rather have, good VT340 interactive performance or somewhat
poorer response with DECwindows?

Not many people are going to be given the option of `would you like a PVAX or
would really rather have a VT340?'

There are severl vendors currently offering X terminals, and it goes without
saying that Digital is also intensely looking at the area. While I won't comment 
on any effort currently under way in DSG, I will relate what the competition
has announced. If you want information about what is happening in Digital, then
contact Vic Belemere at VIDEO::BELEMERE who is the <unannounced product name>
product manager.

The Visual 640 X terminal is currently shipping and comes standard with three 
button mouse, 2MB of memory and a MC68030 processor. Ethernet attachment and 
TCP/IP transport integral. The terminal retails for $1295 (competative with the 
VT330) and has a 15 inch screen of approx 100dpi. The terminal has gotten good
reviews to date, although some complain that the server is not as highly 
optimized as the DECwindows native server. It does seem to function with 
DECwindows applications and if the server optimizations are forthcoming, could
be a real competitor to our existing workstation platforms.

Human Designed Systems (HDS), a traditional aftermarket vendor of VTxxx clone
terminals has announced an X terminal under the trade name of ViewStations.
Citing that it is "... more of a stripped-down workstation [than a terminal]",
the processor is available with both serial asynch and Ethernet communications.
Two resolutions of display monitors are available. Low resolution is 800 by 480
while the high resolution is 1280 by 1024 pixel on a 14 or 19 inch monitor 
respectively. The processor is an Intel 80186, with a TMS 34010 graphics
co-processor. Addin boards will provide TCP/IP or DECnet over Ethernet. Beta
test is beginning ths month and the quoted price is "under $2000."

GraphOn, another aftermarket terminal vendor, announced a $1395, X compatible 
terminal, which communicates via RS232 to an X server running on the host. The
indications given is that performance is not to acceptable levels since the 
bit-blit speed is limited by the RS232 line speeds.

The claim that X terminals will not be compettive with X workstations is 
hollow. There concrete products on (or coming on) to the market which are 
compettive with terminal prices. As memory prices continue to drop and the
CPU speeds continue to increase, the blur of what's a workstation and what's
a terminal is expected to become greater. 

As a result, I expect that customers will quicly be asking not "Do I want the
performance of a VT340, or a PVAX?", but rather, "Why do I need to buy a PVAX
when I can get an X-terminal (with integral server) and use the resources of 
my cluster?" I must admit that the latter solution is very attractive to the 
large MIS dept. director who doesn't like PCs/Workstations because they 
decentralize his operations, cause upgrade and reliability headaches and 
don't like the cost and manageent complexity of the LAVC.

James

	Network Computing Displays (NCD) is also offering an X terminal.

	I believe we are seeing a major departure from the trend of
	Terminal->PC desktops which started in 1982/3. X terminals offer
	the potential of shared resources being a cost-effective model
	in office computer systems.

	Obviously this is a strategic market for Digital, and especially VMS
	which can scale up nicely using multiprocessor/VAXclusters as the 
	number of temrinal is increased.

	For those who assert "why not use a P-whatever", elsewhere in this
	conference there seemed to be consensus that a 6 meg VS2000 should
	be operated as an "X" terminal. Which is easier to install, power
	on, secure, buy, listen to, upgrade, repair, fit on your desk ... 

	... a terminal or a 6-meg workstation ?
								Bruce

    re: .3 et al
    
    I think you may be missing the point.  The trade-off is not:
    
    VAX 6210 and 20 X-Terminals
    
    v.s.
    
     VAX 6210 and N VT340's
    
    It is:
    
    VAX 6310 and 20 X-terminals w/ 0.25 client VUPS per user
    
    v.s.
    
    VAXserver 3600 and 20 VS3100 w/ ?2 client VUPS per user (assume 1
    VUP for the X server)
    
    The cost of the large VAX systems MAY be avoided if the processing
    is done on the Desktop system.
    
    An informal report on some in house testing indicated that the cost
    of a usable VISUAL terminal was higher that the ~1300 quoted since
    4 Mb appeared to be the minimum useful configuration.  I think the
    list price was more like 1800-1900.
    
    The VAX 6310 may not be the most obvious example to work with, given
    the similarities in capacity between the VAX 6310 and the uVAX 3600
    as hosts for the X-terminals.  It might be a clearer problem if
    larger numbers of X-terminals were considered and a VAX 6330 were
    posited as a host.  However, the 20 X-terminals/VAX 6310 is not
    a number that results from rigorous testing either.  What if a VAX
    6310 can only support 5 X-terminals?  Or 3?
        
    At least in our pricing 'architecture', there are considerable cost
    advantages in avoiding the purchase of a multiuser VAX.  This weighs
    in favor of a VAXserver/Workstation approach.
    
    The point is that it is not an idle question to ask if an X-terminal
    environment will be truely cost effective.
    
    It seems clear that existing computing environments can find a place
    for SOME X-terminals.  This file is full of examples were VS 2000's
    are being used as such, as a previous reply indicated.
    
    The question is whether it would make sense to design a system where
    X-terminals would be the dominant desktop device.
    
    -fjp

    RE: .-1 
    
    The choices are not as simple  as  you  describe.  It isn't between one
    big system and a few low cost terminals or a small(er) system and a few
    high(er) cost workstations, rather the choice is where and how does the
    customer place computing resources to make the most sense.    For  some
    customers,  the  configuration you describe fits perfectly.  For others
    (Office Automation or Tranaction Processing) it is woefully overpriced.
    We must provide for this later class of customers.
    
    The OLTP customer  typically needs a large number of terminals, usually
    in  small  (1) to medium (48) size  clusters in  a  widely  distributed
    geographic  area.    Cost of ownership, simplicity of configuration and
    ease of  system  management  are  primary  concerns.    Performance  is
    absolutely demanded and  the  customer is usually willing to trade user
    interface  concerns  for  higher  transaction  throughput.    Also  the
    customer is very sensitive to the cost-per-seat.   
    
    One way  that  I  believe  we  can  meet  this customer's demands is to
    provide very low cost DECwindows display stations.  The opportunity  is
    to  use  an  X  terminal as  a  dollar-for-dollar  replacement  to  the
    character-cell  terminal.   These low cost display  stations  would  be
    driven from a front-end transaction  initiator  like  a  MicroVAX 3x00.
    The role of the MicroVAX is to provide for all the front-end activities
    (e.g.   the "forms" processing, user interface  control  etc.)  and  to
    initiate   transaction  requests  to  the  back-end  database  oriented
    machines.  The back-end database/compute engines (for instance a  63x0)
    would  receive and process the transaction requests and would be  tuned
    specificly  for that purpose.  It is especially important to note  that
    the backend machine may not be geographicly close to the front-end 3x00
    system (not connected via Ethernet).
    
    I believe that  a  configuration  using  DECwindows  terminals would be
    simpler in design and  easier  to maintain.  Also for most departments,
    it would offer the same level of performance at a lower total cost than
    a solution that utilized only VAXstation 3100 systems.   
    
    This  configuration  also  scales  well.    On the very low end,  in  a
    customer  office  with  the requirement for only one terminal, a single
    VS3100 Model  30 would be sufficient.  For offices that require between
    2 and 4  terminals  a  VS3100  Model  30/40  with  attached  DECwindows
    terminals would provide acceptable  levels of performance.  For offices
    requiring between 5 and 8,  an  additional  VS3100 or MicroVAX could be
    added to form a LAVC along  with  additional  DW  terminals.    For the
    customer that requires between 9 and 24  terminals,  the solution would
    be one or more MicroVAX 3x00s in a  LAVC  with  attached  DW terminals.
    For  larger  departments,  we  can keep incrementally adding processing
    capability  utilizing  our  basic  building blocks.  The most important
    aspect  is    that  the  growth  is  modular,  protects  the  customers
    investement and provides a stable growth path.
    
    While there are some configurations which  don't  fit  this model, most
    notable  the work group CAD/CAM applications, the OLTP applications are
    strategic to Digital.  We have to provide a good solution for customers
    for which this  model applies.  The incremental cost-per-seat has to be
    competative with the cost of current day terminals.
    
    This discussion isn't  counter  to  our  departmental  level  computing
    strategy simply because I'm advocating a front-end  systems that behave
    more like terminals than standalone computers, nor is it hostile to the 
    workstation strategies that we currently have.  In fact, I believe that
    I'm  expressing  exactly  how  we see our products being used  in  this
    environment.  In a truly enterprise-wide OA and TP application, we must
    provide a range of  solutions.    We  need small standalone systems, we
    need  the  workgroups  which  you  describe,  and  we  need  the  large
    centralized systems.  A number of different computing resources must be
    available  to solve the application problem. 
    
    The  "information  center"  or "transaction processing environment" for
    the early  1990s  will  require  proper application of ALL our existing
    products.  That's  what  ACMS,  DECintact,  DECforms  and  the other TP
    related efforts are bringing  to  the fore - high levels of integration
    with some hardware elements being  used in very specific and restricted
    ways.  No longer is is acceptable to simply "set host" or "connect from
    the lat" and login.  To meet  the performance requirements, we must use
    the  available  cycles in specialized ways.  The  TP  network  must  be
    somewhat  hierarchical.  The display stations need to be  dedicated  to
    display.   The  transaction  initiators  should  be  specialized toward
    managing the user interface.  The back-end processors should be free of
    time consuming "keystroke level"  processing.    In  this  environment,
    having  between  0.25 and 1.0  VUPS  for  the  display  station  sounds
    reasonable.    It's  also  reasonable  to  expect    that  a  dedicated
    transaction  front-end  (3x00  class)  can support a sufficiently large
    number of these stations. 

    One  last thought.  While the  stand-alone  workstation  market  offers
    large potential business, we must also recognize that not all Digital's
    customers have problems which workstations (alone) can solve.  Offering
    a DECwindows terminal  only strengthens our ability to provide flexible
    solutions.    I believe  there  is  sufficient  justification  for  the
    product, but providing it doesn't  free  us  from  having  to  ask  the
    question "Is this the correct product to this customer's application?".

    James
    

    James,
    
    Do you have any contact info for the HDS 1280x1024 model?
    
    fjp

    The only  information  that  I have on HDS is the statements which have
    been made in the publicly available trade rags. Sorry not to be of more
    help.
    
    James
    

    As far as many commercial customers are concerned, they never want to
    have to install anything on thier display device. Plug it in and Go
    is a desired feature. If X window terminals can become standardized
    (like the VT100 was) by dozen's of companies, then X window terminals
    will become wide-spread.

    MIS directors often don't like the distribution of random systems
    connected to this organization, especially if they have to also manage
    them. Software OEM's who are trying to cover a diverse market (IBM, DEC,
    HP, WANG, PRIME etc) with a relatively common product (standards are
    beginning to allow for this) will lean towards a known commodity rather
    than a customisable work station.

    I firmly believe that a quality X window terminal will be the choice as
    the display device on an average computer system in the 1990's, and not
    a workstation running DECwindows. This is not to say that there is no
    need for workstations, but there is a place for both and both may be
    required for any given set of customers.

    If price is an issue, then no-one in thier right minds are going to
    choose a $10,000 workstation over a $2,000 terminal if they both are
    only capable of being server (Just for example, all of the the 4MB
    VS2000's with disks/etc.), and both run about the same speed.

    A workstation should be capable of stand-alone processing, and I
    suspect that somewhere in the future this distinction will be made.
    One day, people will call your workstation a terminal if all it can
    do effectively is be an X server. Obviously some companies have
    recognised this and decided to make a dedicated X terminal to go
    for that market. Right now they can compare performance of a system
    that costs mucho $$$ but performs no better than thier X terminal.

    It will take a big bite out of any company that can't provide the
    functionality in both X Terminals and X Workstations.

    I talk to Software OEM's and end users contemplating migration to VMS
    or Ultrix (I work in the Center for Migration Services - We are
    chartered to do this), and I do hear thier concerns on a daily basis.
    X terminals are getting asked about (Usually with questions about
    TCP/IP), Workstations are not (This is mostly a commercial customer
    base).

							Jens

>                     Right now they can compare performance of a system
>    that costs mucho $$$ but performs no better than thier X terminal.

NOT TRUE.  The X terminals run out of resources very easily.  This is because
most of them are low memory (1-6 meg) and no virtual memory (haven't implemented
NFS paging/swap).  Until these problems are solved (and solved well) the X
terminal is not really competition even for a VS2000 w/ 4megs.  They will
(I hope) be solved soon.  At which point X terminals will indeed outstrip
the low end workstations (which will have been phased out by then  8^{).

Dick _whose_30_big_clients_would_trash_a_Visual_X_Terminal_

    I'm assuming that most problems will be ironed out with X terminals
    in a year or so (I remeber when ASR33's were the rage & then LA36's
    re-defined the hardcopy terminal). The issue is that many users of
    X terminals will probably not be doing anything fancy (by virtue of
    the MIS directors maintaining control over the applications), so, in
    that sense, can work around it.

    Some of the software that we have been looking at (as recently as
    today) has the organization writing code that does not exceed the
    limitations of it's current hardware. While those of us used to VMS
    tend not to concern ourselves too much about hardware limtations, and
    try to write what is the best long term solution, we do not necessarily
    share the philosophies of the general computer user base.

    I've seen a 4mb VS2000 running DECwindows, and it's nothing to be
    impressed about. I suspect that the current X window terminals are
    similar in response time or capabilities. A year from now things may be
    quite different. I suspect that DEC will be on the fore-front of
    solving some of these problems. Things were so much simpler in 1979.

    Jens_who_is_working_with_customers_who_are_accustomed_to_less_than_or_
    equal_to_VT100_terminal_capabilities_and_whose_software_investment_is_
    substantial_enough_that_they_will_maintain_it_for_a_long_time_to_come_
    but_want_to_allow_for_future_growth_posibilities_by_migrating_to_a_VAX

    Dick,
    
    Arguing that  memory  is  a  limitation won't last long.  There are two
    solutions that come quickly to the X terminal builder.  The first is to
    just add more memory.   Since he can dispense with all the logic of the
    disk controller, tape controller and etc., there is much more space for
    memory.  Having 16 to 32 MB in an X term is not unrealistic.  Secondly,
    with 4MB DRAMS becoming realistic for use in systems, the complexity to
    get this ammount of memory is  greatly  reduced.  Also, both the US and
    Japan are on the edge of the  16MB  DRAM  breakthrough.  At that point,
    the minimum amount of memory that you use  for  a system building block
    is adequate for most current applications. 
    
    I understand your objection, but the rate of change  of  technology  is
    still too great.  We can still say "The next  generation will be faster
    smaller, and bigger." and realisticly expect that it is not a lie.
    
    James
     

With the cost of DRAMS, this terminal with 16 mb of memory will not be cheap.
Another way of doing it is to run a virtual memory system (VMS) in 4 megs
with a server. (Of course a diskless config would need a paging disk on
a server somewhere).

Jeff

	Lets remember the difference between instructions and data.

	An X terminal could easily write its "data" out to a nearby
	disk (ala nfs) which must represent a lot of the memory
	required (100KB/terminal emulator for instance).

	Data is position independent and therefore does not have to
	be "relocated" by memory management mirrors.

	"Virtual memory" runs in real memory after all, and pretending
	you have it when you don't doesn't help, it hurts.

							Bruce

    
    RE .14 ( ...the price of DRAMS)
    
    If the Smithian theory for capitalistic economies is still valid,
    then economies and diseconomies of scale will drive the supply
    and demand curves to their optimum thresholds.
    Hopefully, the useful economies of large scale production caused
    by technological advances could really push down prices.
    
    							Kris...

Memory prices may indeed come down.  How soon?  Soon enough to skip the step
of doing an X terminal with remote resource capabilities?  I doubt it.

The approach of implementing the allocation of server resources via a non-VM
remote server is interesting.  Is it easier than using some known NFS based
VM approach?  I don't know.

This technology is interesting.  It is indeed the wave of the future.  BUT,
if X terminals are implemented badly in the early versions they may scare
customers away before we get it right.  Visual Technology seems to be doing
just that.  DBMSs did that to databases in the CAD world 10-15 years ago and
we are just overcoming that prejudice today.

Let's do it!  But let's do it right and learn from the guys who beat us into
this market.

Dick

    There are lots of database-type applications which are easier to write
    and manage if all the users are running on just one computer. Yet
    everyone is demanding nice mousey point-and-click user interfaces.
    
    X terminals offer one solution to this. There are others: workstations
    acting as terminals; splitting the application into a front end and a
    back end that communicate via a custom protocol...
    
    True, cycles are usually cheaper in a workstation (or PC or Mac) than
    in a server. However, the programming cost of making the application
    distributed can outweigh the savings from buying cheaper cycles.