Conference bulova::decw_jan-89_to_nov-90

    Maybe it's not a legitimate question?  A dumb one?  A company secret? 
    A secret to be withheld from me?  I ought'a know by now?  Out to lunch
    - I missed a key manual? - Wouldn't be the first time.  Y'gotta learn
    Xlib first before you can understand the VMS interface?
    
    I thought someone would have jumped on me by now.  The customer in the
    described situation sure did.  And then my boss wondered ... But I do
    not think anyone in the office knew as much or any more.
    
    Hunkered down - Fred

Fred, when you get your answer, pass it on to the rest of us! If there's
one thing I've learned over the last couple of years it's that I need to
learn a *lot* more about system management.

				-- Bob

RE: .0

>    How does one learn the software support aspects of DECwindows?

Trial and error.

--PSW

    RE -.1
    
    Trial and error.  I was afraid so.  Not so much for myself because I
    rather enjoy the method and have become somewhat impervious to those
    who cannot understand why the method is not very efficient.  As in:
    "that's what we pay you to know.  How come you don't?" When you've been
    around DEC ten years you sort of get a little numb to those sentiments
    and can eventually figure some things out. Is there anyone who can sit
    around the office and play with these things?  I have to do it at home
    and I consider myself lucky to have a VS2000 to do it with.
    
    But perhaps some of the younger folks don't think it is a fair game and
    the deck is stacked against them.  It is!  Even though my son is almost
    a lawyer now and talks about one of the principles of law being
    "fairness", I still do not believe in it.  There is no such thing. 
    Things just "are" or "are not."  
    
    In the DECwindows case, it now appears that the system management of it
    "is not" - at least yet not yet.
    
    However, I still do not believe there aren't a few good folks out there
    that can give us a some pointers to what we are looking for.  And someone
    must at least have some internally circulatable drafts of what I think
    MUST be included in the next major VMS doc set.
    
    Fred

RE: .4

>    And someone
>    must at least have some internally circulatable drafts of what I think
>    MUST be included in the next major VMS doc set.

What makes you think that guidelines on system management for DECwindows MUST
be included in the next major VMS doc set?  Actually, I'll be shocked if
there's anything of the sort in the next doc set.

As more of the Unix culture seeps over into the VMS world, I think we can
expect to see more of this sort of thing.  Things on Unix generally seem to be
more fragile than what we're used to on VMS, and when they break, they do so in
very cryptic ways.  Unix culture is to have a guru or wizard on site who is
experienced in analyzing and solving these sorts of problems.  How do the
wizards get their training?  Apprenticeship to another wizard, or personal trial
and error.

