Conference bulova::decw_jan-89_to_nov-90

Please, please, PLEASE tell us which version of VMS they are running!

When the "fileviews" disappear, do other applications on the screen
disappear?

Could you also post the contents of SYS$MANAGER:DECW$SERVER_0_ERROR.LOG?

    
>Please, please, PLEASE tell us which version of VMS they are running!

    Sorry. It's 5.3; I just got them a 5.3-1 CD, to which they plan to
    upgrade this weekend.
    
>When the "fileviews" disappear, do other applications on the screen
>disappear?

    Yes - anything started from the FV. I dunno if any SM-started apps were
    around, either before or after the event. Will check.
    
>Could you also post the contents of SYS$MANAGER:DECW$SERVER_0_ERROR.LOG?
    
    Will collect a couple today, if yesterday is any indication.
    
    There seems to be one guy getting really hammered by this - three times
    yesterday. The guy next to him (his boss) is doing the same things all
    day long; no problem. Of course everyone claims that I put something in 
    there saying "if Gary then..."
    
    On the plus side, Gary yesterday, while showing me the latest smoking
    crater, insisted that the FV interface to all there utilities was so
    much more efficient that he wouldn't think of giving up and just using
    a dcl prompt... his boss loudly seconded that. A week ago both of these
    guys were looking at one giantECTerm and using their myriad pre-defined
    symbols to navigate, kick off utilities, etc.
    
    I tutored Gary yesterday on adding his favorite home-grown verbs/menus
    - lightbulbs popping all over!
    
    Side comments to developers and sellers:
    This is a GREAT product; it was sort of dropped on this gang of macho
    programmers with no intro/training, and, of course, the initial
    reaction was "who needs that stuff; I've got this login.com I invented
    which creates an elegant environment - only wimps would use that". Then
    of course, the performance problems inherent in having little/no idea
    how to manage it, have them saying "I told you so - it's just a frilly
    boat anchor which would hurt me more than help me". We will be a while
    recovering some of these guys!
    
    A  10-minute one-on-one works for many, but not if they've been burnt
    and closed their minds. Result? the salesman gets blamed for selling a
    high-priced memory-hogging piece of #%^&. It seems to me that the
    troubleshooting guide being discussed elsewhere, and a CBI "Users intro
    to the neat stuff you can do" should be very high priority. Then nobody
    should sell it without insisting on the users being exposed to the
    intro.
    
    We tried to get their internal support people to pave the way with such
    a tutorial, and it woefully missed the mark. The intro has got to be
    prepared by people who appreciate the product; in our case, that means
    other software engineers - who better than the developers! 
    
    Sorry for leaping on the soapbox here, but its frustrating to see
    really good products getting a poor reception due to an incomplete
    definition of the product distribution process. DEC builds great stuff,
    ships it, and hopes the users appreciate it. Some of them don't
    know how to unwrap it - what's the old joke about the guy complaining
    that he couldn't chop trees down as fast with the chainsaw somebody gave
    him? 

Thanks very much for the information and the encouragement.

First on the FileView problem: if it happens to one fellow and not another,
it does sound like quota problems.  Could you also post the SYSUAF entry
for the working account and the failing account?

