Conference wrksys::alphastation

    Re .0, what's wrong with AlphaBIOS?
    
    Has anyone considered getting OpenVMS to move over to the AlphaBIOS for
    future releases?
    
    --svb

    re .1 - what's wrong with AlphaBIOS? ...
    
    Hmmph, snort, snigger, rotfl.
    
    Sorry, I got sort of carried away there.
    
    -- Kenny House

    Re .2, alright Kenny... now i know where you stand 8^).  SRM is great
    for the techno-weenies like us but it really is hopeless for the rest
    (even for some of us who tend to forget the exact incantations like
    "cat mumble -mumble > mumble ..." until we have to deal with tasks like
    upgrading the firmware on an Alpha 8^).
    
    --svb

Isn't there already a whole note string in here already with a 
discussion/rant about this topic?   I think it's under one of the notes about
'half flash' systems.

The SRM console does a bunch of stuff that the OS'es that use it need.
If I recall that discussion right, combining the two consoles (i.e. putting
the Alphabios gui on top of the more sophisticated srm guts) was viewed
as technically doable but politically impossible.   

    
    Puleeease.  Enough.  I can probably write a volume on why the SRM
    console could be used by ALL of the operating systems, with NO loss
    of functionality by AlphaBIOS users, even down to the precious bit
    mapped pictures.  And why at the same time, only MASSIVE investments on
    the part of both OpenVMS, Digital UNIX, *AND* the DECwest group (for
    AlphaBIOS) would be needed to make AlphaBIOS suitable for anything
    except NT.
    
    This is *not* a technical discussion.  There *is* only *one* technical
    solution that is feasible, cost limited, and provides any long-term
    cost savings.   Any discussion of AlphaBIOS/SRM is a political/turf one.
    
    
    _Fred (former member of the "last" console taskforce to fail in the
    effort to create a single console, and author of the opinion
    which proposed to use the SRM console and abandon the AlphaBIOS/ARC
    consoles, co-signed by the Unix, VMS, and Firmware representatives.)
    
    

    I was not part of the unified console discussions nor familiar with all
    the going-ons in that area.  Strictly as an end user, i cringe every
    time i have to deal with SRM.
    
    Why have we been so fond of making things so cryptic for the users?
    
    If it is not a technical (nor usability, i assume) discussion, what
    prevented Unix, VMS and Firmware folks from making SRM more usable than
    what it is today?
    
    Or, is SRM perfectly usable as it is today?
    
    --svb

AlphaBIOS has a poor GUI.
The SRM UI is even worse.

The whole thing is a big embarassment.