--PSW

    Ah, since I enjoy trial and error move over to the Unix world and
    find out how DECwindows works there? - Fred

    
    VMS has plans to include a troubleshooting appendix in a future release
    of the DECwindows documentation.   We know there is a need for this.
    Our knowledge in this area is currently contained in a few people's heads, 
    and doing mind dumps is going to be painful.  So, we could use some help.
    
    If you would like to see a troubleshooting guide, and you have had a
    problem that you solved, please enter a reply to this note
    documenting the problem and the solution.   Also, include the version
    of VMS and DECwindows that you are running.  Our documentation person
    will monitor this note and use the replies as input for the
    troubleshooting appendix.
    
    Thanks
    Karen

    Good Lord! This is scary! My customer has an LAVC with two servers,
    some 30+ vs3100's mostly doing heavy-duty sw engineering. Since they
    went to DECWindows, the system manager has been tearing out what little
    hair he has left. Since he's not been to LAVC training, nor "DECWindows
    system manager" training (mythical course?) the general concensus has
    been "this is what we get for trying to learn how to do this by trial
    and error". 
    Now you're telling me nobody knows how to manage this beast! 
    
    I'm beginning to understand why the CSC tends to duck questions "that's
    a system management problem, not a product question - sorry" and sw
    consultants sent out to advise tend to scuttle away quickly. One left
    the company!
    
    But seriously, this is a VERY important issue. 
    
    The main problems we've seen, after terrible performance issues which
    were alleviated by creating dual system disks, are in the area of
    things going away for undefined reasons. I've gotten as far as
    concluding that it has to do with "the parameters", whether system or
    user account, or some combination. You can read DECWrite mail at one
    seat, not at another. Do too many things quickly and all your fileviews
    and associated applications disappear. 
    
    One very serious gotcha was in the system manager's initial approach.
    Not having a clue as to how to set things up, he just did something or
    other and then started running autogen often. So people who used a lot
    of fileviews started getting parameter creep in one direction, others
    got other responses. Then they sit down at a different chair - guess
    what!
    
    The recent decision is to pick someone who seems to be able to do what he
    wants, and give the same parameters to everyone else. Then don't use
    autogen. Then if something breaks, fiddle and hope. If you get it
    right, do that to everyone else. 
    
    This is pathetic! But is that all there is? Surely there's some sort of
    best-guess recommendations. Various products (like DECDecision) make
    overt recommendations, and even warn you if you start up without the
    recommended quotas. 
    
    
    
    

    Well, since I started it, I'll continue.  Maybe another conference I
    just found can give a clue:
    		4TRACK::DECWINDOWS_DOCUMENTATION
    I will be going there this weekend to see what it contains.
    
    I am greatly encouraged by the last few responses.  I hesitated to put
    in the original entry.  I guess you can read between the lines.  When
    going through the first problem early this year I really was wondering
    where I had missed the game; ie, what was wrong with me.
    
    Darn, I always assume the other guy knows more than I, and then suffer
    for it until it becomes obvious that is often not the case.
    
    Keep the "war stories" coming.  Let's take the doc folks at their word
    that we can have some influence on this very serious problem.
    
    Fred

    Didn't find much in DECWINDOWS_DOCUMENTATION on this subject.  I
    cross-posted my .0 there.
    
RE: 3195.5 PSW::WINALSKI
    
>be included in the next major VMS doc set?  Actually, I'll be shocked if
>there's anything of the sort in the next doc set.

    Wowie, don't we want to sell any more VMS DECwindowing VAXstations and
    DTWs?  There does seem to be some documentation coming, though, by one
    of the other replies.  Hope it comes to pass.  I put in my first war
    story. The second is related to the following.
    
    I just stubbed my toe on Destktop VMS for the first time.  Good
    concept, but I hope I do not smell the aroma of the PRO 350, Rainbow
    and VAXmate scenerios. Conceptually that was a good idea too. I have
    had one experienced customer already say essentially the same thing on
    a loaner we gave them: "It is not regular VMS, where everything is
    where it's always been."  It was the version based on VMS051 though and
    perhaps things are better with the now shipping version based on
    VMS053.  Personally, on the machine I had control of, a VS3100/48, I
    put on a regular copy of VMS053.  I know of one other DEC specialist
    who agreed (it was his unit, he tried it, wanted the regular stuff, so
    I did it for him during his vacation).
    
    >As more of the Unix culture seeps over into the VMS world, I think we can
>expect to see more of this sort of thing.  Things on Unix generally seem to be
>more fragile than what we're used to on VMS, and when they break, they do so in
>very cryptic ways.  Unix culture is to have a guru or wizard on site who is
>experienced in analyzing and solving these sorts of problems.  How do the
>wizards get their training?  Apprenticeship to another wizard, or personal trial
>and error.

    On unix wizards and such:  I just finished reading Clifford Stoll's
    "The Cuckoo's Egg", Doubleday, 1989.  It is really about computer
    security but gives a lot of insight into the Unix world for a neophyte. 
    It should be required reading for all software folks.  Has the flavor
    of a soapy love story too.  Just saw him interviewed on TV, sitting
    monkey style in front of a (Sun?) with yo-yo in hand.
    
    Fred

