Conference bulova::decw_jan-89_to_nov-90

    Could you please give us some typical values that would make the server
    more reliable, without causing any big pain to the whole system (I
    mean, so the server doesn't have a pathologic behaviour).
    
    
    Pierre.

    Well, the default values were supposed to be reasonable, but as Edith
    implied, the timing came out to be 10ths of milliseconds instead of
    milliseconds.  Thus, if you multiply the retry interval default values
    will see more what we intended.
    
    Actually,  you might try leaving the retry interval the same and
    multiplying only the number of retries.  That will give it more chances
    to succeed before it finally gives up.
    
    Burns
    

A few questions about defining these logical names:

1. When can they be defined? On a running server, strictly at server startup,
   between successive "session quit/session start" pairs?

2. What logical name table should they be defined in? System, DECwindows?

I'm very anxious to experiment with these. The default values make it difficult
to do interactive transformations on moderately complex GObE and NetEd objects
from remote clients without having connections aborted. Several products that
use GObE and NetEd have reported this problem to us and I'd love to have a
solution, or at least a temporary workaround.

Thanks,

Kelly

They should get read every time the server resets (that means at startup and
everytime you log out...when the cursor moves itself to the middle).

As to the table, the server looks in LNM_FILE_DEV, but it has previously
modified LNM_FILE_DEV to have DECW$SERVER0_TABLE at the beginning (assuming
server 0, which is the only one we support).  Thus you should be able to
put it in the SYSTEM table, as long as it does not appear in DECW$SERVER0_TABLE.

Burns

    Re:.3
    
       I would just define them in the DECW$SERVER0_TABLE to play it safe.
    
    Re:.1
    
       You can define them as what Burns has suggested, or just make them
       10 times the default values. That should give you a longer, yet
       tolerable retry period, so you can get your work done.  This is
       strictly for V51 server.
    
    
    	Edith

    Sorry, I meant to say for version 1 server.  There is no change
    on this for v52 server either.  But on version 2 server(no idea which
    version of vms it would tie in), I plan to change the default retry 
    interval unit to ms, so that the retry interval will be every 1.5 cpu sec.,
    and a total of 20 retries.
    
    
    	Edith
    

    For the v52 decwindows server, these two logicals are pre-defined
    to different values in the decw$startserver.com.  After some 
    experiment, we found a smaller interval and more retries to be
    a reasonable setting.  So they are set to be .5 second interval and
    60 retries.
    
    		Edith

    For DECnet connections, what about making the retry period as long as
    DECnet time-out for links (is it 240sec time-out by default). That
    would make the whole lot consistent, wouldn't it ?
    
    
    Pierre.

    We are interested only to keep the server alive, and a reasonably short 
    delay, approixmately 30 seconds, is about as much as we can tolerate.
    But you can always experiment with setting the max to the decnet
    timeout value to see whether it helps in your environment. 
    
    	Edith

    Please, oh, please - Am running VMS 5.2-42W and for two main remote
    applications (DECwrite and BOOKreader) I can only maintain a remote
    link for, on good days, 5 to 10 minutes without getting XLIB IO ERROR.
    
    My default settings are as follows:
    
    	DECW$SERVER_RETRY_WRITE_MAX = 30000
    	DECW$SERVER_RETRY_WRITE_MIN = 500
    
    Have tried setting them to 1000000 and 25000, respectively. If anything
    it got worse. But the problem is real sporadic.
    What should I have them set to?
    
    [extra]
    	Have not been able to test this out yet but have others which
    are plauged with the same problem, they are on THINWIRE (like me).
    Got a person on THICKWIRE, and he swears that he never sees the
    problem. Could this somehow be related to the problem?
    
    Please respond,
    jjjones/Colorado CSC DECwindows Support

    What is the network load on the machine you are running DECwrite from?
    Some users have suggested that the Xlib IO Error problems stem from
    network loading.  [This may be obvious to those in the know]  One user
    disabled recognition of boot requests on their boot member and he says
    that the error rate dropped considerably.
    
John

> Have not been able to test this out yet but have others which
> are plauged with the same problem, they are on THINWIRE (like me).
> Got a person on THICKWIRE, and he swears that he never sees the
> problem. Could this somehow be related to the problem?

I had similar problems with a VS2000 once when another person connected
improperly to the same thinwire port.  I experienced *very* slow decwindows
operation and droped links!  If this is your situation, I suggest you take
the following actions to see if it helps:

  1) Disconnect *everything* from the thinwire port (on the wall).
  2) Connect *only* your workstation.  Perform the connection *exactly*
     as described the the hardware users guide for your workstation.  Use
     *exactly* the same hardware/terminator/cable as described!
  3) Use the *as installed* defaults for the parameters you are twiddling.