--RS

    Not to defend the SRM UI, but...
    
    The design grew out of the move towards a more Unix-like interface,
    from the pre-existing interface on the VAXes.  But it's not uniform
    across platforms, and it's not pretty (neither are most Unix shells).
    What it is, is functional.  In fact,  the less a user needs to interact
    with *any* console, the better.  If you'd asked me to design it, I'm
    sure it would be different, and perhaps not better.
    
    All consoles need a serial interface, mostly for automated testing in
    both manufacturing, and for service.  A more user-friendly, and more
    importantly to my mind, consistant, interface is also a reasonable
    request for the end-user.  My opinion about why this was never done for
    the SRM console is simple:  I cannot name a sale that was lost because
    the console was ugly, nor a sale that was made because it was pretty.
    
    AlphaBIOS is a bit over-the-top on the UI frontier.  Almost meta-MS
    Windows, but not quite.  But, if that is the GUI that the company wants
    for ALL their systems (regardless of O/S) it can be added to the SRM
    console.  In fact, it was my opinion that provided access to the
    AlphaBIOS sources, that the entire GUI and ARC API (including Alpha
    extensions, and configuration tree) could be added to the SRM in no
    more than six months, and require zero lines of code to be changed by
    any of the operating systems.
    
    That it would allow the collapse of the two firmware groups into a
    single group, and a reduction in the absolute number of resources
    needed for console work per-platform.  More over, it was my opinion
    that the SRM console needed a kernel group of maintainers to function
    as gatekeepers and architects to prevent the incompatable offshoots
    that occasionally show up.
    
    In any case, there is a document that spells out the requirements of a
    common console, and which then goes on to recommend a solution that is
    at odds with the recommendations (i.e. use AlphaBIOS), and the counter
    proposal that the SRM be used as the base, with the addition of the
    AlphaBIOS GUI, and ARC API (which already exists partially for the
    Turbolaser (enough to run the ECU, but not enough to boot NT - because
    the NT group would not provide the console developers kit to our own
    console group).
    
    There was a idea that the workstation group was looking at, to have the
    AlphaBIOS boot the SRM from flash.  It's about the worst idea in terms
    of solving *anything* I had ever heard.  It seems to have died a quiet
    death.
    
    _Fred (not that I'm biased, but I wasted 6 months on this, and got
    reamed by a corporate consulting engineer about the failure).
    

    As a end-user (meaning not debugging) give me AlphaBios to build NT any
    day of the week compared to ARC/SRM nonsense!!  All systems should be so
    easy!!
    
    Have you have tried building NT from scratch on a Intel box.  Talk about a
    pain, can you say insert floppy.
    
    			Bart

    But do you *care* if the AlphaBIOS interface is layered on top of the
    old ARC console?  Or if it is on top of the SRM console?  I'll wager
    you don't care, and could not tell the difference.
    
    The ARC console, which the AlphaBIOS GUI is built on (offshoot of,
    whatever), has been targeted only at the specific configurations, and
    the specific limitations of NT.  Boot a UNIX system from a CI disk.
    Boot OpenVMS from a InfoServer on the network.  Boot a SCSI cluster
    using a common system disk.
    
    The amount of work to bring ARC up to the level of functionality in the
    SRM is huge - either that, or VMS and UNIX customers must lose
    functionality.  Regardless of which, both operating systems would
    require a huge amount of changes to accomodate the ARC console.  In
    some cases it is moving console functionality into the O/S, in some
    cases it is redisigning the console-o/s interface.  Some things can
    only be fixed by a change to the console (like it's use of Superpage
    mode, and where it gets loaded).
    
    I will argue that all common operations that a console must perform
    for a user *should* be simple.  I will also argue that as little as
    possible should be done in the console.  It's primary purpose is to
    load an operating system, and support the knobs and bells needed to
    do this operation.  There is nothing wrong with O/S specific tailoring
    in the UI of the console, where it makes sense.  And by all means,
    nobody ever suggested that anything offered to NT users by AlphaBIOS
    should not continue to be offered. 
    
    To install OpenVMS, the user types:
    
    		BOOT <cd device name>
    
    And that is the *last* that you will see of the SRM UI, until you
    reboot.  And while I can think of a number of niftier things that the
    console could have done to make it easier, or user interfaces to make
    it pretty - it is simple.  Same command to boot the system.  Same
    command to boot the firmware installation CD.
    
    In any case, we've been there.  And I believe that the final answer is
    that both the SRM and AlphaBIOS will continue to ship.  Heck, it's one
    of the best ways we have to exclude VMS and Digital UNIX from certain
    boxes is to not ship the SRM for it.
    

    Re .10, you took the discussion to a totally different tangent.
    
    The question in .0 and the thread subject is "NT on SRM?".  Your detail
    analysis of a proposed project, which had not gone forward for whatever
    the reasons, was enlightening but perhaps irrelevant.
    
    I contend that while SRM has all of its glorious flexibility and
    functionalities, it is an ill fit (too bloated) for the Windows NT
    environment and (too cryptic) for the user interaction.
    
    --svb

    Huh?  SRM too cryptic?  As a VMS/UNIX user who has moved (quite
    often being drug by my heels) towards NT, I've seen my share of cryptic 
    messages from the AlphaBIOS and NT. 
    
    SRM too bloated?  As an SRM user for many years, I personally have only
    had to use 3 (maybe 4) different SRM commands (BOOT, SHOW xxx, SET xxx).  
    As Fred pointed out, the vast majority of users of either console tend to 
    stick to a small handful of commands.  Just because the SRM has more 
    commands than I know how to use, I don't want to get rid of it...
    
    				-John

   I've found ARC rather limited, and an obvious direct outgrowth of the
   classic BIOS found on a PC system.  In other words, limited, inflexible,
   and entirely lacking in capabilities I expect from a console.  Somewhat
   rephrased, this is a great place to enhance and add value to Alpha.

   As for complexity and learning curve, the vast majority of times, I need
   and use one or two SETENV commands, one or two SHOW commands, or one of
   the various BOOT commands.

   I dislike having two seperate environments, and forcing users to swap
   between them for various operations is blatently poor design.

   The console duplication also adds to the overall support costs.

   And if NT ever expects to head up-market, the standard PC BIOS and ARC
   console will have to be extended regardless.

    Hmmm.  Perhaps.  OK, here are some Q/A that I think cover the general
    topic.
    
    	- Has the SRM been considered?
    
    	  Yes.  It is technically feasible.  It may even be
    	  desireable.  However, it is not the strategic direction
    	  of the NT group in the area of console firmware.
    
    	- What are the technical details?
    
    	  The SRM console must have the Alpha Extensions for
    	  the ARC console implemented, and be able to generate a valid
    	  configuration tree.  That is, the SRM console group must
    	  have the console implementors kit that is available to
    	  3rd parties, and Hudson (but not to them).
    
    	  In addition, the AlphaBIOS GUI could optionally be implemented
    	  to provide a user-friendly console interface.
    
    	- What O/S changes are needed if the SRM is used?
    
    	  None.  The SRM console is inherently whatever we need it to be.
    	  To boot all 4 Alpha O/S's, the console would be adapted to
    	  provide a binary compatable API.
    
    	- Is the SRM bloated?
    
    	  Well, yes and no.  Most of the bloat is due to the many device
    	  drivers provided by the SRM.  Adding the functionality to the
    	  SRM to boot NT, and even adding the AlphaBIOS interface will
    	  create a smaller footprint than shipping both consoles in flash.
    
    	  At some point, a cusomizable SRM console will probably be needed
    	  to deal with the ever expanded list of devices supported.  This
    	  would allow the firmware installation to tailor itself to the
    	  specific configuration.
    
    	- The SRM console has a horrible UI.  Can't it be fixed?
    
    	  The SRM provides a complex UI to perform complex operations.
    	  It must be noted that the SRM is used to do the initial debug
    	  of platforms, and provides extensive debug capabilities.  In
    	  addition, the evolution of large systems requires capabilities
    	  not available on simpler consoles - such as multi-threaded
    	  operation to allow parrallel poser up self tests, and directed
    	  testing.
    
    	  The SRM could benefit however, from a simple UI or GUI such as
    	  AlphaBIOS for "typical" end-user interaction.  With the SRM
    	  console UI available for diagnostic, or advanced setup.
    
    	- Why not start with AlphaBIOS instead of the SRM?
    
    	  Well, because AlphaBIOS/ARC does not contain the capabilities
    	  that are required for many aspects of OpenVMS and Digital UNIX.
    	  Some things include network booting, support for DSSI/CI devices,
    	  support of halt/continue, callbacks for writing crash dumps, and
    	  more.  In addition, the console requires a SuperPage mode that
    	  is incompatable with life as we know it.
    
    	  In short, it is possible.  However, the cost is prohibitive to
    	  Digital UNIX and OpenVMS to re-engineer the O/S to work with
    	  the console.  And if the console is re-engineered to work with
    	  the operating systems - you will end up with an approximation
    	  of AlphaBIOS layered on the SRM as the final end result.
    
    	- How about OpenBOOT instead?
    
    	  OK.  How about it.  It's a cool idea, 5-6 years too late.  A lot
    	  of work, a lot of risk.
    
    	- Is this all just a load of SRM-tree-hugging-crap?
    
    	  Trust me.  At least 4 taskforces failed to deliver a common
    	  console.  All of them failed because the answer was unacceptable
    	  to the NT group.  Either the console required changes that the
    	  NT group was not willing to make, or were based on the SRM.
    	  Or on the flip side, all of them failed because OpenVMS and
    	  Digital UNIX could not afford to roto-till the O/S and lose
    	  functionality along the way by trying to use a unchanged ARC.
    
    	  I worked on this with some of the most talented people in DEC,
    	  and in the end, the result was that yes, OpenVMS can be changed.
    	  Yes, Digital UNIX can be changed.  But no, nobody had the kind of
    	  manpower needed to re-engineer the O/S's, and the guarantee
    	  that the NT console would make the required changes, or be
    	  responsive to non-NT needs.
    
    	  And I went into the thing saying "Let's just do it.  And move to
    	  the ARC console."
    
    	- Is there a good business case for merging the consoles?
    
    	  Well, I'd like to say yes.  And there are at least a few high
    	  level folks who say yes.  However, I don't really buy it.  If
    	  there was a compelling business need, it would have happened.
    
    	  The overall savings, and customer satisfaction across the
    	  entire corporation, seems to be lower than the increased costs
    	  and customer disatisfaction that would occur in the individual
    	  O/S markets.
    
    	  Nobody buys a system, or does not buy a system, because of the
    	  console interface.
    
    	  Were we back at the beginning of Alpha V1.0 development, we would
    	  design a single console that everyone would sign on to.  But my
    	  wayback machine is broken.  The SRM was designed to be multi-OS.
    	  The decision to create a seperate console was wrong.  The SRM
    	  should have been redefined to meet the needs of all of the O/S's
    	  - including NT.
    
    	  At this point, it is unlikely that there is any way that there
    	  will be a merge of the consoles.  It is cheaper not to.  Only a
    	  unilateral move by NT to get out of the console business would
    	  change this, in my opinion.
    
    	  OpenVMS will *never* move to ALphaBIOS.  My offhand guess is that
    	  it will require at least 7-10 engineers, and 9+ months to design
    	  and implement.  And not chumps off the street.
    

    I'd like to swim upstream here by picking a fight with .7
    
    Sometimes it's the little things that make a big difference to
    customers.  Have you tried inserting a console CD lately?
    
    Guess what.  You boot the CD.  It says something to the general effect
    of "I think this is an alphastation 500.  If you want to update it with
    the file magicname.exe press return."
    
    Press return.  Answer the "do you really wanna do this" query with the
    prescribed answer.
    
    It updates both ARC and SRM.  You're done.
    
    To my mind, the console update process just got A LOT less
    embarrassing.   No more looking for a working system with a working CD
    drive (that knows how to read the format of the CD) that has a working
    printer just to find the one magical filename.
    
    (Yes I know this isn't the major topic of this notestream, but I just
    had to respond to .7's claim that the whole thing is a big embarassment.  
    One item, at least, is less embarrassing than it used to be.)
    
    	/john

    Re .13 & .14, your discourses continue to be enlightening but still are
    not to the point (.0) and counterpoint (.1) that were originally
    brought up.
    
    They are in my mind is as follows:  What are those needs of NT and its
    users' expectation of human-computer interaction that have not been met
    by AlphaBIOS and can be exceeded by SRM in the latter's current form?
    
    My contention is:  None that i'm aware of.
    
    --svb

    Re .13 & .14,
    
    So what are those needs of NT and its users' expectation of
    human-computer interaction that have not been met by AlphaBIOS and can
    be exceeded by SRM in its current form?
    
    --svb

    
    I have not chosen to attack the AlphaBIOS user interface.  In fact, I
    indicated that while I may believe that it is overkill, I'd be happy to
    see it as the default interface if it served to unite the consoles.
    
    No, the areas where AlphaBIOS falls short is that decisions were made
    that are NT-centric to the point of making it unsuitable for anything
    except NT or something like it.  Now that's OK for AlphaBIOS - after
    all it is NT-specific.  It does not make sense for a common console.
    
    There are a host of small things to large things that all add up to a
    significant amount of work that would be needed to both OpenVMS and
    UNIX to be able to use AlphaBIOS.  And without additional major changes
    in AlphaBIOS - even with the O/S changes, there would be functional
    loss for UNIX and VMS users.  For instance, VMS users can configure
    multiple systems on a single SCSI bus and use a common system (boot)
    disk.  Well, this requires specific support in the SCSI boot driver. 
    VMS and UNIX users expect to be able to boot DSSI/CI disks.  They
    expect network booting.  VMS users need to be able to press halt, and
    force a software interrupt to allow cluster quorum adjustment.  VMS and
    UNIX depend on the console for boot drivers for system crashdumps. 
    UNIX cannot live with where AlphaBIOS loads.  VMS and UNIX cannot
    handle the Superpage mode used by the console. 
    
    It all adds up to a lot of work, and the potential for regression in
    end user functionality.
    
    And I haven't even gotten to the technical cruft on large system
    testing, and initial system debug.
    
    
    
    
    

:    So what are those needs of NT and its users' expectation of
:    human-computer interaction that have not been met by AlphaBIOS and can
:    be exceeded by SRM in its current form?


From:	US2RMC::"[email protected]" "Samuel Key" 28-FEB-1997 18:58:59.75
To:	[email protected]
CC:	[email protected], xdelta::hoffman
Subj:	DEC AlphaStation 200 4/233:DEC VRT19-DA/HA Mating 


I have the following system (new, at home):

  DEC AlphaStation 200 4/233 and Windows NT 4.0
  This system currently has a DEC PCI-based ZLXp-E1 graphics 
  board. The default video signal is R/G/B/V-sync/H-sync.

I have the following monitors (both in very good condition):

  DEC VRT19-DA (1280x1024 @ 66Hz)        R/G/B/Sync-on-green
  DEC VRT19-HA (1280x1024 @ 66Hz & 72Hz) R/G/B/Sync-on-green 

The DEC AS200 4/233 has two sets of console firmware:

  1. ARC for the MS Windows NT O/S
  2. SRM for the DEC Unix & DEC OpenVMS O/S's

The SRM firmware provides a serial console with an NVR environment
variable "tga_sync_green" which when set to "1" (or 2 or 3) causes
the ZLXp-E1 board to output R/G/B/Sync-on-green. All is well between
the ZLXp-E1 graphics board and my VRT19-DA/HA monitors. (The ZLXp-E1
has a set of "piano" switches which provide for 15 separate fixed
resolution/frequency output pairs, two of which match the VRT19's)

The ARC firmware provides a traditional rinky-dink PC "graphical"
interface for the console (so as not to frighten the PC user with
too many options). There is no hint of an environment variable 
which the ARC firmware can store in the NVR and on power-on put 
to the ZLXp-E1 graphics board for the purpose of mixing the sync 
signals with the Green signal.  

It is clear from my experience with the SRM firmware that the 
ZLXp-E1 is perfectly capable of interfacing to the VRT19-DA/HA
monitors. For whatever reason, DEC/MS have decided not to accom-
modate their older VRT19's for those individuals using the 
Windows NT 4.0 O/S.


Hence, my e-mail to you. Please tell me what I need to know about
your PHOTON TORPEDO 564-72 DELUXE graphics board and associated
"WinNT 4.0 driver for RISC" in order that I can choose between 
it and a new Sony 300sfT monitor.

Thank you,

Samuel W. Key
[email protected]


 

:    So what are those needs of NT and its users' expectation of
:    human-computer interaction that have not been met by AlphaBIOS and can
:    be exceeded by SRM in its current form?
    
   Ease of swapping between NT and UNIX, NT and OpenVMS, etc.

    Re .18, two things...
    
    I passed the note on to Kathleen Langone, TGA NT PL, who'll contact the
    customer about the TGA NT driver no longer supporting 66 Hz monitors.
    
    Allowing the behavior of the OS and its kernel components to be tweaked
    prior to boot, using the console firmware, is one way of doing it
    (albeit potentially unsecured backdoor).
    
    Apparently, the TGA OpenVMS driver retains the support of 66 Hz monitor
    as an option and requires the user to enable it via a console
    environment variable.  Had the TGA NT driver continued to support 66 Hz
    monitor, as an option, a similar "tweaking" method would likely have
    been permitted via the NT registry editor (unsupported) or the display
    control panel (supported).
    
    Because OpenVMS chooses to do things differently and relies on SRM for
    this tweaking mechanism (permitted via the set env), your argument is
    flawed when it implies therefore AlphaBIOS must have the same
    mechanism.
    
    --svb

    Re .19, hmmm... is that good for NT?
    
    --svb

    .21	  Ah, there lies the rub.
    
    			"hmmm... is that good for NT?"
    
    The question should be "hmmm... is that good for DIGITAL?".  A common
    problem is that projects and products tend to focus only on what is the
    right thing for them, to the exclusion of all else.  In fact, a lot of
    the way we goal and reward people drives people to act this way.
    
    At the 50,000 ft level, the answer is yes, it is good for Digital. 
    However, once you dive down a few levels, the answer is not so clear.
    
    The basic reason that we have never been able to come to closure on the
    console issue is because none of the groups have an compelling reason
    why it is good for their specific product, as opposed to the rest of
    the company.  In the OpenVMS case (which I can speak for), we would
    love to have a common console (there are good reasons, and important
    long term ones for OpenVMS), but the cost and risks are too high to
    port OpenVMS to AlphaBIOS.  This also was the case for Unix (although
    they would prefer OpenBOOT to AlphaBIOS).  And in NT's case, they have
    no reason at-all to want a common console if it means a compromise in
    their console strategy (not that I truly understand why console should
    rise to the level of needing a O/S strategy, after all, it's primary
    purpose is to boot the O/S and get out of the way of the good stuff).
    
    

>    			"hmmm... is that good for NT?"
>    
>    The question should be "hmmm... is that good for DIGITAL?".  A common
    
    Or another way of saying it is: "hmmm... is that good for the
    customer?"
    
    As a customer of DIGITAL (albeit a captive one), I must say that it
    would be good for me.  I daresay that externals customers that must
    switch OSes on a regular basis would say so as well.
    
    I'm rather dismayed that we still have people or groups that put their
    interests in front of the customers.

    Life is funny, is it not?  I can remember those days when similar
    sentiments (in .22 about being good for this or that) were expressed
    toward VMS, not by VMS.  But let's stick to the point and save the
    laments.
    
    The point that was put forth (.0) was making SRM the console for NT and
    the counterpoint (.1) was why doing that when AlphaBIOS is doing things
    pretty well for NT already - are we running out of things to do?
    
    I agreed, for different reasons, with your last remark in .22.  I could
    never understand why we ended up using the SRM as a kitchen sink -
    throwing everything in there and never had a clear strategy/design for
    it (separating system design/debug, manufacturing, diagnostic, and
    operations needs from each other).
    
    Console should be simple, boot the OS and get lost.  Instread, with
    SRM, the user ends up witnessing a conglomeration of everything being
    tossed in there along the way from the conception of a system to its
    birth.
    
    --svb

    
    With some reservations (not everything that is good for the customer is
    necessarily good for DEC) I agree.
    
    So, my question is:
    
    	- How many customers switch between NT and VMS/UNIX on a
    	  regular basis?
    
    	- Is this a minor inconvienience, or a major issue.  That is,
    	  are there customers who have decided to not buy, or to 
    	  dump Alpha systems because of the dual console issue.
    
    	- Will the customers tolerate the loss of any functionality,
    	  on either side (NT vs VMS/UNIX)?
    
    	- Do the customers care what is "under the covers" of the console?
    
    	- Do they prefer one user interface over the other?
    
    	- Do they continue to need a serial line console (even if they also
    	  use a graphics console) at times?
    
    

    Re .23, please save it.
    
    What interests that are put in front those of the customers?
    
    If anything, the AlphaBIOS team was the one that took the real effort
    to go and talked to the real customers at large and arrived at what
    they had based on the customers' feedback.  As an outside observer,
    that was a neat thing for me to see.
    
    Show me one customer (any customer - OpenVMS, UNIX, or NT) who says
    they need to switch OSes, and i will show you many more who says
    "that's nice, next?".
    
    --svb

    .24
    
    I never really joined VMS development until well after it's power had
    waned.  I had been on the other end of the NIH short end of the VMS
    stick in groups trying to work with the VMS group.  I didn't condone
    the attitude from VMS then, nor from NT now.  When VMS was defanged,
    all the people who had ever been trampled by VMS sharpened their
    knives, and help to engineer it's ultimate decline.  Take care to learn
    from the past.  The 800 lb NT Gorilla *has* made its own enemies along
    the way.  When the company shifts its strategy to Yet-Another-O/S, the
    knives will come out again.
    
    There is only one reason to join the console strategies, and that is,
    if the NT group is no longer interested, or no longer staffed to do it. 
    Providing that neither of these are true, then we may have the
    technical discussion, but it is a meaningless debate.
    
    While the SRM console appears to have a hodgepodge non-strategy, in
    reality, it started with a well thought out plan, based on previous
    experience, and designed to be O/S neutral.  The hodge-podge appearance
    is more a function of the fact that needs tend to drive deliverables. 
    And multiple consumers of the console, have different, often
    conflicting needs.
    
    You can seperate out many of the functions that the console provides,
    and distribute them to other places (O/S groups, diagnostic
    engineering, manufacturing, field service, etc).  It doesn't always
    make things cheaper, simpler, or more consistant.
    
    But in fact, we concluded the same thing in the console taskforce
    report - that simpler is better, and what we believed was a minimum
    requirement for a console.  But again, our wayback machine was broken
    and in the end nobody has the budget, or the stomach, to go back and
    try and make major changes to how things work.
    
    

    Re .27, your thoughtful reminder is well appreciated (having gone from
    VMS, to TOPS-20, to TOPS-10, back to VMS, and now at NT).
    
    --svb

    Re .25, these excellent questions should be put to the customers
    directly (perhaps also to product management).
    
    My personal take on these...
    
    - How many customers switch between NT and VMS/UNIX on a regular basis?
    
    	I don't know the numbers.  But for every one (OpenVMS, UNIX, and
    	NT) that i heard saying they need to switch between OSes, there
    	have been many more saying it is not either a requirement or a
    	factor in their purchase decisions.  It's a data point.
    
    - Is this a minor inconvienience, or a major issue.  That is, are there
      customers who have decided to not buy, or to dump Alpha systems
      because of the dual console issue.
    
    	Which one is "the dual console issue" (having two or not having
    	two)?
    
    - Will the customers tolerate the loss of any functionality, on either
      side (NT vs VMS/UNIX)?
    
    	I don't know, but my guess is they will not tolerate on either
    	side.
    
    - Do the customers care what is "under the covers" of the console?
    
    	I don't know, but my guess is they do not care.
    
    - Do they prefer one user interface over the other?
    
    	The NT users do prefer a GUI (such as AlphaBIOS' or those of other
    	Intel PC BIOS') over a command line interface.  I know i do.
    
    - Do they continue to need a serial line console (even if they also use
      a graphics console) at times?
    
    	The NT users do not know what to do with it if one is given to
    	them.
    
    --svb

    VMS and UNIX users have come to count on the fact that they can
    remotely manage all their systems by plugging the serial lines into LAT
    boxes, or a Polycenter Console, or whatever (modem, etc).
    
    Manufacturing counts on the ability to run a script to test, and
    configure systems.  They even do this using ARC on a serial line (and
    you should hear the complaints about nice things like filtering out the
    time changing).
    
    Frankly, I believe that everyone has what they "need" today, and that
    despite belief that there are economies to be had by a single console,
    and some simplification for some end-users -- it's not worth the effort
    to do anything, unless it is to add the AlphaBIOS user interface as an
    optional GUI for the SRM console.  I don't even believe that (except in
    a few cases) it's worth the effort to try and boot NT from anything
    except ALphaBIOS - certainly in the low-end space it doesn't make sense
    to change.
    

    Re .30, actually i was wrong on the last one in .29 about the serial
    console line.  The NT kernel developer users would want to have the
    serial connection for kernel debugging.  But it's the same serial port
    being used for modem, printer, etc. and nothing special being expected
    from it.
    
    Yes, i'm familiar with the remote management requirements of OpenVMS
    and UNIX.  I was involved in the development of the products you cited.
    Remote/Unattended system management is going to be the weak link in NT
    going for the enterprise scene (but that's another thread for another
    day).
    
    --svb

>    Re .23, please save it.
>    
>    What interests that are put in front those of the customers?
    
    It's obvious from this discussion and from Fred's remarks that the
    obstacals to a unified console were not technical, but political, so
    the political interests, whatever they are were placed in front of the
    customers. 
    
>    If anything, the AlphaBIOS team was the one that took the real effort
>    to go and talked to the real customers at large and arrived at what
>    they had based on the customers' feedback.  As an outside observer,
>    that was a neat thing for me to see.
    
    They arrived at what was good for customers of NT.  I doubt they talked
    to many OpenVMS or UNIX customers.
    
>    Show me one customer (any customer - OpenVMS, UNIX, or NT) who says
>    they need to switch OSes, and i will show you many more who says
>    "that's nice, next?".
    
    So we ignore the subset of customers who need to switch OSes?

I heard that switching between O.S. is actually never really used, but 
the feature is still demanded by some customer due to political reasons!

The technical folks really want an OpenVMS or Unix system.  To get the 
purchase order approved by a pointy-haired boss, the technical folks use 
the excuse that "Oh yeah, we can convert it to NT whenever we are ready" to 
get the order approved by a boss that only knows about NT.


							-Paul
						

    Re .32,
    
    I take it you were not part of the SRM/AlphaBIOS discussion, and you
    did not hear both sides of the story (since i refrained from discussing
    it in this thread).  I suggest that your hasty remark was totally
    off-base.  Your insistent insinuation of wrong-doings by others in a
    public forum without supporting evidences is uncalled for.
    
    I also take it you never heard of return-on-investment or similar
    concepts.  Why incurring the expenses when there are alternatives and
    the return on that investment cannot justify the expenses in the first
    place?  If there is a very small subset of the customers who need
    multiple operating systems, they can always buy multiple boxes.  The
    economic reality is we cannot be everything to everybody and cannot
    please everyone without annoying no one.  We'll just have to pick and
    choose the ones with the least pain for the majority involved.
    
    The engineers from OpenVMS and UNIX have been doing their good deeds
    for many years to look out for what is good for customers of OpenVMS
    and UNIX, respectively.  Why is it suddenly a sin for the engineers
    from NT to find out how to please the customers of NT?  Would you not
    think that it's bordering on being ridiculuous to talk to the OpenVMS
    customers, who may have no interest in NT whatsoever, to find out how
    to please the customers of NT?
    
    --svb

    Without wanting to get into religious issues of AlphaBIOS vs SRM:
    
    Haven't we had a real customer-driven discussion not too long ago of
    the impact of shipping systems with only one console, driven by a
    workstation whose name I forget but which was first (and hopefully
    last) to ship with only enough flash for one console ?
    
    Wasn't the impact (time + effort = money) enough for the folks who made
    the half-flash decision to decide not to do the same again?
    
    Does that count as evidence for the "who really cares if we can't swap
    OSes" school of thought here ?
    
    regards
    john

>    I take it you were not part of the SRM/AlphaBIOS discussion, and you
>    did not hear both sides of the story (since i refrained from discussing
>    it in this thread).  I suggest that your hasty remark was totally
>    off-base.  Your insistent insinuation of wrong-doings by others in a
>    public forum without supporting evidences is uncalled for.
    
    No, I was not part of the discussion.  I'm just a witness to the
    results.  Since I don't have all the facts, you are correct that I was
    hasty in my insinuation of wrong-doing and I apoligize.
    
>    I also take it you never heard of return-on-investment or similar
>    concepts.  Why incurring the expenses when there are alternatives and
>    the return on that investment cannot justify the expenses in the first
>    place?  
    
    Of course I've heard of ROI.  Did the ROI analysis of two seperate
    consoles take into account the duplicate engineering and maintenance
    costs of having two consoles rather than sharing code where possible?

>   If there is a very small subset of the customers who need
>    multiple operating systems, they can always buy multiple boxes.

    Wish I could present that argument to my cost center manager and have
    him buy it ;-).

