[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference abbott::mailworks-vms

Title:MailWorks for OpenVMS
Notice:kit info notes 3-6; policies note 2; reporting bugs note 7
Moderator:KOALA::LAVASH
Created:Wed Jul 28 1993
Last Modified:Mon Jun 02 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1583
Total number of notes:6814

1578.0. "How to use new TCP Logicals" by VMSNET::J_COLBURN () Mon May 12 1997 22:13

    Hi,
    
    My customer, Dames and Moore wants to know exactly how two new
    MAILworks TCP logicals are supposed to work.  He wants to know under
    what conditions they would be used. Help....
    
    The logicals he is interested in are:
    
    DMW$TCP_PROBE_TIMER
    DMW$TCP_DROP_TIMER
    
    Thanks.
T.RTitleUserPersonal
Name		DateLines
1578.1Anyone there???33998::COLBURN_JThu May 22 1997 18:035
    Could someone please take a look at this and respond.  This customer
    says that he wants to use these logicals but he doesn't want to break
    anything else and since there is nothing documented about these, he
    needs to know what they are intended to do/resolve/etc.  Thanks.
1578.2Same questions asked - some ideasKERNEL::16.182.96.116::houldingjFri May 23 1997 04:2958
Hi

I asked the same question last year for one of my customers - these are the 
replies from Engineering - I hope they help

Regards

Jill

***************************************************************************
>Please can you give me default values for MailWorks probe & drop timers if 
>the logical names DMW$PROBE_TIMER & DMW$DROP_TIMER are NOT defined, (in 
>ICF034).

The default values are:

        DMW$TCP_DROP_TIMER      =       600
        DMW$TCP_PROBE_TIMER     =        75

>How does the value of DMW$TCP_TIMEOUT interact with those of the DMW$DROP 
>& DMW$DROP_TIMER?  Does it override the specific values?

The Release Notes state:
DMW$TCP_TIMEOUT can now be used to control the timeout period when 
MailWorks is sending buffers to a Client via TCP/IP. The 
DMW%TCP_PROBE_TIMER and DMW$TCP_DROP_TIMER logicals can be used to achieve 
a timeout when a PC is no longer available but DMW$TCP_TIMEOUT can be used 
to avoid the extra network traffic incurred with short probe timer values."

The DMW$TCP_TIMEOUT is per buffer.  So for every buffer sent the timeout 
will start again.  If one buffer fails then the connection is broken.

The extra network traffic referred to is a result of: A shorter Probe time
means more network probing which means more network traffic.  So instead of
using the DMW$TCP_PROBE_TIMER logical set the DMW$TCP_TIMEOUT. The connect
server can only send one buffer at a time, so if a buffer takes a long time
(or hangs), the connect server would also look as though it was hung.

<How do these logical values interact with those defined in UCX?

These values only apply to MailWorks connections not to the whole of UCX 
and do override the UCX ones for the MAILworks connections.

>....would like a recommendation for all these values on a 2 node 
>AlphaServer cluster (MailWorks is the ONLY application running) Approx 180 
>users concurrently on each node.

Hopefully the logicals you are referrring to should never be required. 
However they were put into the patch to enable MailWorks to better cope 
with severe network problems typically when a PC dissapears in the middle 
of a data transfer.  This used to cause CPU and IO spikes.

It is difficult to give specific recommendations on these values as it will
depend largely on what is happening on your network. You need to relate the
values to the frequency of problems and how long you can tolerate waiting 
when a problem occurs.