I'll think you will then have a stable decwindows link situation.  You can then
try adding other hardware to the thinwire and see what happens.

    
    I occasionally go through the office looking for improperly terminated
    thinwire connections.  Using the standard DECconnect stuff in our
    offices you can tell a bad connection almost immediately - it usually
    is a "Tee" connector hooked to  the DECconnect box.  This usually means
    2 terminators in the office.  There can only be ONE terminator on this
    type configuration.  The standard problem is people with 2, 3 or more
    devices in their office with thinwire connections.
    
    

    I have been confused by some of the information in this note.
    
    In .0, it was stated that the unit for retry is 1/10 of a millisecond
    and that the default setting is 15000 or .15 seconds.  I don't think
    that math works, i.e. 15000 times 1/10 of a millisecond is 1.5.
    
    In .7 it was stated that the unit didn't change for v52 server.
    
    In .8 it states that the logicals are set in v5.2 startup files
    to have a retry of .5 second and 60 retries.  The values that I
    see in my server table are 500 for MIN and 30000 for MAX.  That
    would only be true if the unit were milliseconds.
    
    What's going on?
    Thanks,
    Mark

    No, this is not new math. It was a programming error internal to the
    server, which caused some confusion of the unit used in the retry 
    count for the vms V52 decwindows server.  For the vms V2 decwindows
    server, the default value for the write-retry logicals will be those
    stated in 197.8.  I apologize for the confusion caused.
    
    	Edith

Let's get all the info in one place.  Can someone in the know confirm or 
correct the following.

For the V52 server:

    The units are in mS.

    The default value for DECW$WSERVER_RETRY_MIN is 500 (i.e., 0.5 seconds).

    The default value for DECW$WSERVER_RETRY_MAX is 30000 (i.e., 30 seconds).

    The logicals should be defined /TABLE=DECW$SERVER0_TABLE in 
	SYS$MANAGER:DECW$STARTSERVER.COM

    To make the new values take effect, I must log out of DECwindows and back in
	again.

Please confirm or correct this information.

-Les.

Let's get all the info in one place.  Can someone in the know confirm or 
correct the following.

For the V52 server:

    The units are in mS.
***Correct

    The default value for DECW$WSERVER_RETRY_MIN is 500 (i.e., 0.5 seconds).
***Correct, except for the "w" in the name

    The default value for DECW$WSERVER_RETRY_MAX is 30000 (i.e., 30 seconds).
***Correct (again, except for the "W")

    The logicals should be defined /TABLE=DECW$SERVER0_TABLE in 
	SYS$MANAGER:DECW$STARTSERVER.COM

***No.  This will work, but the correct place to put them is in your
***SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM file, assuming you want something
***different from the default.  If you define these things as global symbols,
***the right thing will go into the right table.

    To make the new values take effect, I must log out of DECwindows and back in
	again.

***Correct.

Burns

    
    I'm running into this error on a VAXstation 3100 SPX with local
    connections. The server dies when it happens. (At least I that's whats
    causinag the server to die.)
    
    I know that there are some logicals that can be defined to get more
    logging info for the server, but I can't find them here in the notes
    file...
    
    Could some one point me in the right direction or provide an assist?
    
    Thanks -
    	Jan
    	dtn 533-7787

    You should always get a log DECW$SERVER_0_ERROR.LOG in SYS$MANAGER.

    
    Yeh- I know that, the problem is that there doesn't seem to be enough 
    (sometimes any) info to make a firm determination.
    
    I've seen reference to a logical name which would turn on a more
    detailed level of logging, but I just can't seem to find it...
    
    	Jan
    	dtn 533-7787

>    I've seen reference to a logical name which would turn on a more
>    detailed level of logging, but I just can't seem to find it...

There is no logical name to make the server log any additional information.

    
    Rats- Oh well, thanks for the help
    

    
    How about - DECW$SERVER_DUMP
    
    This should get a process dump on the server...
    

That is only if the server dies, and besides, I have never been able to do
anything useful with a server dump.

I think you'll find that if the server log does not say anything about a
process being thrown off, (with more than just "connection closed") that
it was not the server which initiated the shutdown (in particular it was not
because the event queue filled up.  I'm pretty sure there is a log message for
that.)

Burns

    
    I'm still trying to get solid information on these crashes. 
    
    The symtoms are that the user 'quits' via the session manager and the
    server goes away, no logo comes up, no login dialog box. In fact it's
    like being at an LA100 glass teletype...
    
    The server log file is either empty or has the error in the .-?
    note indicated...
    
    	Jan
    
    I was sure that some kind of logical name existed for increasing
    logging information. Maybe it was for the Session Manager?
    
    

    Jan,
    	Have you looked at the accounting data to see what the final
    	status for the server process was?  If you don't have accounting
    	turned on, please do so, as this data is useful.
    
    	Which version of VMS are you running?
    
    James

This looks like the same problem described in note 2665

There is now a patch available thru the CSC, more info
in 2665