>    The
>    economic reality is we cannot be everything to everybody and cannot
>    please everyone without annoying no one.  We'll just have to pick and
>    choose the ones with the least pain for the majority involved.
    
    I agree, but that doesn't mean we shouldn't try to please as many of
    our cusotmers as possible.
    
>    The engineers from OpenVMS and UNIX have been doing their good deeds
>    for many years to look out for what is good for customers of OpenVMS
>    and UNIX, respectively.  Why is it suddenly a sin for the engineers
>    from NT to find out how to please the customers of NT?  Would you not
>    think that it's bordering on being ridiculuous to talk to the OpenVMS
>    customers, who may have no interest in NT whatsoever, to find out how
>    to please the customers of NT?
    
    Well, as an AlphaStation customer I'm a customer of NT, UNIX and
    OpenVMS.  I'd like the console to be consistent and usable when running
    all three operating systems (which I do).  I don't think it's a sin to
    please customers of NT - I don't think I stated that, but I don't think
    pleasing NT customers means you should annoy UNIX and OpenVMS
    customers.

    "pointy-haired bosses" excluded, the customers that would most benefit
    from being able to use one hardware system to boot multiple O/S are
    ISVs, Edu., and DIGITAL internal.  I deal with ISVs.  While they
    consider it a pain to have to switch consoles, they deal with it.  I
    don't worship the ROI, but I don't believe I'd spend much to fix this. 
    The customer would still need 2 disks, 2 ECUs, and there are still some
    options supported-by-one-but-not-some-other.  To delight the customer,
    we'd have to address them all.
    
    Mark Schafer
    SPE MRO
    297-3524
    
    ps. Could you get the SRM to display just a blue screen on April 1st? :-)

    Re .35, i believe the gist of that problem was the workstation in
    question had been shipped with dual flash.  The change to single flash
    was not widely publicized to the field.
    
    The field people was unpleasantly surprised by that change.  One of the
    unintended results was customers who expected a UNIX/OpenVMS system and
    received an NT ready system (or vice versa) had to go through hoops to
    make the changes.
    
    The complains that i heard were not involved with switching OSes.
    
    --svb

    Re .36, if you follow Fred's analysis in .27 - we got SRM to where it
    is today because it tried to be everything to everyone (OpenVMS, UNIX,
    system hardware designers, manufacturing, field engineers, customer
    support engineers, et al.).

    Having things done once, to be all things to all, is not necessarily a
    good thing all the time.  This is, if anything, a good example of
    necessary "targeting" design and engineering.

    Inherently, when you have two or more constituencies who do not see eye
    to eye about the others' computing styles, pleasing one will, in most
    cases, unavoidably displease the others.  It does not mean that we
    should refrain from pleasing the ones who will help us reach our
    business goals.

    --svb

    Some imput from a Customer Support specialist.  There are many people
    who have AlphaStations running OpenVMS or DigitalUNIX who are wanting
    to install Windows NT to try it out and compare.  Believe me they
    do not like the half flash functionality.  One question to anyone
    who claims to know the answer.  As I understand from other notes
    here, the decision was based on costs,  two ROMs are cheaper than 4.
    Why didn't we, Digital,  capitalize on this and offer a second
    model of AlphaStation 2xx with full ROM functionality and charge
    more for it?  I have been polling upset customers asking,  if we
    offered a system with full function ROMs,  would you have paid
    $100 more for it.  Not one has said no.  
    
    Tom Rocca
    CSC-Atlanta
    Windows Support Focus Team

    Re .40, you nailed the issue...
    
    That is, these customers stated in their requests the desire to dabble
    into NT in the most economical way.  I can almost guarantee you that
    these customers were not looking to set up both NT and another Digital
    operating system (OpenVMS or UNIX) on the same system box and in a
    deliberate manner, plan an operational production environment that
    calls for periodical switching between the two operating systems.
    
    Other than some ISVs/IHVs (as mentioned in .37), that i am aware of,
    who have set up their test and debugging systems this way, i know of no
    customers who have done it on a production system.
    
    --svb

    OK, thanks for clarification... in the following, for ARC read
    AlphaBIOS too.
    
    Here's another one. The customers/partners/OEMs I work with who use NT
    (many having moved up from Intel, not down from UNIX) often use obscure
    custom hardware (PCI, EISA, whatever). On *many* occasions when
    troubleshooting it has proved *very* useful to have SRM as well as ARC,
    to see what SRM thinks is in the system. On Intel they just run a
    trivial DOS program to display the config or whatever. On ARC they are
    on their own.
    
    Similarly there are no user-guided diagnostics in ARC, but there are in
    SRM.
    
    Where is this dialog taking us ?
    
    regards
    john

