Conference 7.286::digital

    It's already like this on our machine.  ALL-IN-1 is it.  However, a $
    at the Choice field will take you to DCL.  I honestly don't know if
    this is something that the A1 manager can take away or not, or if very
    many of them even know it exists.  I haven't found that it was worth
    the trouble to fight for a non-captive account. Course, I'm a system
    manager at a customer site (among other things), and get all the DCL I
    want at "home" (so to speak). 
    
    

        UNfortunately, field office managers have a very basic perception
        of what computing resources are  required by their subordinates.
        I would phrase a polite but firm memo to management at your
        site, pointing out that in order to provide optimum service
        to your customer base, in turn giving maximum Customer
        Satisfaction on the Customer Survey (that one always hits
        em where it hurts!). If you do not get a reasonable response,
        elevate the issue.
        
        q
        

    re .1
    
    Yes, it is a standard feature of ALL-IN-1 to take you to the VMS
    prompt in a subprocess when you enter a "$" for a menu choice. 
    But this is also enabled/disabled on a per-user basis from the ALL-IN-1
    profile, which is [presumably] controlled by your system manager.
    
    If you can get to the "$" in the ALL-IN-1 subprocess though, you
    still may not be home free, depending on what you need to do.  I
    would still think that if not getting to the "$" prompt is preventing
    you from doing your job, then the situation would be changed.
    
    Good luck
    Jon

    You also may be able to create (or copy in from another node)
    a login.com with an option to invoke A1 or not.. giving you 
    a system that you can do real work on..
    
    gee, you mean you do other things besides WPS documents ???
    
    

    It's already that way here.  There was a loophole everyone used for a
    while, but it was closed recently, so ALL-IN-1 is it - captive accounts
    for everyone.  The program development menu is gone too, so we can't
    customize screens or ALL-IN-1 commands.  There's no way to SET HOST, or
    to execute any sort of command procedure or access an offnode VTX
    server -- any number of things!  It's a real pain!  It has been made
    very, VERY clear that it won't be changed.  I think it's happening most
    everywhere... 
    
    							Pat Resende 

	Not on my GPX it won't... (Nor on many of the systems I
	manage)

						mike

    I agree about documenting the fact that this will adversely affect
    customer satisfaction.  Lack of convenient access to DCL also means
    that the SWS manager might not be able to make as much money ($$$)
    because his/her specialist's won't be as well learned, in addition to not
    having as much of an advantage over the competition.  In particular:
    
    1) decreases SW Spec's ability to learn how to use new tools, which
       has a direct impack on knowledge to be imparted to the customer.
       Examples of tools which might be on a DEC system, but not a
       customer system (and which customer might pay $ for consulting
       on):  VAXset, DOCUMENT, GKS (which requires programming languages
       as well), TPU, and the tools in the Toolshed.
    
    2) Lack of access to DCL limits experimentation, which can decrease
       the billing level a SWS manager can bill a specialist at.  Limits
       the possibilities of that specialist to deliver services at the
       high billing levels (Level III and Level IV, in particular),
       thus less revenue for the given human resources.
    
    Personally, I wish someone from above would clean house on SWS
    management.  There are too many incompentent ones out there making
    bad impressions on our customer base.  Good luck; I doubt that it
    will make any difference.

    I'm one of an apparent endangered species, a district DIS manager,
    and until the recent switch from DECmail to ALL-IN-1 avoided the
    area DIS directives to switch to captive accounts. My reasoning
    was that in fact we had a true cross functional mix on the district
    DECmail system and others external to the F&A function had a true
    need for the $ capabilities. Everyone is now on the Area DIS
    ALL-IN-1 systems in captive accounts. The rational to this is that
    the aLL-IN-1 systems are to be used for office automation. Office
    automation is viewed as production type application and if you
    need to get to the $ to do your job you should get the necessary
    resources (systems(s)) from your functional management. I don't
    see much sympathy coming from too many corners to change the
    situation.
    
    
    Terry...{~}{~}

    Re .0
    
    We have the same sort of restrictions on our ALL-IN-1 systems here
    (Reading, UK) and as an ex-software specialist and ex-system manager, I
    had to be persuaded that this was the right thing to do. 
    
    Look at it from a strategic point of view - Office automation systems
    should be dedicated because they have their own particular resource
    requirements, system parameters etc in order to cope with the
    power-sapping of ALL-IN-1 and it's associated facilities. Our ALL-IN-1
    systems (2 4x8700 clusters) serving the UK HQ have been set up so that
    most of the things a user needs is available through ALL-IN-1 itself -
    VTX, NOTES, spreadsheets, DECgraph, file transfers (host - DECmate or
    Rainbow or PRO) and vice versa, file copying, command file creation and
    activation, SET HOST, VAXphone and on and on ..... while other systems
    and clusters have been set up to deal with production systems for
    CAS, Logistics, F&A, SWAS and these separate systems & clusters
    do (in most cases) have DCL access.
    
    If there are real reasons why you need DCL to do technical work not
    associated with office automation, and I agree that it is usual for
    someone such as a software specialist to need this, then separate
    resources should be allocated. Clearly, sometimes this can't be done
    because of funding etc, in which case there should be provision for
    either DCL access through an ALL-IN-1 menu or a separate (non-captive)
    account on the same machine.
    
    I have learned to live with not having DCL access, even though I know
    of a loophole in our ALL-IN-1 system that will allow me to get there if
    I really want to.
    
    You don't say exactly what it is you want to do with DCL. Make the
    list of your own requirements - they may not be the same as other
    people's, then see if these requirements cannot be accomodated within
    the ALL-IN-1 framework by talking to the ALL-IN-1 system manager(s).    

    Food for thought ?
    
    Jon

Re: last few

Thanks for your response so far.  I have been amazed with this policy 
trying to take DCL away from everyone.  There are real needs for DCL
in order to do programming work.  I really don't mind using ALL-IN-1 
at all.  It is a very good product and I firmly support that we at
DIGITAL use what we sell, BUT we also should have the option if we
are technically competant to be able to use shortcuts in DCL.  It seems
to me that it is insane to fire up ALL-IN-1 in order to do a simple
COPY, SETHOST, DUMP, ANALYZE, and even NOTES to mention just a few.
The overhead of ALL-IN-1 outweighs the "security concerns" of having DCL.  
After all, if the system is managed properly having DCL is no worse 
than having an account.

I came from a system manager position at NASA and found that simply 
separating the tech vs. non-tech users was an easy way for management
to separate who needed what.

Memu, menu, menu is a stupid waste of time.

Regards,

Keith R>
    

This very topic has been discussed at great length in RITZ::UK_DIGITAL 
topic 98 with 95 replies. The topic died soon after the manager of UK I.S.
(and member of the board of management) contributed. Happy reading :^)

Please note UK_DIGITAL will be moving to node GOOGLY later today.

Dave.

    The bottom line SHOULD be that menu driven applications are for
    less technically oriented people OR people that have a limited range
    of system/application needs. Menu systems really are for people
    that do not use computer systems often. The menus eliminate the
    necessity of remembering sometimes cryptic commands to get a simple
    job done.
    
    I support users/programmers/etc. from ALL ranges and found the
    above to be true for most cases. There are always exceptions,
    such as the novice user that starts out with menus but learns
    quickly to the point the menus are a nuisance.
    
    Like all things this issue probably has a tradeoff point. Forcing
    technical people to use menus not only wastes system resources but
    also leads to frustrated people. Conversely, presenting just a prompt
    to novice users can be just as frustrating.
    
    The determination of menus vs command prompt should be driven by
    two things: application needs and user needs.
    
    (Notice I did NOT mention any specific products!!)
    
    							Warren

    re .5
    
    It's NOT that way here in Minneapolis, and I hope it NEVER!! gets
    that way.  I don't think it will get that way here, because I think our
    local management has a good stock of common sense, and I think we're
    good at making the best use of what we have.
    
    re .8
    
    I STRONGLY disagree with your philosophy.  
    
    You say you have little sympathy for those who need REAL DCL access,
    because admin and MAIL machines should be strictly admin and MAIL
    machines.  Functional management should get the proper resources for 
    those whoneed them.
    
    That's a FINE thing to say from an ivory tower someplace, but out
    in the real world, things are quite different.  Out in the real
    world, software professionals borrow manuals from customers because
    the local office has none.  Out in the real world, local specialists
    trade free consulting to customers for machine time because there
    are no in-house DEC resources.  In general, out in the real world,
    our professionals - the good ones, at least - learn to scrounge
    for everything they can get because the formal resources just aren't
    available.  And it is INSANE to restrict what limited resources
    ARE available.
    
    It's EASY to say "Functional management should supply you with what
    you need", it's another thing to wait around for months on end while
    the request goes thru unit, district, area, country, and corporate
    layers of SWS and Finance approval - and then somebody in
    Massachusetts loses the piece of paper with everyone's signature.  
    (Yes, that DID happen to us.)

    Have YOU ever waited months, or years, for a capital request to
    come thru?  Go to your functional management and tell them you need
    a VAX (at about $16,000 internal cost for an MVII with enough on it to 
    do anything) so your local group can access DCL.  See what reaction
    you get, and if you're successful, see how long it takes to actually
    get the stuff delivered.  
    
    And, in the meantime, restrict access by your professional staff to the
    limited resources already available locally.
    
    - Greg Scott, the one from Minneapolis 

    I'll have to agree with the last reply.  I've been with DIGITAL
    for about a year now.  Just this past month I finally got a terminal for
    my desk---a VT100 and a 1200 baud modem.  I don't think the management
    would go for getting additional equipment.
    
    Regards,
    
    Keith R>

    .14
    Greg,
    
    Calm down.  I think if you read .8 again carefully, he (I seem to
    remember .8 was a he.  If she, forgive ME) was NOT saying
    that _he_ had no sympathy with the position of those needing DCL
    access, but that there is little sympathy forthcoming from those
    who have the power to allocate the resources.  In fact, he says
    that he was a holdout from the directives from above that were
    mandating more restrictive measures, and is in sympathy with the
    position of those needing DCL access.
    
    
    
    

    re .-1
    
    Point WELL taken, thank you for pointing that out.  This issue of
    resources and our use of them is something I (obviously) feel strongly 
    about.

    It's the "ivory tower" mentality to which I strongly object, not
    the author's point of view in .8.
    
    - Greg Scott

    Greg,
    
    Believe me, I know how you feel.  Although the machine I'm currently
    on is captive, I'm blessed in that we have a "sandbox" uVAX to play
    on, and I work full-time at  a customer site.  
    
    

    Another thing which .8 doesn't mention is that in the field (where
    stinginess is a way of life) it is very difficult to justify the
    need for computing resources at the field office level.  The
    centralization of ALL-IN-1 mail to area-based machines (*gag*) removes
    one of the only effective justifications for a field office computer.

    Thus, while those offices which already have machines are probably
    safe, as SWS expands it will probably be very difficult for new
    offices to get additional computing resources.  After all, what
    do you need a VAX for besides office automation (i.e. reading mail) ;^)?

re .14

Greg is right, wrong, and overly optimistic all at the same time!  I'm also out
here in Minneapolis.  I believe our "MAIL" machine is (or will be) restricted.
"They" (DIS or somebody) appears to be trying to shove everybody in the district
people onto one 8600 for All-In-1 stuff.  Currently, the machine is so totally
buried that most of the day you can't log in because the login limit is
always exceeded. Its been this way for months.  Thank God we've got microVAX to
forward mail to and for doing program development. 

BTW:  The main reason we got the microVAXen was because it was determined to be
cheaper than keeping up the 11/750 we were using! It took 4 1/2 months to get a
$500 memory board for a microVAX.  And even then it was only because we called
people out East and harassed them every 2 days! 

re -.1

>    Thus, while those offices which already have machines are probably
>    safe, as SWS expands it will probably be very difficult for new
>    offices to get additional computing resources.  After all, what
>    do you need a VAX for besides office automation (i.e. reading mail) ;^)?

Y'all ever hear of "software projects".  That's where customers pay us money to
write software for them!  Its our justification for resources.  I thought
digital was supposed to be deriving a sizable chunk of its software money from
projects rather than being a body shop.  Gotta have computers to do projects.
If we only had machines for reading mail, we might as well work for a customer
with decent equipment. 

Ooooooh, I don't know if I want to step into this.

Officially, we don't have DCL access on our mail systems here in Irvine.

The rationale has already been stated. We area_staff_wienies DO have
a machine to "get work done" (anyone ever need to make a TK50 for a
customer?) And most of the district/branch offices have machines as
well. It's not totally hopeless here.

BUT we have a foresighted SWS Area Manager. The District Managers aren't
napoleonic. The specialists are heard. Even so, it isn't perfect (not
by a long shot) but it's a lot better than many places.

I don't think you have to live in an Ivory Tower to have tolerable
computing resources. But you do have to have up_the_line_management
with an understanding of Joe/Jane Specialist and what they need to get
the job done. And that is (a) another topic and (b) pretty rare.

K.

PS Of course, you could delve into the bowels of ALL-IN-1 and get yourself
a $ prompt without permission. But that would be cheating, wouldn't it? ;^)

   < Note 453.21 by IVOGUS::BARTH "Karl - studying aeroporcine topics" >