On documentation: I wrote a DECUS talk on "Customization in DECwindows"
that certainly be renamed "User's intro to the neat stuff you can do".
I'll discuss this with the documentation group to see if they could
turn this into a chapter in the DECwindows User's Guide.

    One other thing you could try is to run FileView interactively
    from a DECterm. That way if it ACCVIOs or aborts you'll be able
    to capture the information and post it here. 
    
    The process to do this is:
    
        - remove FileView from the AutoStart list
    	- create a dedicated DECterm for the FileView image
    	- in the DECterm, just type "run sys$system:vue$master"

    re -.1 and -.2: I'll follow up today or tomorrow. Meanwhile, I
    collected the following DECW$SW.log:
    
    %DCL-S-SPAWNED, process GOTTLIEB_1 spawned
    XIO:  fatal IO error 65535 on X server "GOTLEB::0.0"
    %NONAME-F-NOMSG, Message number 02DB821C
    -NONAME-F-NOMSG, Message number 02DBA002

    A ps: Gary has observed that whenever this happens, the "vanishments" are
    preceded by the system forgetting what his logicals are - he sees a DCL
    procedure croaking with file-not-found error messages, when minutes
    before it properly translated the logical and found the file.

    re -.whatever, regarding account parameters:
    
    maxjobs	0	fillm	80	bytlm		65536
    maxacctjobs	0	shrflm	0	pbytlm		0	
    maxdetach	0	biolm	40	jtquota		2048	
    Prclm	10	diolm	40	wsdef		1024
    prio	4	astlm	100	wsquo		2048
    queprio	0	tqelm	20	wsextent	8192		
    cpu		(none)	enqlm	200	pgflquo		40000
    
    The system manager insists all people in this group have identical
    parameters. Gary sayas it hasn't happened to him in a while now;
    bnnut he STILL gets the "disappearing logicals" problem.
    
    I saw it happen to another guy yesterday, who claims it's common. I 
    was helping fix an lse startup command procedure problem - I tried to 
    open another view, and pow!
    
    
    Do the error message value 65535 and the bytlm of 65536 have any
    relationship? I've gotten several other sm logs which always say 
    "XIO fatal error 65535 on X server..."
    
    I dunno what the message means, nor what bytlm is, but they look
    interesting.
    
    

    This may be a related question, may be something else entirely. 
    
    I've observed that various utiliies when started from fileview have
    slightly different behavior with respect to the "stop task"/"dismiss"
    widget. Most simply go away when you click "stop task". Some take the
    parent fileview with them. I've assumed that this was sloppy
    programming (since I THINK all the nasty ones are dcl procedures I
    wrote or untrained customer-types wrote). If the same application is
    allowed to complete (ie, let the widget change to "dismiss", then
    you're ok. The problem ones are generally cases where the verb executes
    a dcl procedure, like "monitor process" or something. It's necessary to
    give the ctrl/z within the popped-up dcl window to "terminate" the
    function (ie, if it were a dumb terminal, get the dcl prompt back) to
    get the "dismiss" button.
    
    I thought this was sloppy programming, and figured I needed to RTFM,
    or get the customer to, but I have just tried to duplicate the problem
    on my standalone system, and cannot. So now I suspect it may be more of
    an idiosyncracy of their installation, related to this basenote. I've
    also not been able to get fileviews to blow away on my standalone,
    although its harder to know what should make it happen. I created some
    40+ fileviews and decterms, juggled them all over the place, iconized,
    stretched, squeezed, etc as fast as I could. Solid as a rock. Same
    distribution CD!
    
    My parameters are generally much lower than are the customer's except
    for enqlm, which I have at 2000 (dunno why - I guess some application
    wanted it that way).
    
    This is a mystery well worth solving - the product CAN be solid, but
    the customer sees it as fragile. We (DEC) can't tell them why. 
    

    This occurred twice today in rapid succession to the department head. I
    was trying to talk him through some stuff on the phone - had several
    fileviews up, and pow. He started a new fileview, got about two or
    three steps into the process we were doing, and again pow. I had him
    logout/in, then it was ok. Ths DECW$SM log had the same error message
    as the others posted here previously.
    
    Isn't ANYBODY out there seeing this behavior? 
    
    Doesn't ANYBODY have a suggestion?
    
    Incidentally, the other day i was attempting to start a new fileview
    and got a reasonably polite "you have exceeded your bytlm" message, and
    had to log out/in to proceed. 
    
    Don Cooley
    

No, you're not alone.  No, you're not crazy.  There is at least one real problem.

If this is happening with a customer, then you need to pursue it thru your
normal channels, whatever those are.  I don't think anyone has any explanation,
or fix, for the problem.  I should QAR it, but this problem requires more
investigation than I can afford and it is lower in priority than the 6-8 other
QARs I've entered today.  Please pursue it; I'd love to see a fix.

    I know this is probably old news, but I was catching up on this
    conference and, having recently read the DECwindows release notes,
    thought I might add my 2 cents worth...
    
    The release notes mention the quotas that are check by FileView with
    the most critical being Prclm, Bytlm, and Pgflquo.  
    
    Each application runs a variety of subprocesses, thus Prclm (process 
    limit) should be a rather high number.  On my 3100, I have it set to 64.  
    
    FileView requires a Bytlm of abut 10000 to run, with an additional 5000 
    for each application.  On my machine, where I do a lot of graphics and 
    display intensive applications, by Bytlm is 512000.  
    
    The most insidious parameter is Pgflquo.  Most applications don't start 
    to consume Pgflquo until they're running.  When the limit is reached, 
    the application will crash.  On my machine, I have it set to 80000.
    
    This may have nothing to do with your problem, but it would appear that
    the quota's shown in .7 could be increased.
    
    Good luck!
    
    Ron Ravey