>>be included in the next major VMS doc set?  Actually, I'll be shocked if
>>there's anything of the sort in the next doc set.

	Some comments (coming from former system manager, now software
	specialist, supporting, among other things DECwindows):


		- there is already a DECwindows troubleshooting guide
		  out - this might be a good place to start.  Developed
		  by someone at the CSC - name escapes me...

		- the U*x culture is used to getting access to sources.
		  These people are astounded when they can't information
		  on the most basic things, like resources, when using
		  VMS.  We often go to the U*x docs for this kind of info...
		  
		- some topics that might be covered:

			- how to make a turn-key DECwindows application 
			  for the production floor (turning off session
			  manager, resources, ect)

			- things NOT to do as system manager (cpu time
			  limits on accounts, idle process killers, inquire
			  statements in logins and sylogins...)

	My 2 cents...

	Rick 

    The two biggest problems I've seen have to do with too little resource
    allocation done with AUTHORIZE, and PAGE & SWAP file limitations.  I've
    included the parameters I use on my VS3100/48.  It's very heavily loaded
    with apps.  The problem with page and swap files generally has to do
    with machines in a cluster.  The system manager. who isn't familiar
    with workstation requirements gens each ws os just like he would
    another time-share machine.  It just ain't big enough.  You end up
    with page files on the order of 10K blocks or so.  50-70K is more like
    it. It's like Paul said.  After playing with this stuff for a couple of 
    years you develop a feel.  Note that if things like PGFLQUOTA and BYTLM 
    are too small, users machine tend to lock up, because the've run out of 
    allocated resources. (Read: memory). I'm not a VMS expert, but these have
    been working for me.
    
    Username: SYSTEM                           Owner:   SYSTEM MANAGER
    Account:  SYSTEM                           User ID: [1,4] ([SYSTEM])
    CLI:      DCL                              Tables:  DCLTABLES
    Default:  SYS$SYSROOT:[SYSMGR]
    LGICMD:   LOGIN
    Flags:
    Primary days:   Mon Tue Wed Thu Fri
    Secondary days:                     Sat Sun
    No access restrictions
    Expiration:            (none)    Pwdminimum:  8   Login Fails:     0
    Pwdlifetime:           (none)    Pwdchange:      (pre-expired)
    Last Login: 20-AUG-1990 09:23 (interactive), 20-AUG-1990 09:24
    (non-interactive)
    MaxJobs:         0  Fillm:       100  Bytlm:        10240
    MaxAcctJobs:     0  ShrFillm:      0  Pbytlm:           0
    MaxDetach:      20  BIOlm:       120  JTquota:       1024
    Prclm:          20  DIOlm:       120  WSdef:         1200
    Prio:            4  ASTlm:       120  WSquo:         2048
    QuePrio:         0  TQElm:        20  WSextent:     20000
    CPU:        (none)  Enqlm:       650  Pgflquo:      45000
    Authorized Privileges:
      CMKRNL CMEXEC SYSNAM GRPNAM ALLSPOOL DETACH DIAGNOSE LOG_IO
      GROUP ACNT PRMCEB PRMMBX PSWAPM ALTPRI SETPRV TMPMBX WORLD
      OPER EXQUOTA NETMBX VOLPRO PHY_IO BUGCHK PRMGBL SYSGBL MOUNT
      PFNMAP SHMEM SYSPRV BYPASS SYSLCK SHARE GRPPRV READALL
      SECURITY
    Default Privileges:
      CMKRNL CMEXEC SYSNAM GRPNAM ALLSPOOL DETACH DIAGNOSE LOG_IO
      GROUP ACNT PRMCEB PRMMBX PSWAPM ALTPRI SETPRV TMPMBX WORLD
      OPER EXQUOTA NETMBX VOLPRO PHY_IO BUGCHK PRMGBL SYSGBL MOUNT
      PFNMAP SHMEM SYSPRV BYPASS SYSLCK SHARE GRPPRV READALL
      SECURITY
    

First and most important point about entering a problem you encountered:
we need the exact version of the software you were running at the time.
We have fixed many, many, many problems since VMS V5.1, and we are not
interested in hearing about a problem we've already fixed.

Second, the type of problem we would particularly like to hear about
are problems where the workstation was behaving very strangely and the
solution was not obvious.  We will even publish workarounds if we don't
know the real solution.

Third, the effort to write a trouble-shooting guide for DECwindows V3
is a cooperative effort between the VMS Engineering and VMS Documentation
groups.  We have heard rumors of a DECwindows trouble-shooting guide in
the field, but we have not actually seen this thing, nor do we know whom
to contact.  If you are the author, please contact us!  We would like to
incorporate this into our official documentation.