< PS Of course, you could delve into the bowels of ALL-IN-1 and get yourself
< a $ prompt without permission. But that would be cheating, wouldn't it? ;^)

  Not to mention that you could get fired for it!  A previous DIS manager
  in our area produced a rather blistering memo on the subject some time
  back about how attempts to beat A1 would be considered terminal offenses
  (sorry, I couldn't resist).
    
  I never really thought about our internal mail system (other than the 
  usual curse words shouted at the terminal when it takes 45 minutes to
  read three mail messages) but I heard a prominent customer of ours
  specifically refer to our internal hassles as a prime reason why they
  never want to see A1 on their machines, ever.  That really opened my
  eyes to how pervasive the effect has become.  Not only is it hitting
  us in the productivity area (remember when we told everyone that this
  was supposed to be a productivity enhancer :-)), but now it's become
  negative marketing tool!
    
  What will we think of next?  Writing all of our mail messages out
  longhand so that an "authorized" DIS person can enter them for us?
  The Shades of IBM methodologies have finally come back to haunt us!!
    
    Geoff

>  ... but I heard a prominent customer of ours
>  specifically refer to our internal hassles as a prime reason why they
>  never want to see A1 on their machines, ever.  
        
        It definitely doesn't look good, does it.  I've semi-flamed
        in other conferences about this, and I agree, in part, with
        both sides.
        
        DIS supports internal mail.  To ease the amount of work with
        the limited manpower they have, they are working at centralizing
        the need for support and maintenance and trying to make the
        systems as similar as possible.  This leads to not having the
        right environment for some people, but it makes sense from
        their point of view.
        
        Resources being limited, they do not wish to encourage
        "non-information" tasks, where "information" tasks are those which
        are internal communications and information processing.  This
        includes Notes, VTX and Mail, but little else.
        
        Customer projects should be done on project machines.  Agreed.
        However, not all coding or "non-information" tasks are for
        customers ... directly.  My personal need for a non-OA machine
        are: 
        
        1) use Notes and VTX... the OA machines (5 of them!!) are too slow
           to be productive.  This is a need which DIS should address,
           but cannot.
        
        2) EDUCATION.  This would be my number one justification if
           anyone would listen.  Field PSS education is poorly organized
           and, though it is being worked on, I don't think it would remove
           this justification.  Education is an ongoing process which
           is best learned by doing than reading or seeing.  I *need*
           a programming machine to try new things which let me solve
           customers problems more quickly, or in some cases, let me know
           something about the product.  This "sandbox" needs to be decently
           configured to run ALL-IN-1, Rdb, RALLY, DATATRIEVE and *every*
           other product I may have a need to learn.
        
        3) (I believe this goes hand in hand with 2) Midnight projects.
           DEC (traditionally) has always supported an environment
           which encourages midnight projects.  I don't think so anymore.
           It's funny that this topic came up when it did.  There is an
           internal tool which saw written by field (SWS) people called
           AVN (Advanced VAXnotes). This tool is a lifesaver to those of us on
           slow network links or without adequate computing resources.  The
           authors of this tool are wondering about it's fate as they are
           losing DCL access to work on it.  I'm positive that this tool is
           increasing many peoples' productivity.  And, in my case at least,
           this is business productivity that is being increased as my job
           requires that I "know things" or, at least, know where to find
           something out. 
        
        If you look back through the replies to this topic, the people
        who are unhappy with the situation are Software Services. 
        F&A, Personnel, etc. don't need more than an OA machine.
        Engineering has what they need.  Not surprisingly, my manager
        is not unsympathetic with me.  It is just he is not given the
        $$$ to buy a group sandbox and his management cannot find the
        justification to hurt the short-term bottom line.  Actually
        I shouldn't complain.  My group now has thing machine I'm writing
        from as a sandbox.  Unfortunately, it is terribly underconfigured
        for the people on it.

        Finally, some questions I have regarding the ways things are:
         Why must we learn on our customers' time?
         Why must we use technology older than our customers?
         Why must we have centralized processing when we sell
           distributed?  (Work group computing?)
        
        Sigh...

re .14
     OUCH! that hurt Greg!! I really wish you'd have read my note
    carefully before burning me at the stake. First off I sure as h*ll
    don't live in an IVORY TOWER somewhere. I was just stating the facts.
    I do SUPPORT the idea that SOME people require DCL to enhance and in
    fact do their jobs. If this were a perfect world you should be able to
    state your case for your business needs and receive a fair and timely
    response from your functional management. Situations are different
    everywhere. As a DIS manager I found getting system resources was
    infinitely easier than getting the human resources to support them.
    After all DIS is an "overhead function." It took TWO YEARS to get
    through a req. to add ONE network support person for a 13 site network
    stretching over 300 miles end to end. Now we have a network support 
    staff of TWO!

re .14 & .19 Greg & Jim - 
    Management in this company or any other will never listen to vague or 
    emotional cries for" DCL to do my job" without objective well presented
    business reasons for doing so. Obviously, even very sound well
    presented reasons still may not produce the desired results. I believe
    there ARE sound business reasons for providing DCL resources for SWS
    and others who must deal with customers who have that capability. How
    can anyone expect to support customers on new products, services,
    and/or features when they are not permitted access to them in their
    internal work environment?

Lastly .23 - 
    You have hit on the very center of something I've been stating since
    I became a District DIS manager - Why are we centralizing when we are
    selling our customers distributed processing? I must admit a very
    personal bias since district DIS in the MAA is to be reorganized into
    oblivion by Q1. All internal production applications are moving
    toward the MENU captive account mode of operation. Are we selling
    this as the panacea to our customers as much as we seem to be selling
    this to ourselves as a corporation?

TO ALL - Sorry about all the soapboxing - BUT THINGS IS TOUGH
ALL OVER!

-Terry {~}{~}

	This note re-afirms my goal of never leaving Engineering again.
	I'm not trying to push mud in anyones face but I honestly don't
	have enough time in the week to properly utilize all the computing
	resources I have at my fingertips..  

	From the FWIW Dept. Here in LKG (home of Networks), we have
	only two people to manage our network too.. And 5 system managers
	to manage systems (50?) for approx. 1000-1200 accounts!  Yea, things
	ARE tough all over..

							mike

    I believe that taking a decision to restrict DCL access on ALL-IN-1
    machines totally misses one of the fundemental reasons why customers
    buy ALL-IN-1 in preference to IBM's PROFS or WANG's OA products.
    ALL-IN-1 is not what comes out of the box when you receive a tape
    from SDC; it is what you - the user - makes of it. In short, make
    each user more productive by providing them with the functionality
    that they require to do their job. 
    
    Some customers do restrict access a la DIS. I would submit that
    they are not the truely successful users of ALL-IN-1. They have
    completely neglected their opportunity to make full use of this
    wonderful product. It is no credit to DIGITAL that we follow this
    restrictive line.
    
    Tony

    I am in Software Services just as others replying to this note.
    
    In the past I have also had to scrounge many resources...from cables
    and manuals to modems and computer resources.  It is REALLY getting
    old trying to fight for the resources to perform the job as it was
    explained to me when I first came to Digital two years ago.
    
    The first resources to be removed were manuals and ALL internal
    publications.  Then our VAX became an ALL-IN-1 machine and their
    were rumors of removing DCL privs (we were able to keep them, but
    as Keith has noted, they are about to be taken away for real). 
    I now find myself using one customer's resources to get the job
    done for another customer.
    
    Sometimes I feel like giving up and just saying we cannot do the
    job.  However, I still care too much for the customer's business
    needs to let 'Digital' get in the way of itself.
    
    As for learning about new products, etc, I only hope that I can
    get on a customer site that has some of the newer products and has
    dial-in capability so that I can learn at night.
    
    Speaking to Deaf Ears,
    
    Pat

    Restricting access to ONLY ALL-IN-1 is a good way to maintain empires.
    Maybe JEC will help us out, but there are a lot of 'service' people
    out there managing and supporting people that really don't need
    the level of support they are being given.  For example, the corporate
    mail people have how many people supporting that mail system?  I
    don't know but assume it's a lot.  And, the revenue of funny money
    the receive is in the 10's of millions.  It helps their empire to
    force people to use their expensive mail system rather than the
    'free' one network aware people use.  Same with the ALL-IN-1 issue.
    There are people paid to maintain those menus and plan the service
    levels.  They depend on numbers, and those using DCL threaten their
    budgets.  Go buy a cheap apple with alisa DECnet and be a node!
    
    bill

    Thanks for all the responses so far.  I have taken the liberty of
    extracting some of them (and as I promised NO names, addresses,
    etc.) and have forwarded them on to the person who is spearheading
    our attempt to keep DCL.

    Will keep you all informed as to our progress.
    
    Keith R>

    I hate to be the bearer of bad tidings, but here is the announcement
    that we receive on our F&A "mail" machine (names have been changed)...
    
--------------------------------------------------------------------------------
System USSCSL. Unauthorized access is prohibited.

Username: BAY
Password: 

    Property of Digital Equipment Corporation; for internal use only.

    This is VMS V4.5 (CVMS V2.2).

 ACCESS TO DCL will be terminated as of 3/31/88 per NEADIS MAIL POLICY.  
 The following utilities WILL BE  available in ALL-IN-1:
 
 VAXMAIL		DECgraph
 DECslide		ELF (employee locator facility)
 DECalc		PHONE		
 VAXnotes		Show Users	
 Videotex
 
 Please notify mumble or mumble if you have an application 
 that needs to be incorporated into ALL-IN-1. 
 To return to the menu type MENU
