Conference abbott::mailworks-vms

    Jan,
    
    The message, 'too long to log', indicates that the specified
    information was longer than the allocated amount of space for
    that particular field.  This information is purely informational.
    This information is being logged to the
    A1MAIL$TEST:A1MAIL$CONNECT_INFO_node.LOG file.
    
    This feature can be disabled by turning off CON logging for
    the A1MAIL$CONNECT process.
    
    In the example that was provided in the base note, the node name
    was longer than the allocated space for node name:
    1997032012452793 CON> Node, DEANGELISRJ.NPT.NUWC.NAVY.MIL, too long to
    log.     
    
    The maximum allocated space for node name is 28 characters.
    The maximum allocated space for user name is 16 characters.
    
    If either entry is longer than this and CON logging is enabled, then
    the error message will be put into the EVL log file for the
    A1MAIL$CONNECT process.  This user will have no entry in the INFO
    log file for the A1MAIL$CONNECT process.
    
    This error should not be a concern for the customer.
    
    The WARNING and OPEN CONTEXT messages on the other hand may be
    a concern.  Some suggestions include:
    - Verify that all open context are related to TL V2.7 clients
    - If the above statement is true:
      ? Are the users that are getting the warning and open context
        messages using a new feature to TL V2.7?
    - What action(s) do the users, that get the warning and open context
      messages, have in common?
    - Can the messages be reproduced on demand?
    - When the user disconnects, do the open context go away.  To verify
      this, look for a line similar to the following line:
    1997032617181245 CON>S0053ECE8, Client context statistics:
    0 folder, 0 message, 0 body, 0 find.
        If the folder, message, body and find values are all zero, then
        there is no memory leak and there is no concern.  If the users
        that are generating the warning and open context messages are
        also leaving context open on a disconnect, this is a memory
        leak and the memory leak should be investigated.
    
    
    It is true that the old TeamLinks clients had a memory leak.
    It is possible that a new feature may have introduced a memory leak
    or an old feature that was modified may have introduced a memory leak.
    
    Knowing what the customer is doing to get the warning and open context
    messages would greatly reduce the amount of time to find a resolution
    if there is a problem.  At this time one of the most helpful actions that
    could be done would be to try to determine what is causing these
    messages.  While you are working with the customer, I will talk to
    the TeamLinks Engineering team to see if they are aware of any
    memory leaks in V2.7.
    
    -diana

    Hi Diana,
    
     >- When the user disconnects, do the open context go away.  To verify
     >this, look for a line similar to the following line:
     >1997032617181245 CON>S0053ECE8, Client context statistics:
     >0 folder, 0 message, 0 body, 0 find.
    
     The customer looks at the log file on the server and folder, message,
    body, and find values are not 0. The customer says she can get the
    !!! Warning and Context warning messages to appear by opening several
    folders (6) without closing any.
    
    Tommy Williams
    

    As long as all context go back to zero when a client disconnects,
    then there is no memory leak.
    
    It is normal for the number of open context to fluctuate during
    normal execution of the client.  The number of open context increase
    and decrease due to various operations starting and terminating.  Examples
    of context being allocated include, (but are not limited to,) opening
    a drawer, opening a folder, opening a message, doing a search in
    a folder.  Examples of context being deallocated include, (but are
    not limited to,) closing a drawer, closing a folder, closing a message.
    
    In summary, I do not believe there is a problem at the customer's site if
    context go to zero when a client disconnects.
    
    -diana

    Diane,
    
    When the users disconnect, the contexts do not go to zero.  I'm
    thinking that this may be because the user is not closing all drawers
    and folders before disconnecting.  Would that cause the contexts to not
    go back to zero?  If so, could that cause memory leaks?
    
    There is another issue at this site.  There are several users that have
    many drawers and thousands of files in their A1MAIL$ directory.  I have
    told my contact that these drawers need to be moved to another
    directory to cut down on the number of files in a directory.  I've told
    her that the large number of files could be causing the slow response
    time that users are seeing when refiling messages to other drawers. 
    She tells me that the folks with this problem are management type
    people and unless she can show them something that indicates that this
    could be causing the problem, they don't want to move anything to other
    directories.  I've been looking at the Notes file for VMS to try to
    find something in writing about RMS tuning that I could send her but I
    haven't found anything appropriate.  Since I'm not an RMS Tuning
    expert, if you have anything I could send her or if you could comment
    on the above with engineering recommendations, I would appreciate it.
    
    The customer is telling me that all usera are seeing a slow response
    time when moving or refiling messages, not just the users with many
    drawers/messages.  Could those few users be causing a problem with
    slowness for all users?
    
    I'll get some answers to the questions you ask in .1.  Thanks for your
    help.
    
    Jan

    Diane,
    
    More information -
    
    We can produce the open context errors by doing the followin:
    
    Log into Teamlinks and connect to Mailworks
    
    Open several drawers
    
    Disconnect Teamlinks from the Mailworks Server, leaving the drawers
    open.
    
    This generates errors in the log file about open contexts.  The
    customer can re-produce the errors every time.  I haven't been able to 
    re-produce it here but I'm still trying.
    
    I need to know if these errors are appearing as open context errors,
    could they be causing memory leaks?
    
    Thanks

    I performed a quick test and left several applications open. 
    e.g A window Reading a Word doc
        A window reading an Excel doc 
    etc.
    and then exited TeamLinks ignoring the error indicating Applications
    launched from TeamLinks were still running.
    This resulted in Open contexts on Disconnect and might lead to a memory
    loss. I have not investigated this yet
    
    Regards
    Alan

    Opening a Word window even if the window is closed seems to leave open
    folders etc, and using the WPS-PLUS or WordPerfect viewer for example 
    from TeamLinks results in 1 folder and 2 messages, 1 body being left open 
    for each document read even when the Read Window is closed.
    
    I am using TeamLinks for Windows V2.7
    
    Does your customer manage to reproduce the error without reading any
    documents??
    
    Alan

    Alan,
    
    My customer says that she can re-produce this by just going in and
    opening various drawers and folders but its after she opens a lot of
    them.  She is not launching a viewer or any application.  She is mailing 
    me the log and will tell me how many folders were open. 
    
    I have again tried to re-produce the problem by opening applications
    and using viewers.  This is the result of my test:
    
    1997040715330706 SVR> 140111 of 144929 free pages still available
    1997040715380710 SVR> 140111 of 144929 free pages still available
    1997040723081058 SVR> 140111 of 144929 free pages still available
    1997040723131062 SVR> 140111 of 144929 free pages still available
    1997040723181065 SVR> 140111 of 144929 free pages still available
    1997040810082147 CON> Error occurred reading from INFO file; status: 1
    1997040810082160 CON>S0041F118, User colburn_j connected from node X4JAN
    1997040810082293 CON>S0041F118, User colburn_j Client API/SPI Versions,
    CFC 2.7, CFCX400 2.7.002
    1997040810131331 CON>S0041F118, Client disconnect request for user
    colburn_j,on node X4JAN.
    1997040810131335 CON>S0041F118, Client context statistics: 4 folder, 6
    message,3 body, 0 find.
    1997040810131343 SVR> User, colburn_j, not found when attempting to
    delete;status: 1
    1997040810131350 CON>S0041F118, Executing FCI_SERV_DisconnectAst, pass
    1
    1997040810131354 CON>S0041F118, Client disconnect and cleanup complete
    1997040810131619 SVR> 140111 of 144929 free pages still available
    1997040810181623 SVR> 140111 of 144929 free pages still available
    1997040810231625 SVR> 140111 of 144929 free pages still available
    1997040810281629 SVR> 140111 of 144929 free pages still available
    
    What I need to determine is whether she has uncovered a problem with
    Mailworks that could be causing the problems that they are having with
    A1MAIL$CONNECT.  If there is some relationship between a slow process
    and memory leaks, then we, DEC own the problem.  If not, then the
    customer owns the problem because her users refuse to fix the problem
    with large file cabinets and A1MAIL$.dir files that are much to big. 
    If that is the case, I can close this call out with recommendations
    that they need to get a VMS tuning Expert out there (for a price).
    
    Thanks for whatever help you guys can provide.
    
    Jan