The general idea of the trouble-shooting guide is to help customers
solve their own problems when something simple goes wrong with DECwindows.
It is not intended to be a complete system management guide to DECwindows.

Note that Desktop-VMS is a completely different subject from DECwindows.
Please enter Desktop-VMS war stories in a separate topic.

>We have heard rumors of a DECwindows trouble-shooting guide in the
>field, but we have not actually seen this thing, nor do we know whom
>to contact. 

Try "VMS DECwindows Troubleshooting/Support" EY-9460E-LO by Dave 
Bryson.  It is an ED Services class, pretty big, but has a lot of good 
info.  I don't think it has been updated since 5.1, however.

Other bits and pieces, like setting up a captive account, are in the 
FSIN (DSIN, STARS) database.  I haven't heard of anything better than 
autogen for sysgen parameters.

Bruce

Starting, I believe, with VMS V5.3, a number of people have found that they 
suddenly can't log in.  The login box and the logo goes away as it should but
nothing else starts up.

A common reason for this problem is that something in either SYLOGIN.COM or
the user's LOGIN.COM is assuming that the input device is a terminal.  For
example, it may have $SET TERM/INQ, or $INQUIRE.  Rather than search up the
appropriate test to see if you are on a workstation, I'll point you to the
release notes, and also the SYLOGIN.COM on DECWIN.

Burns

It seems that GBLSECTIONS and/or  GBLPAGES are frequently set too low when
systems are installed initially.  This limits the number of sessions that you
can have with LOCAL transport.  ENQUEUELIM can have a similar effect.

Burns

RE: .10

>>be included in the next major VMS doc set?  Actually, I'll be shocked if
>>there's anything of the sort in the next doc set.
>
>    Wowie, don't we want to sell any more VMS DECwindowing VAXstations and
>    DTWs?

Hey, I'm just describing the reality of the current situation.  I didn't say
that I like it or that I think it's the way things should be.  Actually, I've
been rather pleasantly surprised about the quality of X Windows.  It's a notch
or two above the usual crap that passes for software coming out of university
research projects.  The DECwindows engineers have also done a yeoman's job of
whipping it into production shape.

Still, we are entering the age of Open Systems = Unix.  For the VMS world, this
is going to mean that a lot of stuff from now on is going to be an order of
magnitude less reliable and an order of magnitude harder to maintain.  Better
get used to it.

--PSW

    No criticism of any individual intended, least of all you.  I too think
    that the DECwindows folks did a fantastic job. I love it and want to do
    the best job possible supporting (and selling) it.  But didn't one
    reply mention that someone left the company over this?  I'd like to
    know a little more about that.
    
    Most of my comments on subjects like this smack of other pet pieves:
    
    	Undated documents.
    	Incomplete or totally lacking indexes for complicated products.
    
    Why should I expect to get a complete set of instructions when I buy a
    shovel?  I should be more understanding of the builders who have used
    it so much they expect everyone else to know how.  I understand that,
    I've done it myself. But I have also been "beat up" for it too.  I
    usually like to read something to death (or at least until I get sick
    of it) - and then try it.  Yeah, I know I am different - personal quirk
    and background, I guess.  No one seems to have the time to do things the
    right way anymore.  What is the right way anyway?   The bucks in the
    pocket this quarter?  I guess so, its an old axiom; if you don't eat
    and drink today, you will not be around next week.
    
    Fred
    
    Fred

re: .17 (PSW)

>Still, we are entering the age of Open Systems = Unix.  For the VMS world, this
>is going to mean that a lot of stuff from now on is going to be an order of
>magnitude less reliable and an order of magnitude harder to maintain.  Better
>get used to it.

Don't ya just love it!  A few of us around here (programmers, of course) joke
that after all the finance-types embrace "open systems" 'cause they think it
means cheaper computer systems, 90% of applications will be written in cryptic
C running under U*IX.  Can you imagine the armies of programmers who will be
needed to maintain this crap?  And think of the salaries once the suckers are
locked in!  I can get used to that very easily.

Paul