--------------------------------------------------------------------------------

    I contacted "mumble" and requested that Kermit be added to the list. I
    was told that strict guidelines permit only certain applications to be
    added and that Kermit was not one.  I have heard rumors that the "CVMS"
    above stands for something like "Corporate VMS", a preconfigured VMS
    subset designed specifically for OA/Mail application environments. 

    As for "$" in A1, well that was never turned on in the first place.
    
    To say that this is an alarming trend is to make the understatement
    of the year.  What exactly are we supposed to use for resources
    to keep up our expertise?  When I go to a customer site, and am
    deluged with questions, I continually must apologize that the customer
    knows more than I do, despite my $90/hour consulting tag.  When
    I am asked to do presentations on software, it is extremely difficult
    when the software isn't on the machine and documentation isn't to
    be had.
    
    Why is it that the needs of programmers and engineers are so well
    understood internally, but the same company can't recognize the
    same needs in similar jobs just because they happen to be field
    positions?  Why is it implied that technical expertise is not required
    for dealing with customers?
    
    And worst of all, why does my district, as totally unsatisfactory
    as it seems to me, appear to have more going for it than most? 
    We have lost DCL on our mail machine, but we have a LAVC with a
    785 and two MVIIs that are solely used by software services.  Believe
    me, this little cluster (10MB on the 785) cannot support 125 software
    specialists!  And yet, It would appear that we are blessed!  We
    all have privs, we all have DCL, and it is not unheard of to do
    software installations from home.  
    
    I have heard of districts (which will remain nameless) that don't have
    access to the Enet AT ALL!!!  When a friend attended a training session
    recently, the instructor volunteered to send him a program in the mail.
    He gave the instructor his node name, but the instructor stated they
    didn't have electronic mail in thier district, and that she meant she
    would send a hardcopy in internal mail!
    
    I believe that the Enet is one of the greatest corporate assets
    any company has ever had.  I believe we have the best products in
    the computing industry today.  I am damn proud that I work for Digital.
    
    Is Digital ever going to show me how proud it is of me????

    [RAY OF HOPE - There is a rumor that the recent MANDATORY Workstation
    training that EVERYONE in my district (including secretaries) had to
    attend is the first step in a grand plan to put a VAX Station on
    everyone's desk.  Of course this rumor went around when the PCs
    were announced, but I think it is strategically more logical to
    put a true DEC product on everyone's desk rather than a PC clone.
    Keep your fingers crossed (since you don't have a keyboard anyway) ]
    

        Re: .30 (and others)
        
        What would happen if you documented each time that you couldn't
        answer a customers question because you couldn't get experience
        with a piece of software without access to DCL, and presented
        the documentation to mumble and your manager? 
        
        Would that encourage your manager to work to get you DCL access,
        or doesn't logic apply in this case? 
        
        					B.J.

Do you *really* want DCL access?

From Notes, enter EVE or TPU - you can then spawn DCL. From some reaon,
it's the only utility where a spawn works - it doesn't from VAXmail.

We're lucky - we have a local machine with DCL access. However, the last
"new" ALLIN1 release from Atlanta accidentally deleted VAXmail from the
menus - you had to use the above loophole to send anything (there's a
new VAXmail import command in the EM menu for reading inbounds).

Eric

>From Notes, enter EVE or TPU - you can then spawn DCL. From some reaon,
>it's the only utility where a spawn works - it doesn't from VAXmail.

Fixed in next release.

I'm in the Columbus, Ohio Data Center. I am part-time system manager and
part-time network jockey. I've seen the entire life cycle of this 'corporate
mail/office automation machine' business so I'll give you my 'view of
history':


  Once upon a time there were various and sundry machines both in the field
  and in corporate (plants and mfg.). Those machines in the field weren't
  networked to the machines in corporate (much).
  
  Let's concentrate on the field machines.  Various groups owned and managed
  them, but typically it was Software Services. The SWS folk happily used the
  machines for development and demos.  System management was usually done by
  one of the SWS folk that had an inclination for that sort of thing. Life
  was fine.

  Then came more networking. Corporate began to push the idea of one big happy
  network (Easynet) that would tie field and corporate systems together. Once
  this was established a better corporate mail system could be formed to
  replace the current system which consisted of EMS (mail-only hubs) and RCS
  (Digital's private TWX network).
  
  The SWS folk in the field were eager to become part of this big happy
  network- SWS specialists could copy s/w easier and the SWS managers wanted
  to be able to use a better mail system that the awful EMS system. So many of
  the SWS systems (VAX 117xx class machines) took on mail node duty as well as
  the development/demo duty they had been doing. The system manager supported
  this additional mail functionality. As the systems took on this new role of
  a mail node the number of user accounts increased- now sales and fs managers
  needed accounts on the systems as the EMS systems were being phased out.
  
  About this time there was a shift in what SWS folk were doing to make money.
  Traditionally the SWS folk in a field office were experts in various
  operating systems and products. They would take problem calls from the
  customers at their desks and install the stuff on customer sites. But the
  wave of the future for SWS was now consulting... making bucks on the
  customer site instead of in the office. The SWS machine now gets the
  additional workload as a tool to help prepare proposals and project plans.

  The SWS manager now had budgets to meet... pressure was on to get the
  available staff onsite at the customer's place to bring in $$$, not to sit
  in the office and manage an internal mail system (this activity was
  'unproductive'). Meanwhile corporate DIS (who had been given the task of
  building this new corporate mail system) was hearing about the erratic
  service that mail users were experiencing- poor support, erratic system
  availability, non-standard product set (one system might be running latest
  VMS and mail version, another site running a real old version).
  
  Corporate DIS reacted to this situation by mandating that DIS should operate
  and manage the all mail systems... there needed to be standardization and
  consistancy so the users wouldn't get so confused. Many of these users are
  now 'non-techie' types that have no interest in DCL and have no idea what a
  layered product is- all they want to do is read their mail and edit
  documents.
    
  SWS managers by now were happy to turn the operation of the mail system over
  to someone else (DIS) so that their people could be out making budget $$$
  instead of supporting internal stuff like mail. {Do you see what has occured
  here? The system that used to be a demo/development machine in the SWS
  specialist's eyes has become a 'mail machine' in the eyes of DIS and SWS
  management. An important distinction.}
  
  Now what used to be 'SWS' machines are 'DIS' machines. DIS is concerned with
  mail. The offical mail product is ALL-IN-1 mail, therefore the DIS machines
  also tend to offer OA (office automation). DIS is also responsible to
  support some of the internal applications that deal with things such as
  order entry, accounts payable, etc. DIS therefore wants to standardize and
  limit what it supports... thus the removal of DCL at some sites. Headcount
  is scarce- making support (i.e. handling user questions about how to use as
  well as actually supporting the product on VMS) difficult. Remember, most of
  the user base is now non-technical and tend to need more support resources
  that when the user base was mostly SWS DCL jockeys.
  
  A standard set of VMS and layered products packaged by US DIS is called CVMS
  (Common VMS). Various CVMS 'environments' (office, production, development)
  contain different sets of products. Various sites interpret how strictly
  they must adhere to the product set of a particular CVMS environment. {Here
  in Columbus we use the 'office' environment as a base set of products and
  add products that our users need... we don't currently have access to DCL
  cut off.}

  Now we arrive at today. The individual in SWS still needs a machine that
  they can 'exercise' and hone their skills on. They still need a machine that
  they can copy savesets, write small programs, read tapes from a customer
  site. They need a system to prepare proposals and documents on. Hardly
  anyone has come out and said 'the mail machine isn't supposed to be for
  this anymore'. SWS management has either assumed that the mail machine will
  still provide all of this _or_ has assumed that the SWS specialist will get
  it done on the customer site (hah!).
  
  At some sites local SWS mgmt wisely allows various SWS systems to exist
  becuase they know that the mail machines are no longer SWS machines... but I
  get the impression that SWS mgmt higher up takes that view that local
  machines require someone to support them- if local machines don't exist then
  those people can be out at a customer site being productive.
  

I guess to wrap all of this up I'll say that the SWS specialist is left
holding the (empty) bag- the machine that used to be his/her everything is
becoming a DIS mail machine with a limited offering of products and commands.
This is a realistic thing for DIS to do (narrow their offerings to provide
better support for what's left) considering current staffing restrictions.

SWS mgmt needs to undertand what computing a SWS person has need for, then SWS
mgmt needs to figure out where the SWS person can obtain that resource. SWS
mgmt may not be fully informed that the traditonal source (what is now the DIS
mail machine) is not going to provide what they used to.

Does this help any?
  
  Lee

    A very good reply.  The transition if you want to go back to the
    early 70's starts with sales: they acquired and operated the systems!
    Or rather had prioritized their use by OEM's, end users, and Software
    Services (pre-PSS days).  Why you could think of it as a stone age
    ACT with PDP-8's with OS/8 and PDP 11/20's with DOS-11.
    
    Software Services eventually got staffed up to have one person in
    each sales office, and gradually took over that function.  Along
    the way we got into the "timesharing" business and today we have
    managers for field-based computer centers.
    
    The are two scarce resources that need to be managed and depending
    on what year we're talking about concern over one overrides the
    other:
    
    (a) System Management, ie humans who'll keep the system functioning.
    (b) Response time, ie processor load.
    
    The no-DCL policy, I think, is more of a way to manage response
    time.  Why aren't they even more systems?  Who's gonna pay for them
    and who's gonna to pay to get them managed?  "With response time
    already this poor...how can we afford to let 'them' access DCL?"
    I imagine is the way the story goes.
    
    In fact, if there was a way to limit all users to one command "READ
    MAIL" between 9AM and 12 Noon and a way to enforce a maximum speed of
    1200 baud on the terminals, I'd think that would be given serious
    consideration. 

    
    Working for VAX/VMS Development I'm as far from "the field" as one
    can get, but I can't understand the reasoning behind not providing
    the tools somebody needs to perform their job.  What does a typical
    hour of an employee's time cost Digital?  $40?  $50?  How many hours
    does it take to equal the cost of a $5000 workstation?  Not many.
    
    That doesn't sound like the Digital I've heard about...
    
    							Rich
    

    It appears that this Notesfile (or at least the entries with glaring 
    acronyms like NEADIS) is highly visible.  It seems likely that my 
    previous reply may not have been taken as intended and I would like 
    to clarify it...
    
    After reading the history in .34 one can understand why systems that 
    previously allowed SWS people to have DCL access, etc. may no longer 
    do so.  And its not hard to understand why strict policies must 
    govern what software is available.

    What I heard in previous entries is that most folks don't have access 
    to any other computer resources besides the ones being dedicated to 
    mail service.  When I said that "this" is an alarming trend, I meant 
    that the "big picture" is alarming.  I am not concerned that 
    particular machines are no longer allowing DCL access, but that the 
    genreral amount of compute power in the field available for 
    development, testing, systems work, etc. is growing smaller and 
    smaller.

    I am a software specialist, and I have a problem.
    
    There seems to be an understanding that electronic mail is essential, 
    not just convenient, to Digital, and it appears as if attempts are 
    being made to make electronic mail available to all DEC employees.  
    There is still much to be done, since there are those without access 
    to electronic mail.  But as long as the goal is electronic mail for 
    everyone, then mail is not the problem.
    
    Those charted with supplying mail have hired people to maintain the 
    mail systems.  I liken these people to pony express riders who have a 
    thankless task, numerous obstacles, but make our communications 
    possible.  These people are not the problem.
    
    The problem is based on a crucial premise - that SWS people are 
    programmers in disguise.  SWS people perform many duties - customer 
    contact, proposal and requirements writing, consulting, analysis, 
    etc.  But the one thing most have in common is the background, 
    ability and desire to work with and program computers.
    
    However, as the history in .34 highlights, somewhere along the way 
    some essential planning was not done, some dynamic situations were 
    assumed to be static, and the ball got dropped.  I am talking about 
    the fact that no one has paid attention to the fact that programmers 
    NEED access to computers to do their jobs, to learn, to test, to 
    grow, to be satisfied.
    
    Electronic mail is essential to Digital.  Electronic mail machines 
    are production systems, and there is no room on those machines for 
    software development, etc.  I would go so far as to sanction the 
    "READ MAIL" command between 9 and 12, as opposed to having to wait to 
    read my mail because someone is running a spreadsheet.
    
    But when it is time to hone my programming skills, the ones I was 
    hired for, the ones I use everyday and depend on and use to make 
    money for Digital, I need access to compute power and the richness 
    of the environment that the VMS operating system provides - not some 
    menu interface designed for non-technical, non-DP users.
    
    Speaking for myself, and I think for others as well, I find a lack of 
    computing resources to be frustrating, depressing, and to have a 
    negative impact on my ability to do my job.  What makes it more 
    frustrating is to work for the second largest computer company in the 
    world, and to have to admit to my customers that Number Two doesn't 
    consider it a priority to supply their software people with the one 
    critical resource that Digital has in abundance - DEC computers!
    
    SWS is a business.  We do not run on handouts.  I believe that most 
    districts lack compute resources because it is incredibly difficult 
    to justify those resources.  Managers cannot make numbers by 
    "wasting" money on expensive equipment.
    
    That is why I believe the problem is not with the districts, but with 
    how the districts are administered from above.  Every district has 
    office space, typewriters, copiers, coffee machines.  Sales people 
    have Voicemail and Cellular phones.  Most field people have company 
    cars or a travel allowance.  The company sees to it that every single 
    need of every single person is catered to.  Except for the 
    programmers.
    
    Somewhere, someone realizes that programmers need computer resources 
    because our software engineers do not want for hardware resources.  
    Software is their stock-in-trade.  Why are field personnel treated 
    different?  Expecting software people to work without access to 
    computer resources is like asking Sales people to work without 
    telephones.  Or like asking software engineers to work without 
    computers.
    
    I believe that SOME of the problem can be attributed to the local 
    districts.  When numbers are not being met, it is difficult to go to 
    higher management asking for new computers.  But this is the short 
    term view.  The long term veiw is that it is hard to meet numbers 
    when your people spend 2/3s of their time wearing themselves out 
    scrounging resources.  
    
    It is the job of higher management to consider the long term veiw.    
    I truly believe that attrition of good people could be curtailed and 
    employee satisfaction could be greatly increased (which leads 
    DIRECTLY to increased customer satifaction) if the needs of the 
    programmer in the field were understood and addressed.
    
    The second largest computer company in the world should be able to 
    guarentee at least a token amount of computing power to all their 
    programmers, whether internal or in the field.
    
    At great personal risk, I will venture a guess as to why hardware 
    resources get a low priority (besides the financial ones mentioned 
    above).
    
    Some people want to program, and some people want to manage.  The 
    point can be argued that most managers have little interest in 
    technical areas, or certainly, much higher interest in other areas.  
    Those interested in management, whether from a technical background 
    or not, are not of the same stuff of those that are NOT interested in 
    management and choose to follow technical career paths.

    Therefore, it is a catch-22 - RARELY will someone who truly 
    understands the "techie" point of veiw ever be a manager since that 
    type of person will never want to become a manager.  And it will 
    always be difficult for someone who would rather manage than program 
    to understand how important computer resources are to people like 
    myself.  I believe that havimg come from a technical background may 
    even make it harder for a manager, since his/her background may give 
    the manager a false sense of empathy ("Hey, I understand.  I used to 
    do that too, y'know").
    
    Most software people I know aren't overly interested in the rewards 
    that sales people (and managers) are attracted to.  Rather than a 
    dinner or a trip, they would like a terminal/PC at home, 2400 BAUD 
    dial-in capability to a healthy VAX at the office, privileges 
    sufficient to do their jobs, software, documentation, a technical 
    class to learn new skills, etc.  So that if they DO get a free 
    vacation, they feel good about it, and look forward to going back to 
    their jobs afterwards, instead of looking at it as a brief respite.
    
    A developer in a class once said to me how wonderful I have it, 
    since I have a free company car.  I told him that if I had wanted to 
    drive for a living, I would have become a trucker - and that I would 
    trade my Taurus for his VAXstation anytime (I have never worked with 
    a VAXstation - I have only seen them.  When customers ask, I refer 
    them to the sales people - no testimonials here).
    
    I would give ANYTHING if the company I work for said to me (in a way 
    that is important to ME) that they consider me just as important a 
    resource as their software engineers.
    
    But I'm not holding my breath...
    
    --------------------------------------------------------------------
    
    re .31 - I let my manager know in NO UNCERTAIN TERMS when my ability 
    to do my job is impacted.  I have seen little (not zero) response 
    (apologies to whom it may concern).
    
    re .32 - I'm sorry, but the ability to "work-around" a problem is NOT 
    a solution.  Thanks for the tip - I still want the real thing.  BUT, 
    as noted above - NOT on the mail VAX.
    
    re .34 - Excellant summary.  Thank you for taking the time.  It clears 
    up several things.

    re .36 - I've only heard rumors of your "Digital".  I was with DEC for 
    two years before I ever attended a training class. Three years before
    I received a doc set.  A girl in our group came from engineering 
    because her husband transferred to Connecticut.  After six months, her 
    reaction to being in the field was classic:

	"When I was in engineering, it was like a family.  Here, it
	seems so isolated." 
    

           Reality from my point of view(as a software specialist
           working in a FAC"Field Application Center") is
           that the future of SWS is not programming!
           
           The rumor is that new projects will have coding done
           by subcontractors.
           
           Also note that installation are now done by Field
           Service.
           
           So I see my job as changing from a "Jack of All
           Trades" application designer,builder  and VMS problem
           solver to a report writing consultant.
           
           If all I do is write reports, then a MACintosh is
           all the computing power I need(maybe a network
           link to see what new 3rd party packages corporate
           has signed agreements with).
           
           So in the long term who needs DCL?  Maybe outside
           contractor who can hire programmers to write code,
           but not me I am now a "wordsmith" consultant!

re: .36

Believe it, my friend.  The Field is probably the only place in DEC where
sole possession of a VT100 is still a status symbol in some locations. I
consistently bring in $100+ per hour for the corporation, and the only
resources provided to me are a mailbox and access to a cluster that is
located 120 miles away.  

There have been some improvements.  Connecting district DIS computers to
the Easynet 3 years ago was a landmark event.  But the basic complaints
are still there.  All the skills a PSS engineer acquires in my neck of
the woods are done with customer resources.  If you are lucky enough to
work for a trusting customer with state of the art equipment, great.  If
not, too bad.  Maybe you can learn something at your annual week at 
training.  If that happens to be something like VMS internals, don't expect
to use any DEC machines to sharpen those skills on when you get back.

I sympathize with those who are so vocal on this issue.  But the bottom line 
is that consulting stinks.  It always has, and it always will.  It is NOT
the caring, nurturing environment that most have come to appreciate as DEC.
I could relate numerous war stories here - suffice it to say that one needs to 
develops a thick hide quickly in order to flourish or even survive.

The nature of SWS business is moving away from the delivery of specific 
technical skills, as someone else already pointed out.  It is a very sad thing  
to see, but we lure technically competent people into the field all the time
and then turn them into salespeople.  Not that there is anything inherently 
wrong with sales, it's just that one jumps at an opportunity to come work
for DEC as an engineer, only to find out after a year or two that technical
excellence is NOT the key to career advancement in the Field. 

Hmmm, enough rambling.  I guess I see the lack of commitment on the part
of SWS management to resource availability not as an isolated problem, but
as indicative of the very nature of the business.  Unless SWS changes
drastically, the problem is not going to disappear.

/Al

    If technical excellence is no longer the way to advancement in the
    field, then I say DIGITAL deserves what it will get.
    
    I bring 26 years of experience in the computer business (counting
    education, working in university and business arenas, and nearly
    12 years in DIGITAL, over 8 of them in Central Engineering. My current
    job classification is Senior Software Consultant (who knows what
    JEC will do to it) and I report to the manager of the Office and
    Publishing Applications Center for Engineering and Support, part
    of SWS/Engineering. My main contribution to this company is and
    has always been TECHNICAL EXCELLENCE.  I work my tail off to provide
    things that specialists can sell/provide to customers. My organization
    takes seriously the idea of serving our "customers", ie. you
    specialists in the field, through programs such as ASSETS, continuing
    to push/pull ALL-IN-1 developement, etc.
    
    How does upper level management think our budding "consultants"
    are going to get their education? A consultants base of knowledge
    turns over at a ferocious (sp?) rate.  If you could attend frequent training
    courses, seminars, trade shows, etc., you might keep up with what
    is going on in the industry.  But, how about what is going in inside
    the company? If you aren't "connected" (pun intended), how you gonna
    find out? 
    
    The system is the network is the company message, and we can't seem
    to do a good enough job of "use what we sell".  I'm tired of hearing
    about managers that sluff off buying capitol equipment because they
    can't see justification for helping their bottom lines.  This in
    "infrastructure" maintenance we are talking about, decay in the
    internal framework and support environment for some of our most valuable
    personnel, not to mention their morale and well being. We're talking
    about the productivity rates of people whose salary and support
    costs to the company are an order of magnitude each year above the
    once in 5 years cost of the equipment they ought to have access
    to.
    
    We ought to, as a company, have the management guts to say we are
    going to put our money where our mouths are and show our customers
    we believe in our own hardware, software, sales hype, etc. to use
    it ALL OVER THE PLACE inside the company, whether in central
    engineering or out in the field.

    Now, I happen to be in an organization that has engineering as part
    of its title, so we fortunately are getting good backing and support
    from our funding sources.  But I am concerned because so many
    of the people who are supposed to be using what we produce are having
    such a hard and discouraging time trying to.
    
    jack

    

   Re: .40
    
         I was contemplating adding to this topic recently (I've had
    a few years at DEC myself) but the last entry says everything better
    than I ever could. WE SHOULD HAVE OUR OWN STUFF ALL OVER THE PLACE.
    
    Wake up managers!! People out in the field are NOT just numbers
    or number producers. THEY ARE ASSETS. Long term ones if MANAGERS
    do their jobs right. I know I'm biased pro-DEC but even if I TRY
    to think objectively I know DEC should be "USING WHAT WE SELL"
    everywhere there is a person doing a job.
    
    I'll stop here because I tend to ramble once I get started and
    I certainly could here.
    
    Again: Mr. Bouknight has the right ideas. LISTEN TO THEM. DIGITAL
    would be 5 times where it is today if some of his ideas came true.
    
    							Warren
    

I am in SWS in the field.  I have a mail system with newly captivated
accounts.  And I have no problem getting DCL access on other machines.

In fact, this machine is available to me, since it does not handle our
mail.

The whole tone of the replys I've been reading have me concerned... and
thankful.

I am concerned because my company has high level software consultants using
one customers resources to delvelop solutions for another customer!  This
is a violation of company policy!!!   It should cease immediatly and be
reported to management.

If we have SWS people out there who need resources to provide customer 
solutions, nd are not getting them, then it is your responsibility to use
the open door policy to get what you need to do your job!  If your immediate
management is not providing you with resources, because of the possible
negative effect it may have on their numbers, then their manager should
know this!

This is not a healthy situation for Digital.

The reason for making the Corporate Mail Systems captive to ALL-IN-1 is
obvious and straightforward... response time for essential business
communications cannot be impacted by software development. Period.

At the same time, essential software development cannot be impacted by
a few shortsighted managers who are only concerned with _their_ numbers.

They need to refocus on Digital's numbers.

Having come to Digital from a competitor, I can tell you that it is much
easier to get resources here at Digital.   

Management in my district has the foresight to understand that the best 
consultants are able to address the customers needs at all levels, and
provides us with the resources to do it.   We achieve customer satisfaction,
employee satisfaction, and technical excellence, because we have been 
provided with the resources to do it.

If this is not the case in your organization, then you are being mismanaged.

If your local management has "deaf ears" ... then it is in the interest of
the corporation that you document your concerns and pass them on to a level
of management that WILL listen.

Under no circumstances should we be using our customers resources for 
development of solutions that are not for _that_ customer.

For this company to be #1, we cannot have "deaf" managers at any level!

Bob Deep

RE:  < Note 453.42 by MISFIT::DEEP >

>I am concerned because my company has high level software consultants using
>one customers resources to delvelop solutions for another customer!  This
>is a violation of company policy!!!   It should cease immediatly and be
>reported to management.

    Reported to management?  This kind of activity is _encouraged_ by
    management. 

>At the same time, essential software development cannot be impacted by
>a few shortsighted managers who are only concerned with _their_ numbers.

>They need to refocus on Digital's numbers.

    Hah!  People will behave according to how they are rewarded.  Managers
    in the field are _not_ rewarded by how well Digital as a whole does;
    they are rewarded _solely_ on how good _their_ numbers are. 

>Management in my district has the foresight to understand that the best 
>consultants are able to address the customers needs at all levels, and
>provides us with the resources to do it.   We achieve customer satisfaction,
>employee satisfaction, and technical excellence, because we have been 
>provided with the resources to do it.

    Congratulations!  You are in a very enlightened district.  As was noted
    in earlier notes, the character of SWS is changing.  Apparently, we
    aren't programmers anymore and don't need the resources that
    programmers need.

    RE:  < Note 453.42 by MISFIT::DEEP >

>I am concerned because my company has high level software consultants using
>one customer's resources to develop solutions for another customer!  This
>is a violation of company policy!!!   It should cease immediately and be
>reported to management. [spelling and puncuation corrected from orig.]

    I don't know who "management" is.  Normally one speaks of a Unit
    Manager or a District Manager, or an individual.  When someone
    says "management", I think "rank and file" and start thinking what
    a fine shop steward or local president I'd make.
    
    As for using one customer's (A) "resources" for another (B), that's not
    only not a "violation of company policy" (which company? which policy?
    A, B, or Digital) but I concur that it is rewardable behavior if
    done with the acquiescence of A.

> Management in my district has the foresight to understand that the best 
> consultants are able to address the customers needs at all levels, and
> provides us with the resources to do it.   
        
        In Chicago, most consultants get all the resources they need.
        Specialists do not.   What hurts is that the specialists are
        not provided the resources to learn with so that someday they
        too can become consultants.  
        
        Fortunately, this is not entirely true in Chicago, but it is
        VERY true in some other places.
        
       _Mike

    
    I think that there is a serious misperception here that this is
    a problem with local SWS management.  It is not.
    
    In all three of the districts that I have contact with, the District
    Managers have the good sense to listen to their District Consultants
    when they tell that there is a problem.  And the consultants out
    here have been saying that there is a problem for years.  I have
    seen many District Managers try to do something about this and get
    almost nowhere.  The Districts simply do NOT have enough money in
    their budgets for training, documentation, AND hardware.
    
    I suspect that it is widely believed that how much we spend here
    in the field is tied to how much we sell.  It is not so.  Our expense
    budgets and our revenue budgets have essentially nothing to do with
    each other.  Furthermore, it does not matter how much over our revenue
    budgets we manage to make, our expense budgets can NOT be increased
    before the next year, and these are the things that a manager is
    measured on.
    
    At a higher level, I suspect that an Area Manager might be able
    to do something if they cared, or if they where told by enough of
    their technical people that there was a problem.  However the Area
    Headquarters are always better equipped than the other field offices
    and the Area Consultants always get the lions share of that equipment
    (read VAXstations, for which any field person would kill) so they
    probably do not perceive any problem.  The real problem however
    is probably further up the chain.  Like in Country and Corporate
    SWS management.  These folks are so far removed from the problem,
    and so well taken care of themselves I doubt that even realize that
    their is a problem.  
    
    Further, I am becoming increasingly convinced that management at this 
    level just does not understand the nature of their business out here.
    Either that or they do not care.  An open door policy is fine but
    I could not even tell you where the correct door IS for this problem,
    let alone whose name would be on it.  Sometimes the managers should
    come out of their open doors and ask the people in the trenches
    just exactly what the barriers to productivity are.
    
    --  Barry

    Every other year or so, a nationwide survey called Interact goes out,
    in which field employees are selected by the final digit in their
    social security number to fill out an anonymous questionaire whoch
    is supposedly used to "take a pulse" on whats happening out here.
    You would never believe the "to-do" that goes on over this.

    Good idea, unfortunately, it is ignored.  The first year it came out,
    we had a district meeting to announce the results.  One U.M. addressed
    the district and dealt with the lack or resources as follows: 
    
    Item "x" on the survey shows that SWS field personnel have indicated
    they do not have the resources to do their job.  Well, we know WE
    don't have that problem.  The next item..."
    
    Last year we had another survey.  We filled 'em out, sent 'em in,
    and no one has heard anything about them since.
    
    Re .46, TOTAL AGREEMENT!  WHO'S door is open to WHOM?
    

    Actually, I know in NY Ed. Services, based on the interact survey
    Personnel met with everyone, analyzed the results, and based on
    the survey and the meetings, changes were made.

    re: .48  "Interact reaction"
    
    In our Area, we got a nice letter from the Area staff thanking us
    for our participation in the Interact survey.  Oh well ...
    
    re:  "Open Door Policy"
    
    Wandering into an upper-level manager's "open door" without first
    checking to see if that manager is part of the problem might lead
    to you being shown to the "front door".  It's happened before ...
    
    This may sound cynical, but field management really doesn't have
    a whole lot to gain by making their technical people educated and
    efficient, for a variety of reasons.  For one thing, a trained
    technical person has a lot more career freedom outside of his
    unit that way, which leads to staffing problems for the unit
    managers, even if it does benefit the company in the long run.

    
    Geoff

RE: < Note 453.44 by SDSVAX::SWEENEY "Patrick Sweeney DTN 352.2157" >

>    I don't know who "management" is.  Normally one speaks of a Unit
>    Manager or a District Manager, or an individual.  

 Let me make it clear for you... Management, to you as an employee, should
be that part of DEC that begins with your immediate manager and ends with
Ken Olsen.   You should notify each, in turn, as necessary, of any impropriety
that could result in the loss of customer to Digital.  Its called "Doing the
Right Thing"


>    As for using one customer's (A) "resources" for another (B), that's not
>    only not a "violation of company policy" (which company? which policy?
>    A, B, or Digital) but I concur that it is rewardable behavior if
>    done with the acquiescence of A.

I was refering to Digital policy, although you will find it is a violation
of policy in any major corporation to use its computer resources for the 
development of applications for an outside interest, hence it is unlikely
that the behavior would be considered "rewardable."

    re .49
    
    Another interesting thought about vested interests of "management"...
    
    If a manager has a senior level person, doing senior level work at
    associate level pay, the manager's margin is increased.  "Margin" is
    THE number for the field.  The longer the senior level person takes to
    get up to the salary s/he deserves, the longer the the manager has a
    high margin earner in his/her stable. 
    
    This would apply for promotions, or even movement through the salary
    range.
    
    If JEC seeks to resolve this type of thing, then it certainly has
    a noble goal.  Does this happen?  Will JEC stop it if it does?
    

    Re: .52
    
    >If a manager has a senior level person, doing senior level work at
    >associate level pay, the manager's margin is increased.  "Margin" is
    >THE number for the field.  The longer the senior level person takes to
    >get up to the salary s/he deserves, the longer the the manager has a
    >high margin earner in his/her stable. 
    
    This is not quite correct from what I have seen: most
    Time-and-materials contracts specify that a level X person is $YYY
    per hour.  Thus the higher the level of a specialist, the more we
    can charge for them.  Of course if you're at the bottom of your
    pay range, the margin does look rosier...
    
    To get back to the discussion of computer resources for a bit, a
    thought struck me while reading over this discussion:  there seems
    to be a difference in perception between field software specialists
    and some level of management consciousness.  Most Software Specialists
    in the field regard themselves to be software engineers.  From what
    I have seen, we are regarded as glorified salesmen by those who
    decide how assets should be allocated, and given computer assets
    accordingly.  At one time this may have been true, but I don't see
    a whole lot of difference between the work that I do and Engineering
    work with the exception that my work is largely custom, and I must
    be prepared to work in any language on any sort of software at any
    given time.  I do not have the luxury of working with one toolset
    and on one product for a span of years.  When working onsite at
    a customer facility, I may not have access to many of the tools
    such as LSE that help me do my job.  
    
    So the question is:  Why are field Software Specialists not given
    the same resources to do their jobs as the engineering folks?
    
    Kevin
    been the case

    re. 53:
    
    Is is a myth that the 'System Engineer' levels quoted in our contracts
    have anything with our (Software Specialists) levels.  They do not.
    The contracts are quoted for 'Level of Service Delivered' NOT 'Level
    of the person Delivering the Service'.
    
    --  Barry

    re - the recent stuff about pricing.
    
    C'mon, folks!  NOBODY prices by "level of service delivered", or
    level of seniority.  This is the USA - prices are charged based
    on what the customer is willing to pay, then the contracts are written
    accordingly - all perfectly legit.  BUT THE   R E A L   RULES ARE 
    DETERMINED BY THE MARKETPLACE, not some corporate policy made in
    Maynard.  You know it and I know it, and we've all seen it first hand.
    
    Back to the subject of this topic - we seem to be on the subject
    of resources in general now, and not just DCL access.
    
    I'd like to tell a SHORT story about our office in Minneaplis.
    We transfered here from Chicago in March, 1985, and my wife was hired
    as the receptionist.  The person she replaced had tried for the
    previous year to get a lousy terminal at her desk.  My wife tried
    for the next year, and my wife's replacement, and HER replacement,
    has tried since that time.  Finally, a couple months ago, somebody
    coughed up the cash to put a VT100 on her desk.
    
    So, for at least the last 4 YEARS, the first thing customers
    saw when they walked into our DIGITAL office was - get this - an
    IBM typewriter right in the middle of the receptionist's desk. 
    Now, we show off our wares with a shiny new VT100!
    
    Did people bitch?  You BET people did, and all the District Managers
    agreed this was not good, but nobody did anything about it.   In
    fact, I can remember big customer meetings, (my wife was there)
    when the Sales people ran down to her desk and asked her to hide the 
    typewriter before the crowd arrived.
    
    So what's the point?  If it takes 4 YEARS and approval by GOD and
    his second cousin to get a vintage terminal on the receptionist's desk,
    then the problem is bigger than just what we in SWS see.

    Isn't there a statement somewhere about the mechanic who has the
    worst running car, and the carpenter whose house is the most poorly
    maintained?
    
        - Greg Scott (the Minneapolis version)

re: SWS management and margin

Had a short chat with my unit manager this morning and the subject of
margins came up.  He is being encouraged to develop business in certain
areas, one in particular is AI.  OK fine, says he, but we don't have any
specialists in the office who are qualified to deliver any such business.
We need to train someone, that will take about 10 weeks.  The response
he got back was that 10 weeks is too much because of the margin impact -
he can only have two.

Now, can someone tell me what the message is here?  I cannot understand
how set goals can be realized, when no one is willing to pay the costs
necessary to achieve them.

/Al

re:.56 

  First of all, given the direction of this discussion and it's focus on 
Software Services (how we get so little support for doing our jobs,
etc.), I think it would have more visibility in the Software Services
conference (SWSNOD::SOFTWARE_SERVICES, KP7 or SELECT, blah blah blah).
I'm not trying to choke anybody off but, much to my surprise, the SWS
conference apparently *is* read by a few highly-placed types in that
organization, or at least somebody with access to them. 

> We need to train someone, that will take about 10 weeks.  The response
> he got back was that 10 weeks is too much because of the margin impact
> - he can only have two.
>
> Now, can someone tell me what the message is here?  I cannot
> understand how set goals can be realized, when no one is willing to
> pay the costs necessary to achieve them.

  Well, I guess we're down to the short strokes here. I'm in the field 
too. Yes, they use live ammo out here. And, yes, it gets me depressed
when I'm tasked with pounding nails with a piece of rope. 

  But that doesn't get us anywhere. You and I and all the rest of us 
Individual Contributor types *ARE* Digital. We're the only ones who have
control over whether the customer gets a quality product for the money
they spend with us. The fact that they don't know how good we CAN be is
no excuse for duping them into believing that, for example, it's their
responsibility to pay us to read their manuals, or that it's perfectly 
normal for an Accounts Receivable program to crash their VAXcluster 
twice a week. Besides the ethical issue, sooner or later they'll catch 
on. They will never forgive you, and they'll never forgive Digital.

  Our focus has to be on the customer. Not on ourselves (except where it
contributes to the customer's success). Not on our management (unless
it's to get the resources you need to deliver quality to the customer).
Not on IBM and how to beat them. Not on some abstract number. That's for
Digital's good, for the customer's good and for sake of your own sanity
and self-respect. 

  As to your example, your unit manager should say, "Well, then we can't
have an AI specialist this fiscal year, and we can't penetrate that
market." Period. And if they try to send you, you can say, "I can't
deliver this service to this customer with the level of quality that
Digital requires and the customer deserves." If it's Sales Support, and
the Sales Rep. wants an AI expert, tell him you're not one, and that
they have to get themselves another body. Send them to Area, Country,
Corporate, Marketing or wherever that need to go to get somebody who can
do a quality job. 

  Don't get me wrong, I'm not advocating some kind of vindictive job 
action here. I'm saying that you, as a professional, have a
responsibility to yourself and to your customer to maintain the kind of
quality that has made Digital successful in the first place. I came to
work for Digital because, above all, sooner or later, Digital WILL do
the right thing. My responsibilty is to make sure that I do the right
thing by my customer. It's not easy, either. That's why Digital is such
a rare success story. 

  Use Digital to make your customer successful, NOT the other way
around. Some people confuse the metrics of success (customer survey
results, revenue numbers, margin numbers, etc.) with success itself. 
That's their problem. If they become personally successful as a result,
good for them. I'd rather be able to look myself in the eye when I'm
shaving in the morning. The best part is, I *KNOW* that I'm going to be
successful too. Maybe not this quarter, maybe not this year, but
eventually. 

[*CRRACK* Ooops ! my soapbox collapsed...]

  Regards,
  Larry.

re: -1

After five years in the Field with some success, I know full well what the
"right" thing is.

DCL is the topic of this note, but it is also a rather powerful metaphor for
everything wrong in "our" (SWS) neck of the woods.  The problems I have
seen mentioned here, i.e. lack of equipment, manuals, desks, training, etc.,
are the very same problems that were obvious when I started with the company.
Little has changed in 5 years.  

Yes, we individual contributors get results, even in the face of such adversity
(anyone in Engineering or Manufacturing listening??).  In order to
advance, or even survive out here, you have to learn how to work the
system.  Complaining about the lack of resources gets you nowhere; in the
worst case, it limits your career.

But there are limits to what can be accomplished with nothing, and good people 
won't put up with it forever.  The fact is that margin is the single most
important metric in the Field, the grandaddy of them all, more important even
than customer satisfaction survey results.  At least, this is how it seems
to me. And therein lies the problem. We have (as I understand it) one of the 
highest margin requirements in the corporation (40%+ ?), and certainly higher 
than ANY of our services competitors.

And how do you obtain high margins when you figure that salaries and essential
overhead don't vary much from company to company?  Well, you do two things.
You charge more than anyone else, and you cut costs to the bone.  And, when
you cut costs that much, what value, in the long term, does a DEC specialist
add over any of our competitors?  The answer is, of course, not much.  And
when the added value is not readily obvious, we loose in competitive 
situations.  We have some outstanding successes when we have been given the
chance, but I think we loose far too many opportunities.

Oh, I do read SOFTWARE_SERVICES and PSS.  There is not much activity in either
conference, however.  Mostly questions about project management and prototyping
tools.  If the moderators want this conversation out of here, fine.  Until
then, it has been more interesting here....

/Al

    Welllll..   true about metrics...  Customer sat is very important,
    but you don't see too many units survive on High satisfaction and
    low margin...
    
    

  What generates expense, mostly, is having people, idle or not. What
generates revenue is doing work for customers. Margin is the difference
between revenue and expense. If you have people sitting aroung because
nobody is buying what you sell, you're going to have a margin problem. 

  OK, so what makes customers buy your service product? 

  If nobody NEEDS the service you're providing, whether it's good, bad 
or indifferent, you're not going to sell any anyway. The solution in 
this case is to get out of that business (well, you can also try to 
create the need, but that's a different story).

  If customers need your service product, they'll buy the one that they
perceive has the most value to them. How do they measure the value of a 
service? If some vendor has done this kind of work for them before and 
they were satisfied with the result, they'll probably go to that vendor 
again. If a vendor "screwed" them, customers will do almost anything to 
avoid using them again. If they've never needed this kind of service
before, they'll ask somebody they trust for a recommendation. 

  So, what make customers pay money to SWS for service? Customer
satisfaction. What keeps them coming back for more service? Customer
satisfaction. What makes the customer recommend Digital to his business
associates? Customer satisfaction. 

  And what do all of these things do ? They allow you to generate 
revenue. What does revenue do ? It allows you make margin.

  As to that other metric, what makes the customer put 9's and 10's on
the survey after you've completed the service? Well, taking the customer 
to lunch and telling him that if he doesn't, you don't get to go to 
Hawaii might do it. But, I'll tell you what, if he thinks that you and 
your organization are a bunch of technically incompetent, unethical 
shysters, begging probably won't do the trick. On the other hand, if
you've made him successful by delivering what he needed when he needed 
it for what he expected to pay, you probably won't have to coach him at
all. 

  Now, that was a long, boring dissertation of obvious, common sense, 
cause-effect relationships. Right ? Well, it appears that the sense is 
not so common. The only way to create customer satisfaction is to FOCUS
on customer satisfaction (I know, I haven't proved it, but how else do
you do it ?). Good margin and survey scores are CAUSED by satisfied
customers. Lots of resources, big raises, trips to exotic locales and
promotions are CAUSED by meeting (and exceeding) metrics like margin and
survey scores. 

  And who has control over the customer's satisfaction with their 
Digital software services? K.O.? Jack Shields? Don Busiek? Bill Ferry?
Your area manager ? No. It's the person who is in the customer's face
everyday. That's you. 

  Yeah, I've heard expense-margin-revenue arguments before. Pretty
heady stuff, all of this financial mumbo-jumbo. And, boy-oh-boy, we can
add it, subtract it, average it. Yes, indeed, we've become pretty
sophisticated about our business now, haven't we!

  Just don't forget that the purpose of mathematics is to *model* the
real world, to help us measure it and possibly to understand it better.
But, it is *not* the real world. A lot of people get the two confused.
Some even succeed as a result of their confusion. For a while. 

  Regards,
  Larry.

    re: .-1
    
    >    Good margin and survey scores are CAUSED by satisfied
    >	customers. Lots of resources, big raises, trips to exotic locales and
    >	promotions are CAUSED by meeting (and exceeding) metrics like margin and
    >	survey scores. 

     
    But to complete the above circle, meeting survey score metrics is
    CAUSED by having the resources to accomplish it!!!
    Holding back resources because a unit hasn't been able to satisfy
    their customers is a catch-22! How do we make the situation better???
    
    If a customers needs are not met in a timely manner becaust I don't
    have the resources for it, or if, worse, he catches me developing
    software for someone else on his machine, there will be NO WAY to
    get him on Digital's side again.
    
    Kevin

    More to the point (and MY favorite argument):
    
    How can dissatisfied employees be expected to satisfy customers?
    
    And WHAT dissatisfies employees?  Not having sufficient resources
    to do thier jobs!
    
    Jim
    

    Our datacenter just took what they call a "major security enhancement"
    on our area-wide mail machine.  They have forced the use of the
    VMS password generator.  They also sent out a note reminding people
    not to write down their password.  Supposidly they phoenetic spelling
    of the system-generated password will make it very easy to remember
    the correct spelling.
    
    BTW - DCL access on this machine is very difficult to get too. 
    Also, if you are fortunate enough to have it you will discover that
    you really do not need it as there are no layered products on the
    machine.

    
    Generated password are an important part of securing system.
    Digital Field Service policy is for all their systems to use password
    generation (although I have no idea if this is really done).
    
    Even those of us in the heart of engineering are finally using
    generated passwords, although only after outside intrusions.
    
    How anybody can have generated passwords and never need to write
    them down in beyond me, though.  A generated password written down
    and stored in a wallet or purse is still much more secure that
    "pick 'em yourself" passwords...
    
    					Rich Bouchard
    					VAX/VMS Development
    

   Re: .64 "...generated passwords being better than ones picked..."
    
    I STRONGLY DISAGREE!!!!
    
    I've got 10 plus years of system level "support", hacking, whatever
    you want to call it and to ME the only bottom line is a number:
    the number of characters minimum for the password (should be a LARGE
    number) and the common sense in selecting the password, i.e. don't
    use obvious or even SEMI-obvious passwords (Like your dog's name
    or something).
    
    There are enough slogans, etc. that can be strung together and
    easily remembered by the account owner that IF CHOSEN PROPERLY
    will take a system a LONG time to crack. A very stupid example
    would be a password like THISISSTUPID. This passes the 12 character
    minimum now being required and yet should be easily remembered.
    
    Having dealt with multiple operating systems where I had to remember
    zillions of passwords (and still be SECURE) I can speak from
    experience. And I've seen enough "written down passwords" to make
    me sick at the thought of how easy some systems could be broken
    into.
    
    Don't make a password have to be written down, make it LONG enough
    and non-obvious so that it is too hard to break.
    
    P.S.  I can't remember but in another notes file somewhere this
          has been chewed around considerably as well.
    
  
    							Warren
    

    A simple way to make a password easy to remember yet secure is to
    combine two words - and/or misspell them.   Use your dogs and other
    obvious name-together.  FIDOMARY.

Kind of a rathole but...the QAR system on TRIFID now forces generated passwords.
For the first time in 20 yeasr in the business, I have written down a password.
There is absolutely no way I can remember a 10-character generated password I
use once every other week, if that.

Best way I know of to come up with secure passwords:  Choose a phrase that
you can remember - something from a song, a book title you like, anything.
(The only thing you have to avoid is a phrase easily associated with you -
your NOTES personal name, for example.)  Use the first letter of successive
words of the phrase.

For example, I could choose "I spend way, way too much time reading notes".  My
password would be "ISWWTMTRN".  There is no reason to try to remember the pass-
word itself - just run through the phrase in your mind and type the letters.
I don't "know" my passwords - probably wouldn't recognize them if I saw them
written down - but I can type them with no problem.

If you use something like a book title, you can add simple variations:  Add
the author's last name, or first and last name.  Before or after the title.
With or without "by" or "wrote" as part of the phrase.

The result should be quite unguessable.
							-- Jerry

  I'll second (third?, whatever) the notion of using long, rememberable
passwords.  My prefered technique is to type in a sentence much as Jerry
Leichter abbreviates those sentences.

John

Those are good suggestions. The one advantage generated passwords may
have, is that they guarantee non-guessability, as opposed to relying
on the good judgement of users.

The obvious disadvantage is they generally force you to write them
down, at least until they become familiar.

- greg

    Easily remembered words from a non-work related hobby do well.
    For instance, who but a gun buff and reloader would understand
    REDDOT or IMR4227 ? (Both are types of gunpowder) And since
    there are a hundred or so powders, even a hacker who knows that
    I reload...... :-)

	But what good are system-generated passwords when there are local
	machines not controlled by so-called "security administrators"?
	A case in point:

		Our office (BXO) uses the following machines:

			NEMAIL cluster
			BOSTON
			BOSGPX
			SLUGER

	Only the cluster has/will have system-generated passwords (at least
	as far as we know). The cluster also has *nothing* on it; as the name
	implies, it's a mail machine - BOSTON is our development box.

	So what good does it do to secure a *useless* machine and not secure
	other machines that are reachable from the terminal server?

    I too am a firm believer in *long* passwords.  I usually use an
    entire line of a poem sans spaces.  It usually runs at least 25
    characters and is changed at frequent intervals.  I have never had
    anyone break into my account (in 15 years).  Breakin attempts have
    happened, but no successes.
    
    A friend of mine uses a drum rythm played on 2 keys.  Even if I'm
    watching, I can't catch all 30 keystrokes.
    
    I agree that passwords should be non-decipherable and non guessable,
    but you should be able to remember them without writing them down.
    
    						Have a GREAT day!
    						Pete
    

    Another very secure method is to use words from a language not used
    in the local environment.  If there's more than one such language
    available, associative terms are much less risky to use as passwords.
    Slavic, semitic, and asiatic languages are particularly good in
    the US since those language groups have fewer cognates with english
    than romance or germanic languages do.
    
    						=maggie

    re passwords:
    
    My favorites tend to be Roman emperors.  Not only are there a lot
    of them, but how many people can tell you, say, Nero's *full* name?
    
    Dick
    

    I personally favor common words with grouped keyboard characters
    that I deliberately spell wrong.

    I personally like constructing things like
    RUDNME				URAK9
    Are you the Enemy?			You are a Canine.
    
    Boy has this topic wandered...

    I normally  add in random numbers to what ever words I select
    
    i.e.  "my7new92pass5word"
           
    Just passing through.........
    
    Mark

    My favorite (that I dont use any more) was "MYNAME".  This one is
    so secure that you can tell anybody your password and they still
    wont be able to get in your account.  They tend to try "LARRY",
    "WAKEMAN" "LARRYWAKEMAN"... and come back and ask how to spell myname.
    
    Another one I like is the practice one person has here of encrypting
    his password on a telephone touch pad.  
    
    Larry

Some of these ideas are good, some are extremely poor.  Consider Roman
emperor's or terms used by gun enthusiasts.  You each claim there are "hundreds"
of obscure terms.  I can easily get a list of more emperors or gun terms than
you ever heard of - say a thousand each - and check them all in a couple of
seconds.  No, I'm not going to try typing them in by hand; if THAT were the
threat, ANY 6-character word would be safe.  Instead, I'll get hold of your
encrypted password - difficult but not enormously so - and run a little program
that encrypts all the possibilities and compares.

Never underestimate the power of brute force!  To protect against it, you need
many BILLIONS of possibilities; THOUSANDS isn't even in the same league.

Your methods were moderately secure against people who didn't know you.  Someone
who knew you well enough to know your special interests would have a fair chance
of guessing what to try.  Anyone reading this note now knows EXACTLY what to
try!

What matters is not the apparent obscurity of your choice to people; what
matters is that the space of possibilities it is drawn from is HUGE.  Examplee:
Suppose there are 100,000 words in English.  (Close enough - and most of them
are so obscure you might as well use a random pronouncable sequence.)  I
can certainly check a trial password in 100ms (.1 second), so if I suspect
you've used an English word, and I have a dictionary available on line (no
problem these days) I can run through ALL of them in 10,000 seconds = well
under 3 hours.  Now, you've heard about the vulnerability of English words,
and avoid it by the common suggestion of inserting one digit somewhere in the
word.  Suppose words average out to 10 letters (this is a high estimate).  You
have 11 choices for position, 10 choices for the digit, so you can generate
110 passwords on average from any one word.  Hence, if I know you are doing
this, I can have my program run through all those possibilities, too.  If you
work through the arithmetic, you'll find that I can now try all the possibil-
ities in about 13 days.  (Of course, on average I can expect to find your
password after going half-way through the list - about 1 week.)

Now, you may ask, who can run a job for 13 days?  Maybe it would raise some
eyebrows if run on a time-sharing machine; but there are TONS of VAXStations
out there that could be run such a job in batch; no one would ever be the
wiser.

In the cryptographic community, codes aren't considered secure unless they
are proof agains an attacker who knows EVERYTHING about the cryptosystem in
use except for the particular key chosen.  You should use the same rule when
chosing a password:  Your password should be safe even after you've revealed
your method of selection to your opponent.  Many of the suggestions made in
this note do NOT obey this rule.
							-- Jerry

    Re: .-1  "..TONS of VAXstations that could run batch jobs to determine
              your password for days..." (taken slightly out of context)
    
    Well Jerry, it's even easier than that except for ONE thing: unless
    your system is the most primitive on the planet and you've been
    asleep for the last ten years your system will have warning bells
    going off all over the place after the first few tries of ANY attempts
    to break into a SINGLE account. And if you really did your job
    (translate: you're the system manager and set up a tight system)
    the processor/program/whatever trying to break into a given account
    will SHUT THAT ACCOUNT DOWN after the first few failed tries.
    
    I realize not all of DEC's operating systems work this efficiently,
    but as has already been stated if enough characters are used and
    you don't pick passwords that are RELATED to you in ways anyone
    could even hazard a guess your chances are DAMN good that nobody
    will get into your account.
    
    I have worked DIRECTLY with a negatively guided young person that
    had an APPLE computer that was dialing numbers and listening for
    that familiar tone. He also had a program that tried to guess 
    passwords, and while I was not able to persuade this person that
    the goal he sought was fruitless I also did not feel any empathy
    for the non-DEC system he was concentrating on at the time. Each
    time his program used an incorrect password he got the expected
    "invalid password" type message but the host system did nothing
    to thwart this person's next thousand attempts at getting into the
    same account.
    
    Bottom line AGAIN: Long passwords with no "signature" (yours) on
    them is the safest. Your "signature" should be considered to be
    anything personal that distinguishes you from any other average
    person (i.e. you are a gun buff, or like chess, or, {fill in the
    blank}).
    
    [As a sidenote, I do not know if the person I spoke of ever actually
    got into the system he was trying to break into, but I do know he
    tried for MORE THAN A WEEK at which time I decided it was best to
    not have that type of young person as my friend].
    
    							Warren
    

    
       Re: .80:
    
       I think the point was that it's not THAT hard to get into a UAF
    usually, pick up the hashed password of a given username, and then run
    the algorithm yourself locally in memory.  To have to run through
    LOGINOUT.EXE to try every one is extremely time inefficient, and as you
    said would generate many alarms/security evasion measures taken on my
    VMS (can't speak for many other OSes.  Many I know would just ignore
    it.)
    
       .79 has a very good point.  You can't consider a encryption method
    secure unless it's secure when everyone knows everything about the
    algorithm.  I can get the VMS password hashing algorithm off
    microfiche, or by disassembling a part of LOGINOUT.EXE.  I can get the
    hashed password off disk.  (One of the things Pete McVay's security
    checker does is check world-readable-ness of SYSUAF.DAT.  If it's
    readable, your system is open to anyone with a compute engine and
    enough time.)
    
       The only hope you have then is that you can figure out the mean time
    to construct a password which hashes to a given random value, and
    automatically change passwords within a time interval which gives a
    good chance that it'll change before a working password is found. 
    (Note that the password hashing algorithm isn't 1-1, in HACKERS, you'll
    see that many passwords hash to the same value.)  Even then, it's
    possible that the first password tried will work, and your system is
    open right away.
    
       Is this perhaps the beginning of a move for VMS to use a more secure
    password encryption algorithm?
    
    
    					-mjg
    

    But to reiterate - if all other security systems are in place, and you
    are trying to protect the system from outsiders that don't have
    accounts already on the target system - generated passwords are
    overkill, and place a really unnecessary hardship on users (which IS
    kinda what this topic is about). 
    
    If you are trying to protect the system from a local user who already
    has an account on the system and is trying to break in and get more
    privileges (for example, a disgruntled employee that used to have privs
    before the machine was dedicated to mail service)... 
    
    THATS A DIFFERENT STORY!
    
    Might I suggest that sufficient resources for DEC employees would
    eliminate most of the motivation for internal hacking.  As for the
    outside world, well I'll place my confidence in VMS evasive tactics
    anyday (Come to think of it, does VMS know to go evasive when attempts
    come through different generated port numbers on a LAT?).
    
    If we are getting generated passwords now, whats next?  A system
    password????  (I'll probably live to regret saying THAT!).
    
    An almost, but not QUITE, disgruntled employee.
     

The belief that you don't have to worry about people doing encryption probes on
SYSUAF because on a properly run system an intruder can't log in in the first
place, or because typing a lot of guesses at the prompt while logged out will
raise alarms is incredibly naive.  The method I've usually seen used to
penetrate systems is a two-step process:

1.  Utilize a bug in the operating system (or system management setup) to get
into a privileged account.  This may well raise alarms or leave a trail which
can be traced to determine that the system has been penetrated.  So what. A
smart intruder will just steal the passwords of existing accounts, and then log
off of the compromised account.  While everyone at the site is waving their
arms in the air, the intruder is probably eating lunch.

2.  Using the stolen passwords, log into the system again (possibly after
letting things cool down for a few days or longer).  Unless the system
management is smart enough to have immediately changed all the passwords,
this approach *will* succeed.  This is the point where the intruder eats
YOUR lunch.

Storing passwords in encrypted form merely adds another step:

1.5. Systematically attempt to find a password which encrypts to the same
value as one of your stolen passwords.

An intruder with an on-line dictionary and a copy of the encryption algorithm 
sufficient resources to break into any system with enough accounts if people
pick an English word for a password despite being told not to. I have no
sympathy for anyone who does that and then complains about being forced to
use generated passwords, since it is their lax attitude towards security which
will enable their system to be penetrated.
				/AHM

    I'm starting to get disgusted with all this security crap! My site is
    switching to LATs and talking about implementing passwords on the
    DECServer. As I talk to people and ask why we can't simplify the 
    process, I get this feeling that some of them think their real enemy
    is the employee and not outside hackers.
    
    Let's play out the 'every point uses a random generated password'
    scenario. I have a terminal at home. I live in Fitchburg and work in
    Shrewsbury. Currently, I call WMO; select TSN and login with a default
    to SHR; placed on the LAT, i select my system and login. That's two
    logins, one on a group account and one individual on a specific system.
    The ultimate scenario is WMO implements a DECServer with random
    password. [How do I obtain this password that changes every three
    months?] This allows me to select TSN out, but I have to login. [How
    do you obtain this password?] That connects me to the SHR DECServer,
    to which I have to login. That allows me to connect to my system,
    to which I have to login. Now, all these are random generated
    passwords. All of these are supposed to be communicated to me via
    personal contact, every three months, and I'm not supposed to write
    any of them down. The logisics of the first part and the stupidity
    of the second part, are incredible. The people that would be kept
    off of the net, are the ones that are supposed to use it. The kid in 
    a previous response will keep trying. As I see it, I will have two
    choices. Make the toll call to SHR (thereby avoiding two logins) and
    turn in expense vouchers for the cost, or don't bother. Result, return
    to the dark ages. Oh yes, if I'm in a different facility for a meeting,
    I'll find someone I know and just SET HOST from their system, so that
    I don't have to go thru the login via TSN step. Or I won't bother
    reading my mail til I get back to my office.
    
    Bob Mc

>    switching to LATs and talking about implementing passwords on the
>    DECServer. As I talk to people and ask why we can't simplify the 
>    process, I get this feeling that some of them think their real enemy
>    is the employee and not outside hackers.

The day after we implemented LAT passwords, someone, somewhere, on some LAT
was trying to break into the DECNET account (and others) on my machine.

This means that whatever hacker was attacking my machine was either in the
building or had managed to get the LAT password in less than 24 hours!

Sounds like an inside job to me.

/john

    RE .84
    
    	Sorry, I hear your complaining, but you can't reach me.
    	Security is SERIOUS business. We have been spoiled and
    	vulnarable for too long! If you think you are inconvenienced
    	by the login process, try losing your system for 4 days
    	while they rebuild it from the ground up due to an unauthorized
    	entry. This can and does happen.
    
    	You sound like a spoiled brat who can't have his way so you
    	don't want to play anymore. As far as I am concerned, we do
    	what we must no matter how inconvenient to protect our systems,
    	our data and ultimately our jobs. We cannot afford to be
    	vulnarable to outside hackers. You are being asked to cooperate
    	for the protection of all. Please look beyond your own
    	situation and join the team trying so hard to protect us from
    	those that would do us harm.
    
        I heard on the news last week that police in France arrested
    	a speaker on his way to a computer conference for hackers. He
    	is part of a worldwide network of hackers that work to break
    	into corporate/educational institutions and do their dirty
    	work. These are not kids. They have a membership of highly
    	sophisticated hackers around the world and based in West
    	Germany. These folks just love to find sites where security
    	is lax because these sites could be a window into some other
    	facility(ies). Security is no longer a joke and we must get
    	very serious about it.
    
    							Art
    

  I don't know if this has been mentioned before, but what about using secondary
passwords on all privileged accounts, and disusering all privileged accounts
not being used?

re .86?
  The person caught in France was the president? of CHAOS hackers club in West
Germany.  They hacked into a NASA-SPAnet system.  From what I understand he was
supposed to give a speech on security at a security conference in Paris.


	Jack

    re: .86 It's a serious breach of etiquette to say "you sound like a
    spoiled brat". 
    
    Regardless of how one feels about security, it's unnecessary to
    characterize one's opinions in that manner.

    re .83
    
>    1.  Utilize a bug in the operating system (or system management setup)
>    to get into a privileged account. 

    This is exactly my point.  The hacker has to get in somehow in the
    first place.  No amount of password changing, encryption, garbling
    or whatever is going to prevent the scenario above from happening.
    
    Security IS serious business - there is no doubt about it.  But
    so is consulting, software development, electronic mail, computer-based
    instruction, office automation, noting, using spreadsheets, configuring
    systems, reporting time, word processing, data collection, giving
    demos, etc., etc., etc.
    
    Lax security is a problem.  But what I see happening is TREMENDOUS
    overkill at the user password level, while other areas of concern are
    all but ignored.  For instance, if you log into Tymenet and type a
    six-character word, you will find yourself at the "Username:" prompt
    for our mail system, inviting you to score a lucky guess:
    
	Unauthorized use prohibited (translation: C'mon, hacker, I DARE you!)

    I also see people thinking that increased password security is going
    to shield against other weak points, as in note .83, which simply
    IS NOT TRUE.
    
    I've got nothing against security.  But this security thing is starting
    to sound like the "red scare".  I have always, and WILL always hate
    people flying off the deep end in a blue panic, when it accomplishes
    little or nothing except to cause tremendous inconvenience for hordes
    of individuals that did absolutely nothing to deserve it.
    
    If security is so very important, start at the source.  Invest in
    call-back and/or secure modems.  Tighten up the use of timeshare
    services.  Don't play games with hackers, teasing them to try and beat
    your system - cut them off at the source!
    
    But don't make life miserable for the 150,000+ people that have to
    remember idiot passwords to access the system sitting in their own
    building.  Don't make people who sit at a keyboard for a living
    endure password hell.
    
    And finally, a question to all you math majors out there...  What
    is the likelyhood of breaking into a system using a password generator
    similar to that used by the SET PASS/GEN software?  That is, what
    if you know that the passwords are meaningless, so you use a system
    that comes up with "pronounceble" passwords?  For some reason it
    strikes me as more likely than trying to break, for instance, two
    unrelated english words, like ORCHESTRA_TERMINAL_1, or LAUNCHPAD_DINGHY_Z,
    combinations that are easily remembered so that they don't have
    to be written down, which we all know is the WORST possible security
    violation - AND that EVERYONE that doesn't have a photographic memory
    will soon be doing!
    

    And I'll say this till I die:
    
    The more characters to a password the HARDER it is to crack -- even
    if you have the hashed password and lots of machine time. And as
    previously mentioned it would be better to have lots of unrelated
    words strung together to make a LONG password. 
    
    Personally, I prefer two to three words that make a nonsense statement,
    sort of like "BANANAS_BEAT_PORSCHES" or "FISH_TALK_IN_REVERSE",
    etc. 
    
    As for multiple passwords (LATs, system, etc.), yes it is preferable
    to have some way to just dial into the system and have it dial you
    back. This is the MOST secure method and probably preferable to
    those of you that have to make a long distance call to get into
    a system, since it places the charges on the system side.
    
    PLEASE, PLEASE, PLEASE don't write down passwords. If you MUST,
    spend the $39 it costs to get one of the latest "credit-card
    data-banks" that stores data for you with your own personal code
    preventing access by unauthorized persons. 
    
    Perhaps it's time DEC started looking at these type of devices?
    There is even a single product on the market that works with
    software that generates a pattern on the screen that is interpreted
    by the device and in conjunction with the users SINGLE password
    would allow access.
    
    I agree that remembering 6 passwords to get to one system is overkill.
    There are better ways. Unfortunately, until a standard is
    chosen/designed/etc. we'll all have to live with the status of the
    technology.
    
    							Warren
    

    
    I think some people are missing the point a bit.  Yes, properly
    chosen user-generated passwords are almost as secure as randomly
    generated ones, and easier to remember.  But how do you enforce
    the selection of proper passwords?  You can't, but you can enforce
    random password selection.
    
    I (and many others in ZK) lost the bulk of a days work due to somebody
    chosing an improper password.  That is a lot more annoying that
    having to use a generated password.
    
    I also fail to see a serious security problem in writing down your
    passwords.  Keep a copy in your wallet or purse.  The (very) senior
    people in charge of security here in VAX/VMS Development suggested
    people do that!

There's nothing wrong with writing down passwords, as long as you don't
post them on the terminal or the office bulletin board, which is where a
lot of the horror stories come from.  Keep 'em on a discrete card in your
wallet or checkbook.  Make sure you have a backup list in a locked file
or at home so that if you lose your wallet or checkbook you can quickly
get onto your system(s) and change them (or notify the system managers
to change them).  I have to keep track of quite a few passwords, and
it isn't more than momentary trouble.

/Dave

    Thank you .88 & .89
    
    Re .86
    Thank you for letting us know that your mind is totally closed to
    reasoning.
    
    The point here folks is that; two levels of 12 character, randomly
    generated passwords, is sufficient to deter or severely inconvenience
    all but the most sophisticated system breakers. It would be annoying
    to the 'average' DEC user, but not totally frustrating. Also, this
    should provide sufficient time for the sysmgr to recognize that an
    attempt is being made. Four levels are gross overreaction and would 
    convince most non-technical employees to not use the network. "Send me 
    interoffice mail, I can't get into my VAX account".
    
    And, therein lies another question. Do I detect a certain level of
    'techie elitism' here? Didn't this topic start out by complaining
    about no DCL access? Let's see, how about designating the person,
    that complains the loudest about lax security, the person that has
    to personally contact every user at their site and whisper the new
    passwords in their ear, every three months.
    
    Bob Mc

        This topic is getting way off track.
        
        Re: .87
        
> I don't know if this has been mentioned before, but what about using secondary
>passwords on all privileged accounts, and disusering all privileged accounts
>not being used?
        
        Secondary passwords are designed for `two person control', where
        it takes two people to log into an account, each of them knowing
        one password. 
        
        If you don't want that feature, using one long password is
        basically as secure as using primary and secondary passwords.
        Secondary passwords can not be used to force user accounts to be
        more secure:  users can disable the secondary password anytime
        they want or (if you keep enabling the feature) use the same
        string for both passwords. 
        
        Disusering unused privileged accounts is a good idea. 
        
        
        Re: .84 & .93
        
        Yes, I agree with you, two 12 character passwords (chosen in a
        reasonable manner) would be sufficient to protect the security
        of your system. 
        
        But, in the situation you described in .84, each of the four
        passwords is necessary: 
        
            The WMO DECServer needs to prevent intruders dialing up to
            gain access to that LAN. 
        
            The TSN machine needs to prevent intruders from using that
            network.  It doesn't know that you already entered a
            password, or that your destination will request a password. 
        
            The SHR DECServer needs to prevent intruders from gaining
            access to that LAN.  It doesn't know you already entered two
            passwords, and it doesn't know that all machines on the LAN
            have good passwords on all accounts and other adequate
            security measures. 
        
            Your system needs to authenticate you.  It doesn't know you
            entered several passwords already, and the passwords you
            already gave did not identify you, but rather a large group
            of people. 
        
        I don't see how any of those passwords can be eliminated
        currently, but work needs to be done so they can be eliminated
        in the future. 
        
        One possible future scenario is:  When you dial into the WMO
        DECServer you are presented with some confirmation that this is
        the real DECServer and not some random machine masquerading as
        the DECServer.  You then log in by specifying your name and an
        individual password.  The DECServer consults an EasyNet
        authentication server that verifies who you are.  When you
        connect to TSN your identity is passed along---you are not
        required to log in and the TSN machine can use the identity to
        determine your default port.  The identity is passed to the WMO
        DECServer and to each node you connect to, so no passwords are
        needed for either of them (and you also have the option of
        specifying a different username and logging in with a password).
        There is protection against each machine in the chain using your
        identification information to impersonate you. 
        
        People are investigating networks like this, but until the
        various components work together it is necessary for each
        component to require you to authenticate yourself.  In sorry, it
        is indeed a pain to enter four passwords, but I see a security
        reason for each of those passwords and no easy way to eliminate
        them. 
        
        					B.J.

    .79:
    
    Well, what I didn't want to admit about the Roman emperors was that
    in every case, I've handed to the new proprietors a card reading
    "VESPASIANUS" or some such, and saying "Here's the password to SYSTEM",
    and they've said "Urggh!  Too long, I'll never remember it.  Have
    to change it to something reasonable, like 'september'".  Made me
    wish I'd used Nero's full name (I can't remember it, but it's built
    from 7 or 8 names, and probably exceeds the max length).
    
    (I'll mention this because the FS guys had attitudes rather like
    the sysmgrs:)
    
    The most amusing part was giving FIELD passwords like CALIGULA or
    NERO_CAESAR or DOMITIAN (if you see what they had in common :-)
    
    Dick (FS refugee)

re: .89

	1) Perhaps this is silly, but if it's so easy to get to Enet from
	   Tymnet or ARPAnet, why do we allow it? Do we really need this
	   on a continual basis? For what?

	2) Along the same lines, I said it before - why not dial-back
	   security ?

	An internal hacker can be deterred, not stopped. An external one can
	be stopped. I'd rather inconvenience the relatively small number of
	staff who need dial in/external network access, than to piss off
	everyone.

	Yes, it really isn't that tough, but...

	eric_who_writes_his_password_in_a_Coop_diary_he_keeps_in_his_pocket_
	because_he_once_went_on_a_long_weekend_and_forgot_it

P.S. another cutesie suggestion - jargon fromA Clockwork Orange, concatenated
     with a foreign word - e.g. manchikpobre

    All this discussion about security and passwords is GREAT!
    
    Was there any participation from the people who sent out the SAVE
    statement AGAIN with password and badge number and phone access
    numbers clearly PRINTED on it?
    
    	-Barry-
    

Re .89:
  
Unguessable passwords are necessary to attain a reasonable level of security for
any of our systems.  If you concede that no version of any of our operating
systems is immune from security holes caused by bugs, then you should understand
that those "evasion" features you are so proud of can be substantially negated
by guessable passwords, encrypted or not.

I recently heard someone wonder whether the space of generated passwords was
smaller than the space of all possible passwords.  As a math major, I'll tell
you that while no one is going to break into a system with evasion features
enabled by guessing a phonetic password, I suspect that such passwords should
be appreciably longer than what I've seen if it is desired to really cover VMS's
complete password space.  That may not be a realistic concern.

Here's a shot in the dark for you Jim: when did you stop using "OUTERLIMITS"?

Re .90:

If a password is guessable from a dictionary, the time it takes to guess it on
VMS is essentially independent of its length.  In fact, the longer the minimum
password length, the less time it takes to go through the dictionary, since most
words are quite short, and can thus be eliminated cheaply.

Re .91:

I can think of one rather labor-intensive method of insuring unguessable,
user-selected passwords.  A system manager who is willing to record and verify
people's passwords *after* they have been changed can decide for themselves
whether the passwords fit reasonable criteria (such as length, lack of a
pattern, etc), without divulging any useful passwords.  I wouldn't envy such a
job, but it would be an alternative to generated passwords of insuring that a
user community plays by the rules over the long term.

Note that the possibility that your group is too big to adopt this policy should
not influence others.

Re .96:

Where do you see the word "ARPAnet" in .89?


I don't consider dialback modems a cure-all - at least one model has been
bypassed in the past by people with no physical access to the site and without
doing anything to the phone lines.


I find the apparent average level of security concern within Digital these
days quite disturbing.  I've never seen much investment by management in
proactive security measures, especially user education.  However, with the
attitudes I see in far too many people, I wonder whether education will become
a moot point.  Education and TRUST might well take a back seat to
nondiscretionary access controls.  The day may be fast approaching when EVERYONE
(and I include all of engineering in this) is saddled with generated passwords,
no privileges, restrictive ACLs and everything else that makes it difficult
to breach security.  It is possible to not give users the CHOICE of whether or
not to be a jerk and permit some high school student to wipe all your disks some
weekend by picking their username as their password.  I can just see the "them
were the good old days" discussion in this conference 5 years from now. 
Is this a foregone conclusion?
				/AHM

    re .98
    
>    Unguessable passwords are necessary to attain a reasonable level of
>    security for any of our systems.  If you concede that no version of any
>    of our operating systems is immune from security holes caused by bugs,
>    then you should understand that those "evasion" features you are so
>    proud of can be substantially negated by guessable passwords, encrypted
>    or not. 

    Alan, I hope I was not misunderstood.  I agree completely.  The
    only place we may differ is that I don't believe the equation:
    
    		user-generated passwords = guessable passwords
    
    I would personally find a minimum password length of some ridiculous
    size like "12" infinitely preferable to a computer-generated password,
    and I believe it would be next to impossible to come up with ANY
    easily guessable password that is 12 characters long.  I knew a
    system manager that used TIPPACANOEANDTYLERTOO.  Even if I overheard
    the password, I STILL don't know how to spell or punctuate it.
    
>    Here's a shot in the dark for you Jim: when did you stop using
>    "OUTERLIMITS"? 

    :-)
    

>    In fact, the longer the minimum password length, the less time it takes
>    to go through the dictionary, since most words are quite short, and can
>    thus be eliminated cheaply. 

    *IF* you know the minumum password length.

>    It is possible to not give users the CHOICE of whether or not to be a
>    jerk and permit some high school student to wipe all your disks some
>    weekend by picking their username as their password.  I can just see
>    the "them were the good old days" discussion in this conference 5 years
>    from now. Is this a foregone conclusion? /AHM 

    I got bad news - these *ARE* the good 'ole days!
    

    re .96

                    -< why Tymnet/Arpanet access so easy? >-

    Tymenet, ARPAnet, DECnet...  These networks are all alike!  :-)


>    	1) Perhaps this is silly, but if it's so easy to get to Enet from
>	   Tymnet or ARPAnet, why do we allow it? Do we really need this
>	   on a continual basis? For what?

    I guess you haven't noticed my other diatribes in this note.  I
    am one of the few, the loud...  Software Services.  I am one of
    the elite group that is required to log in once every six months
    to prove I am still technically competent to consult.  But seriously,
    you must consider there are other groups affected by these policies.
    Folks in the field may not even SEE their office but about every
    six months.  After-hour access via modem is the ONLY way we can
    read mail, etc.  And as stated, previously, yes, we can use long
    distance lines (which STINK!), record the charges, and then bill
    them to DEC, but that is mercilessly inconvenient, especially for
    folks like myself that are logged in every night, and unfair because
    it takes time for the money to change hands.  Tymenet is NOT a
    convenience as long as there are folks that don't have any other
    access (BTW, these folks in the field that require dial-up access
    are one of the main reasons for all the security crap - we have
    created a LOT of exposure in our efforts to make compute power
    available in the field.  I envy you not having to dial in at night,
    but please don't take away my access, okay?
    

>	2) Along the same lines, I said it before - why not dial-back
>	   security ?

    I recommend these, I would LOVE these.  However, as you can read
    elsewhere in this file, it is TREMENDOUSLY cheaper to make a stupid
    policy that it is to buy modems.  And again, obtaining ANY hardware
    in the field requires an act of God.  The only reason security has
    been so long in coming is because its been so hard to get terminals
    for people's homes, that there hasn't been a need for a lot of dial-in
    accounts.  (Another good security precaution - turn off dial-up
    access except for people who need it - i.e., people with terminals
    at home, etc.).
    
>	An internal hacker can be deterred, not stopped. An external one can
>	be stopped. I'd rather inconvenience the relatively small number of
>	staff who need dial in/external network access, than to piss off
>	everyone.

    As noted above, you just "pissed off" almost everyone in my district,
    to the person (350 - "small number of staff").
    

How to keep people from using "obvious" passwords:  Have SET PASSWORD check
them against an on-line dictionary; refuse to accept the password if it is
found in the dictionary.  Keep adding to the dictionary as you find weak
passwords people use:  Names, car models, etc.  Also check against a couple
of obvious things, like the account name.  This is cheap and easy to do, and
HAS been done on some Unix systems; it can make guessing very unlikely to
succeed.

Be sure to couple introducing such a system with some training in GOOD methods
of choosing passwords, whether using random pairs of words or the acronmym
algorithm I proposed or something else.
							-- Jerry

PS  Unrelated issue:  It is trivial to write a Trojan horse program that will
use $GETUAI to extract your hashed password.  The only problem is finding a
way to get that information back to the system cracker.  But I can think of
a number of methods to do this - even for a cracker without any account on
your system.

Running ANY software you picked up off the nets?  For that matter, any 3rd
party software - what do you REALLY know about the programmers working for
the maker?  (All this is assuming you have complete trust in 120,000 or so
co-workers - not a bad apple in the bunch, right?)

Another unrelated issue:  Generation of passwords is another place where
apparent randomness can be cnfused with security.  I knew a site that gave
its users randomly-generated, unchangeable passwords.  The passwords were
some 8 characters long, mixed letters and digits.  Looks VERY secure and
unguessable.

Then one day I had a look at the password generator.  It used something like
a 16-bit random key; or maybe it used consecutive values of the generator,
I forget which.  If the first, I can quickly try all 65536 possible pass-
words - no protection at all.  If the second, I can figure out the random
key MY password came from, then run the random number generator backward and
forward a couple of hundred steps - and be certain of finding all passwords
generated in the same run (in practice, most passwords on the system - they
were all re-issued in one big run every couple of months).

Are random pronouncable passwords vulnerable?  That depends; you need to
know not only how many "pronouncable" combinations there are, but how
they are computed - and form what.  (If the generated password is created
based on the VMS time, knowing even approximately when you changed your
password would be enough:  The VMS clock can only take on 86,4000 distinct
values in a day, and I can try the passwords each of them [^864,000] leads
to.)
							-- Jerry

Re .99:

Yes, I agree that everyone is capable of composing unguessable passwords, you
and I probably use them exclusively, and that you and I don't like machine
generated passwords.
				/AHM

Let's get back to the topic (more or less).

Anybody have any suggestions on how to get the computes to the people that
*NEED* DCL access, now that some data centers are taking them away?

Do the high-level mgrs understand the need for this kind of access?

Lee

Ask your VP when he comes visiting.  (See topic on DEC culture)

    I still believe the only thing that will make resources appear in the
    field is a VERY high-level field management person having a visitation
    on high from the diety of common-sense instructing him/her to go out
    and "gird up the loins" of his/her people. 
    
    Our local management is REALLY trying to get us hardware.  And I
    really APPRECIATE what they are trying to do!  But on our shoestring
    budgets, we will never be more than just over the computer hardware
    poverty level.
    
    Most companies buy computer equipment to accomplish something, and the
    programmers are there to keep the cogs greased.  In the field, our job
    is to grease OTHER people's cogs, and the hardware in the home office
    is not quite as important to day-to-day operations as Voicemail and
    typewriters.  ("Ongoing training - thats what Ed Services is for!").
    
    If someone can come up with a productive way of getting this message
    into the ears of those with the authority to make a change, count
    me in!  I'll join a sit-in on Parker Street, if AT LEAST one other
    Deccie will be there.
    
    However, most are too busy doing their jobs.  A salesperson once
    complained that it was ridiculous to have to write every proposal from
    scratch.  I explained that as long as it was more important to meet the
    numbers than it was to admit failure to the manager in charge, and cite
    lack or resources as the problem, than it will never get better.
    Suffice to say the sales person and I sat up late many nights writing a
    proposal from scratch (in this case I was the techie peon doing the
    DECpage - but its true - I wimped - another example of the strong
    drives in the salary continuation plan). 
    
    Jim
    

    .100:
    
    A certain three-letter competitor's software includes the feature
    of keeping a list of the last 10 passwords you've used, which makes
    the following much harder to do:
    
    $ SET PASSWORD
    Old password: FAVORITE
    New password: FOOBAR
    Verification: FOOBAR
    $ SET PASSWORD
    Old password: FOOBAR
    New password: FAVORITE
    Verification: FAVORITE
    $
    	... and away you go for another month (or whatever the password
    life is set for)...
    
    Dick

	    We kill what we fear?

        Re: .106
        
>    A certain three-letter competitor's software includes the feature
>    of keeping a list of the last 10 passwords you've used, ...
        
        A decade ago it was 8 instead of 10, and the father of a
        friend had a command procedure that changed his password
        nine times to return to the original value.  I guess they
        increased the number remembered to avoid that problem.  :-)
        
        The moral:  Don't allow the password change procedure to
        take new passwords from a command procedure, make sure it
        comes from the terminal.  That means that users have to fool
        around with logical names or pseudo terminals to get around
        restrictions like this.
        
        The real moral:  You can't force a user to use good passwords
        by just annoying them.  Lots of remembered passwords just
        drives users to bypass them, or to use a simple series of
        passwords (like FAVORITE1, FAVORITE2, ...).  The four only
        reasonable options I can think of are:
        
        	Don't worry about user's passwords.
        	Educate your users to care about good passwords.
        	Hack SET PASSWORD to check for bad passwords.
        	Use generated passwords.
        
        					B.J.

        re .106,108. Our MIS people are already using some hack to
        compare a new password to the last N Passwords...
        
        q
        

>        A certain three-letter competitor's software includes the feature
>    of keeping a list of the last 10 passwords you've used, which makes
>    the following much harder to do:

    WE already have this feature available too.  I was a system manager
    at NASA and we had a command procedure that I think came from DECUS
    that will do just that.
    
    Regards,
    
    
    Keith R>

    re. -2
    
    The hack is sitting in Tollshed at the moment.
    

    RE. .106 And god help ya if someone gets hold of the list of
    your ten last passwords - they'll have you "patterned" in a jiffy,
    
    
    1. CHOCOLATE
    2. VANILLA
    3. STRAWBERRY
    4. COFFEE
    5. FUDGERIPPLE
    6. COOKIESANDCREAM
    7. CHOCOLATECHIP
    8. MAPLEWALNUT
    
    figure it out !

       What! No Rocky Road?
                                                   Denny

    Oh, heck ! Now I gotta change it again. Thanks, blabbermouth ;-)

    See what I mean ? How many "ice cream flavors" would a hacker have
    to try ? That list is a key do decoding the user's pattern of
    selecting his passwords.

    I haven't looked at the "hack" in question, but I would hope that
    a "security" program would be able to store the hashed password,
    and not the source.  Otherwise, you've taken security back to the
    old RSX days when ANYONE could type out the password file.

    Jim