If a customer wants to dabble in Windows NT in the most economical way for 
everybody (including themselves), they'll find a spare cheap x86 box somewhere 
and install Windows NT on that. Who needs an Alpha to dabble? And if they do, 
Alpha systems are as cheap as x86 systems these days (or so we're told).

As for creating half-flash/full-flash versions of Alpha systems, will the added 
confusion (and therefore time and money) generated by an extra part number, and 
the extra production and maintenance cost of providing two almost but not quite 
identical systems, be outweighed by the extra revenue?

PJDM

    Re .42,

    If the developers are forced to work on an older Alpha system model
    that is not supported by AlphaBIOS, they're handicapped by ARC in the
    area of system configuration display.  AlphaBIOS, on the other hand,
    can tell the users/developers plenty about the system and options that
    have been configured on it.  SRM does not have any advantage over
    AlphaBIOS here.

    Why should there be user-guided diagnostics, whatever that is, in
    AlphaBIOS?

    That is the crux of this thread.  Console should be simple, boot the OS
    and get lost.  It should not be the kitchen sink where all things for
    all people are tossed in there.  It should, instead, have a facility to
    execute "plug-in"s, the way AlphaBIOS allows ARC applications to be
    run.  This allows extended, occasional, and perhaps proprietary
    functions accessible to a very small special set of users (such as
    field service engineers, device driver developers, etc.).

    There is an internal ARC developer kit that has been distributed to
    various groups within Digital for some time now.  There is now an
    equivalent external ARC developer kit available to all IHVs and ISVs. 
    This has been the method for extending AlphaBIOS functionality. 
    DECwest Engineering uses it (e.g. we ported the entire PCI SIG
    compliance tool suite to Alpha).  Vendors use it (e.g. Adaptec used it
    to port their SCSIselect DOS tool to Alpha).
                                                
    Please send me mail if the I*V you are working with needs it.
    
    Where is this dialog taking us?
    
    Where do you want to go today? 8^)
    
    --svb

In the world-wide perspective, most PC systems use BIOS SETUP screens as
the "console".  This model seems to be robust enough for 4-8 CPU mid-range
PC servers.  The popular "flavors" are Pheonix and Award, with each 
manufacture doing their own customizations.  The market seems to accepts 
that no two setup screens are exactly alike.

In following the move to commodity hardware, perhaps it is time to consider
commodity firmware, out-sourced through Pheonix or Award with a small 
amount of Digital-specific customization.  Maybe we need to port DOS to 
Alpha for diagnostics.

This would require a *very* large corporate effort to port three major 
operating systems to the new interface.  Plus we would need to fund 
3rd-party to port BIOS setup to ALPHA.  Would this model yield long-term 
benfits?  Perhaps no one believes that all three O.S. will be around for 
the long term.



							-Paul