Conference 7.286::digital

    Concerning the ease-of-use software:  Will those groups that are
    passing out the idea that this software runs itself please quit
    doing so?
    
    It may be easy to use.  It may be easy to install.  But except for
    some turnkey systems like PCALLIN1, it NEEDS A SUPPORT STAFF!  I
    am sick and tired of fielding questions from users/managers out
    there that say they have installed Message Router and/or ALLIN1
    and/or DECmail, and now their system manager (a secretary until
    two weeks ago) is confused and the software isn't running right.
    
    As far as the "user-agent" mail systems are concerned, "turn it
    on and be up and running" in five minutes is bullshit!  There are
    already enough problems with na�ve managers that think computers
    are magic without encouraging some spell-casting via advertising!
    DEC already looks like a bunch of used-car salesmen to some customers
    (such as the Food and Drug Administration, and the Naval Research
    Facility in Washington D.C., since you asked...).  Please--let's
    quit kidding ourselves internally and externally.

    Re: .0
    
    There is a third philosophy: ease-of-use with a small support staff.
    
    For example, A-to-Z.  [What's that?]
    
    In fact, as of Dec. 1, A-to-Z will move to BOSE, with the aim of
    becoming "a subset of ALL-IN-1 which ... is installable and
    maintainable by end users".  (The quote is from a slide presentation
    by Gerry Hornik.  I'm not sure exactly what it means or implies,
    but the general goal is clear.)
    
    I think/hope this third philosophy will come to represent much of
    DEC's philosophy for business computers.

    Having been burned badly by "ease-of-use" and "ease-of-support"
    with some other products, I will reserve judgement on how easy A-to-Z
    is to support.
    
    Message Router is easy to support.  But you need a full-time staff
    to do it.  I hope A-to-Z doesn't have the same problem.

    I think we need to distinguish ease-of-use, ease-of-learning, and
    ease-of-support.  I think VMS MAIL satisfies the first and third
    of these, and doesn't require a whole lot of learning either.
    
    I don't know why we have this proliferation of mail facilities,
    but I really believe we need a single corporate-wide electronic
    mail facility, possibly with different user-interfaces if necessary.
    My vote would go for VMS MAIL, since
    
    	- it's already on every VMS system in the world (possibly also
    	  on RSX, etc.)
    
    	- I think it could, possibly with a different user-interface,
    	  satisfy all the requirements.
    
    In the VERY near future, we'll need a mail facility that will let
    you mail around documents containing pictures, etc.  When that time
    comes, we'll be in real trouble if we continue this duplicated effort.

    From my perspective, we need to train our own internal folks better
    on *how* to support some of these products, particularly ALL-IN-1.
    I'm not sure where A1 fits into your categories: it's easy to use
    from the *user* perspective, but how much support staff do you need?
    Clearly the answer is: that depends.
    
    For a single node that can get by with the builtin functionality,
    it requires very little support staff.  But when you throw in message
    router combined with a very non-vanilla A1 system, then you'll need
    a larger support staff.  Customizing forms/scripts *can* be a trivial
    matter, but most sites (both internal & external) have non-trivial
    requirements in many cases.
    
    In regard to mail specifically, A1 will talk to all the mail systems
    that Digital uses; ie, another A1 mail system, Decmail, or VMS mail.
    (note to .1: yes you *can* mail a WPS+ document to a vmsmail user,
    you just need to convert it to ascii first, but he'll still get
    the thing in a readable format!)
    
    Sorry to focus on a single product, but unfortunately, ALL-IN-1
    falls into many categories simultaneously.
    
    Jon

    Pete's right; the problem is endemic.
    
    I think we can almost see the difference between "Maynard" (advanced
    user) and "Merrimack" (non-technical office user) programs, although
    "Maynard" is often in Nashua or elsewhere these days. 
    
    I think we blew it by not positioning All-in-1 correctly.  I was
    at VRO when we were a field trial for V1.0, which was well after
    its original CP/OSS (Charlotte) days but before it was quite so
    strategic.  Frankly, it was a disgusting pig which nearly brought
    DONJON to its knees.  V2 does away with all the subprocess creation,
    but it still doesn't win any awards for efficiency.  And it's being
    used within other products.
    
    Now what happened with All-in-1 is that we set up a site main menu
    which pointed to our "favorite" applications (DECmail, Digicalc,
    Calendar) and let you escape to the "native" A1 menu as well.  Some
    non-technical users lived with it for a fair while, but the general
    trend was to learn an application via A1, and then learn to invoke
    it directly from DCL.  It doesn't take a PhD to learn to type "calc"
    at a '$' prompt, and it saves about 15 seconds of A1 startup time.
    Unless the system is busy, when it's longer.
    
    For the brandy-new-to-computers office person, for whom even simple
    command mode is intimidating, A1 is great.  But after a year, it's
    a waste, when applications can be run "directly".  So I think we
    should have positioned A1 as "Training Wheels" instead.  With a
    bundle of similar-looking office software to go with it.  The other
    facilities of A1 used in program development are generally redundant
    with SMG, FMS, TDMS, etc. anyway, or could have been done better
    if it weren't for trying to stay backwards-compatible with CP/OSS.
    Now we've got mail agents and wsp agents which rely on A1 folders
    while VAXmail V4 proves you can hide a directory structure pretty well
    without A1's help.
    
    It shouldn't take a half-decent programmer very long to add a "training
    wheels" front end to VAXmail, and even hide Nmail better within
    it, or Message Router, and make it a nice, supportable product.
    But too much "management" and faze review will probably result in
    another DECmail disaster.  Too bad folks don't learn from others'
    (or their own) mistakes.
           fred

    The key to ANY computer system should be to satisfy its users' needs.
    
    Hard as it may to believe to some of the people who have replied
    here, there are some VERY non technical users in this company.  VAXnotes
    is EXTREMELY difficult for the AVERAGE non technical user to use
    in Digital.
    
    I always find the attitude of the REAL technical people as expressed
    in a couple of these replies to be entertaining and somewhat sad.
    They are basically saying that the standard VAX/VMS user interface
    is all any human needs to have to adequately deal with the system.
    WRONG!!  

    I am proud to say that I was one of the very first haters of ALL-IN-1
    (it was called DECaid when I learned it - before CP/OSS).  It is
    really easy to hate if you view it as nothing but a menu driver.
    It is FAR more than that and worth every resource it sucks up on
    a VAX.  That isn't to say that it should be on EVERY VAX in the
    world.  Just any VAX with non technical human type users.

    The complete cost of user friendly software must be addressed. 
    The price must be paid one way or the other.  It is amazing that
    we do what we tell our customers to not do.  We ignore the support
    and ASSUME that complex software is easy to maintain.

    Don't forget that there are FAR more non techies than techies in
    the world.  Digital's future depends on how well we satisfy them.
    
    Don

    Mentioning customers as .1 is out of line.
    
    This note appears to me to be a jumble of problems associated with
    how we manage information systems and has lot less than meets the
    eye with respect to product design.

    	Maybe we can write a back-end compiler/interpreter language
    for writing business applications, and implement a few different
    user interfaces, including all of the existing ones. This is the
    TPU style of problem solving, the way TPU implemented EDT more
    efficiently than EDT. 
    
    	You could even just extend TPU, by adding the necessary functions.
    
    	Ed

I want to say something, but I'm not sure where to begin.

Around 4 years ago a decision was made to use DECsnail (I mean DECmail)
for group communications.  Among the reasons was the fact that we needed to 
communicate with the field people.  I protested and complained daily 
about how slow the product was.  BUT... I miss it!  Today all I have is 
VAXmail (uninformed people won't allow ALL-IN-1 on our system) and there
are so many things one could easily do with DECmail that can't be done
with VAXmail (or if they can, they're not obvious).  I scream every time
I want to send a reply not only to the sender of a message but to the entire 
distribution list.  DECmail would simply ask you if you wanted your
reply to go to everyone.  DECmail allowed you to write cover memos when 
forwarding memos, but VAXmail only allows a subject line.  I could go on 
but it's rather pointless.

There are lots of things one could say about ALL-IN-1 as well in the
area of functionality.

In general, functionality costs and you get what you pay for.  VAXmail 
and a bunch of other nifty utilities are cheap and perform well but have 
limited functionality.  Something like ALL-IN-1 probably has more 
functionality than you need, is expensive (software AND support) but is 
slower.  So, if you want it you need to be prepared to put it on a 
bigger machine and allocate support resources.  It's the people who 
simply install a product without addressing the resources and support 
costs who get burned.

-mark

    RE: -1
    
    >DECmail allowed you to write cover memos when forwarding but
    >VAXmailonly allows a subject line.
     
    Try REPLY/EDIT in VAXmail. You can even set up your favorite editor
    to be the default (mine is TECO).
    
    Deb

    
    	The question in .0 brings back the conflict of the ENGINEERINGnet
    vs the EASYnet. Enet vs DBN. Two different audiences, two (or more)
    different products.
    
    	-John

    re .11 re .10:
    
    I believe you meant FORWARD/EDIT.  But let's not prolong this
    digression into comparing mail features.
    
    I believe that the Easynet should support a "mail system" that allows
    users to use the mail program of their choice, to send to and receive
    mail from any other employee on Easynet, and not have to worry about
    which mail program the other employee is using.  Enough of this
    "my mail program is better than your mail program" stuff.
    
  --Simon
    

    Much of the issue comes down to training.  On the system that I
    use, we were blessed with quite a few 'non-techie' users about 
    two years ago.  We refused to put ALLIN1 and DECmail up on the system
    because frankly, we didn't have what we preceived to be 'a lot of
    time' to spend on application management.  We felt it would be better
    to spend the time and effort to train the new users in the more
    difficult utilities (vaxmail, vaxnotes, edt) than a 'forever' job
    of maintaining tools that none of the group used.  It has worked
    for the most part.  
    
    We have had to put up DECmail because of the field's lack of accounts
    for network support people, but few use it for their day to day
    communication.  
    
    We don't have the resources to have a application support group
    and the cost of having facilities do it for us seems too high.
    
    bill
     
   

    You'd be amazed at what normal people can learn.
    
    During the late 1970s I was at Bolt Beranek & Newman.  Their
    _secretaries_ did their word processing using TENEX TECO and TENEX
    Runoff.
    
    Believe it or not.
    
    	Ripley

    re -.1:
    
    	I'd suggest you upgrade your perspective on secretaries if that
    surprises you...
    
    grins,
    Marge

    re:-.1
    
    It doesn't surprise me one bit.
    
    After all, I wuz green behind the ears then.  I didn't _know_ that
    secretaries need _menus_!

    (The "believe it or not" was aimed at people who do.  Now you get
    it, Marge? )

    
    gotit, thanks!

    Most people in sales DO use decmail on an everyday basis, in fact
    DECmail is the only VMS application that most salesmen can use without
    constant support. DECmail is huge and slow and a burden for system
    managers and operations staff alike. The current release of DECmail
    is the last as I understand it and the corporation is about to make
    ALL in 1 the default Mail Standard internally and for sale to
    customers. By the way I've never seen a DEC software product that
    requires as much attention and support from the system management
    perspective that DECMAIL requires, I've worked it down to the following
    equation:
    
       Time saved in decmail for users  = (system manager    ** 2 )
           by ease of use menus            support time
    
    VAXmail is my personal "pick to click", its quick, easy to use
    and is not a drag on system resources and personnell.
    
    -Joe
    

    	I'm a little confused. Why does DECmail and related (?) mailers
    take so much support from system managers? I know nothing about
    them, but I can't figure out what the mailers do to be so much of
    a drain...
    
    	I use VAXmail now, but I can't say I "Like" it. TOPS MS ...
    now there's a mailer that made sense!
    
    	Ed

    The fundamental difference between DECmail and the products "similar"
    to VMS's MAIL is that DECmail keeps the messages in a large, central
    database. This allows it to implement sharing of the messages. Within
    a system, a message sent to hundreds of recipients exists only once
    with pointers to it from each user's folders. And within a user,
    even if copies are placed in multiple file folders, only one copy
    of the text exists.
    
    The price of having a database is that someone must own and maintain
    it....

DECmail is an anomalous case.  It was a port of the internal EMS system from
stand-alone MUMPS to VAX MUMPS as a stopgap until the corporate mail system
(a part of OFIS) was ready.  OFIS died and the corporation was left with
DECmail as its only full-function mail utility (VMSmail doesn't count
because it is missing important features such as distribution list management,
carbon copies, document inclusion, store-and-forward, etc., etc....).

DECmail has severe problems, the worst of which is reliability.  It has a
bad tendency to trash its database, which is why it requires a large
support staff.  Its basis on MUMPS is also unfortunate, because VAX MUMPS
tends to trail the rest of the VAX layered product world badly in terms of
support for new releases.  For example, does VAX MUMPS support clusters
yet?  That is the main reason why MTS sites have been held to VMS V3.n.

It is interesting to contrast DECmail with Message Router.  Both systems
have a centrally-managed message database.  DECmail is a continual system
management headache.  Message Router causes very few problems.

--PSW

    re: .22
    
    Message Router is a postoffice system.  Users can't use Message
    Router directly--they must go some intermediate "User Agent" such
    as DECmail or ALL-IN-1 (or VMS mail "Gateway").  I agree with Paul,
    though: Message Router (V2.n) works nicely.  almost every bug or
    complaint we've run into has been the fault of the User Agent, not
    Message Router.

re:.-1,.-2	Whoah!!!

DECmail uses the message router as its transport, so you can't compare 
the two.  It's like apples and oranges.  I agree that the message router 
is a good, solid reliable piece of code.  That's one of the reason's 
that DECmail reliably delivers the mail for you.

Now if it happens to get trashed after it arrives, that another story.

BTW - the name of the product DECmail is written in is DSM (Digital 
Standard Mumps) not to be confused with Digital MUMPS which had been 
replaced with DSM around 7 or 8 years ago!

-mark

RE: .-1

It is NOT an apples/oranges comparison to compare DECmail and Message Router.
DECmail is both a transport medium (when operating intra-node) and a
user agent to Message Router (when operating multi-node).  I was comparing
the transport capabilities of both products, which is an apples/apples
comparison.  If you want a apples/apples comparison on the user agent level,
compare the DECmail/Message Router pairing to the DMAIL/Message Router pairing.

Any way you look at it, DECmail loses badly when it comes to data integrity.
Either the code or the intra-node database design is very fragile.
DMAIL/Message Router takes almost zero system manager time to maintain.
It also consumes almost zero system resources.  DECmail/Message Router is
a continual system management nightmare, and it consumes 1/4 of a 11/750
even when idle.

--PSW

Re: .22 

The VAX DSM group is getting sick and tired of all the MUMPS-bashing 
we have to deal with in this corporation, most of which is based on 
hearsay, innuendo, old (in some cases, very old) information and 
rumor.

Note 216.22 is a perfect example of the misinformation we're dealing 
with, and I feel compelled to come to DSM's defense.  (Sorry to have 
taken so long to respond, but I just came across the note recently).


	>DECmail has severe problems, the worst of which is
	>reliability.  It has a bad tendency to trash its database,
	>which is why it requires a large support staff. 

You can't blame VAX DSM for all of Decmail's problem. They are
currently running under VAX DSM 2.2, using RMS ISAM files for the
database. 

V2.2 has been unsupported for over a year, and we have been consistently 
urging them to upgrade to the current release of DSM (which is 3.1), 
and to convert from RMS (with all of IT'S attendent maintenance 
headaches) to a true DSM database.  The fact is that many of the 
problems associated with DECmail are tied to their dependence on RMS, 
not to VAX DSM.  A VAX DSM database is kept in a file 
maintained by our own background processes (write demon and 
garbage collector) and it is stored as a multiway balanced 
B-tree, providing significantly improved performance AND reliability 
over RMS ISAM files.

	>VAX MUMPS tends to trail the rest of the VAX layered product
	>world badly in terms of support for new releases.  For
	>example, does VAX MUMPS support clusters yet? 

That's just not true.  We provide maintenance upgrades when required,
and have produced new releases with performance and functional
improvements on a yearly basis, now, for the last 3 years.  Currently,
we are working on our next major release for later this year. 

We have supported clusters ever since they came out, and have no
problems running in a clustered environment. 

CAPS and COG supply customer support and internal support for the 
various sites using VAX DSM both within Digital and at our (many) 
customer sites scattered throughout the world.

There are 2 notes files dealing with the PDP-11 and VAX products. 
VAXWRK::DSM and VAXWRK::VAXDSM. 


re: .24  - thanks for the kind words...

						Bob Craig
DSM Technical Programs Group

    .26:
    
    Well, maybe the MUMPS-bashing isn't deserved;  but remember that
    DRECKmail is most people's introduction to DSM.
    
    Recall too the details of the indictment:
    
    -- DECmail is well-known for unreliability;
    
    -- DECmail has had its last version shipped (thank God!);
    
    -- DECmail is layered on an unsupported version of DSM (which one
       might assume has had some bugs fixed in the subsequent, supported
       versions?)
    
    FWIW, a couple of years ago, I was told that I would have a DECmail
    account (rented) on a (rental) machine.  The machine was not easily
    accessible from where I was, and usually overloaded and slow.  So
    I didn't use the account much.
    
    I checked it out once, and discovered that in 3 months I had received
    13 messages.  Nine of the thirteen were messages of the form
    
    "Due to {hardware/software/firmware/underware} failure, all DECmail
    sent between 03:00 on Sunday, March 22 and 02:00 on Monday, March
    23 to SNA, MOO, ZOO and Timbuktu was lost.  Please resend any important
    mail that was sent during that time period."
    
    (Oh, and I think that three of the remaining four turned out to
    be junk mail caused by somebody with hyperactive distribution lists.)
    
    I told them to flush the account.
    
    Dick