|
ICF37 Announcement
==================
Kit Name:
A1MAIL_FIX037013_ALPHA.BCK
A1MAIL_FIX037013_VAX.BCK
MailWorks for OpenVMS Engineering announce the availability of the
latest FIX patch kit. The kit is available on request.
To recieve a copy please send mail to myself (IOSG::REESA).
This kit can be installed on 1.3A-3 (ECO3) and obsoletes all previous
ICF kits.
The following README_37.TXT outlines the problems fixed.
Regards,
Arfon Rees.
MailWorks Project Manager.
This file describes the installation and contents of patch
A1MAIL_FIX037013_<arch>.BCK.
The patch consists of two savesets: A1MAIL_FIX037013_VAX.BCK for Vax
systems and A1MAIL_FIX037013_ALPHA.BCK for Alpha systems. The relevant
saveset must be used depending on the machine architecture in use.
Both of the patch savesets contains of the following images:
A1MAIL$SHARE.EXE
A1MAILDOSSHR.EXE
A1MAILMACSHR.EXE
A1MAIL$CONNECT.EXE
A1MAIL$DS_SERVER.EXE
A1MAIL$PRINT_SERVER.EXE
A1MAIL$CCT_MAIL.EXE
CTISHR$DECNET.EXE
CTISHR$DSL.EXE ! Not supplied for ALPHA saveset
CTISHR$TCPIP.EXE
MUAS$CLIENT_SHARE.EXE
MUAS$MRIF_SHR.EXE
MUAS$SERVER.EXE
MUAS$SERVER_SHARE.EXE
MUAS$SHARE.EXE
MUAS$SM_SHARE.EXE
MUAS$TRANSLATOR_SHARE.EXE
X400$SSI_SHARE.EXE
MailWorks for OpenVMS V1.3 ECO-3 must have previously been installed
before the application of this patch.
A procedure, PATCH_INSTALL.COM, is also provided in the saveset.
This should be used to install the patch. To run the command
procedure, do the following:
1. Unpack the .EXE images and the command procedure from the saveset
relevant to the machine architecture to the SAME directory.
2. Run the command procedure from the SYSTEM account:
$ @PATCH_INSTALL
Problems Resolved by this Patch
-------------------------------
1. If an error occurs while looking up an address in DDS then this can
result in the A1MAIL$DIRECT_... process being terminated.
Note that after installation of the patch:
Time-out notification will now take longer than the DS_TIMEOUT
value, if the time-out resulted from a large number of matches being
found during remote DDS lookups.
2. If an access violation occurred in the connect server
(A1MAIL$CONNECT) on an ALPHA architecture system then this resulted
in an access violation in the condition handler itself.
3. Additional checks have been added prevent access violations in the
Connect Server. Also, additional logging has been added so that
more information can be gathered on events that previously caused
these access violation to occur.
4. CPU looping and IO Spikes can be experienced if there is a problem
while communicating with a client via TCP/IP. This in turn resulted
in all other clients being unable to communicate with MailWorks
until the bad connection timed out via the TCP/IP time-out Although
it is strongly recommended that the network problems that cause
these server hangs should be investigated and any necessary tuning
implemented, a logical DMW$TCP_TIMEOUT can now be used to control
the time-out period when MailWorks is sending buffers to a Client
via TCP/IP. The logical can be defined to contain the time allowed
when attempting to send a buffer. The value supplied must be in the
delta time format - 'dddd HH:MM:SS' . e.g.
$ DEFINE/SYSTEM DMW$TCP_TIMEOUT 0 ::20
This will define a time-out period of 20 seconds.
A time-out period of 10 minutes will be used if the logical is not
defined to contain a valid number. Note a new value will only
become effective after the connect server is restarted.
The DMW$TCP_PROBE_TIMER and DMW$TCP_DROP_TIMER logicals can be used
to achieve a time-out 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.
5. TCP/IP Send and Receive buffer quotas can now be set via system
logicals. This allows a larger buffer quota to be used for MailWorks
without affecting the rest of the network. Tests have indicated that
setting the TCP/IP buffer quotas to twice the maximum MailWorks
buffer size (4096) helps avoid buffer full bottlenecks. e.g.
$ DEFINE/SYSTEM DMW$SEND_BUFFER_QUOTA 8192
$ DEFINE/SYSTEM DMW$RECEIVE_BUFFER_QUOTA 8192
Note these values will only become effective after the connect
server is restarted. A Default value of 4096 is used if these
logicals are not defined.
6. Messages with attachments larger than 3Mb now display the size
correctly. The maximum value for the size field has been increased
to 100000 blocks (50Mb)
Note that TeamLinks displays a corrupt string for the size of
messages larger than 32Mb.
7. New mail notification messages are now sent from ALPHA systems to
TeamLinks for Mac users connected via Appletalk-Decnet Gateway
8. New Mail notification messages, broadcast to TeamLinks users are
often delayed. In extreme circumstances this delay can become
excessive.
This problem is particularly prevalent where TeamLinks users have
requested New Mail Notification, but have not set the "Disable when
disconnecting from mail service" flag. In these circumstances the PC
broadcast handler does not know that a users PC is disconnected, it
attempts a network broadcast regardless, which incurs a default
time-out typically of 40 seconds per message. TeamLinks user's
should therefore attempt to ensure that they have set their New Mail
Notification option to "Disable when disconnecting from mail
service" and that they always exit from TeamLinks properly.
To avoid problems resulting from long network time-outs, the default
time-out has been reduced to 10 seconds. This default time-out value
can also also be dynamically overridden by the use of logicals. To
change the length of this time-out period for any network transport
use the following system logicals:
DMW$TCP_NOTIFY_TIMEOUT - for TCP/IP type network broadcasts
DMW$DEC_NOTIFY_TIMEOUT - for DECNET type network broadcasts
For any of these values, specify the length, as a standard VMS delta
time [d hh:mm:ss] of the new network time-out period. For example,
to set the time-out period for TCP/IP type network broadcasts to 5
seconds, define the required logical as follows:
$ DEFINE/SYSTEM/EXECUTIVE DMW$TCP_NOTIFY_TIMEOUT "0 00:00:5"
Similarly if necessary, the time-out can be increased from the 10
second default value to cater for any slow PCs that do not respond
within this period.
A notification message will not be delivered if the time-out period
expires when attempting to deliver the message
It should be noted that the above changes can only reduce the delays
experienced due to disconnected PC users. It is still recommended
that disconnected PC users should be removed from the notification
table whenever possible. This can be accomplished by periodically
deleting the A1MAIL$LIBRARY:A1MAIL$NOTIFY.DAT file and restarting
the MUAS server. New Mail Notification will then need to be
reenabled for Users when they connect. Also TeamLinks users should
be encouraged to disable mail notification when they disconnect.
Note that the Enable/Disable new mail notification option in the
TeamLinks (V2.7) Notification window itself can be used if
notification is required when TeamLinks is not active.
9. A new TeamLinks Client version logging feature has been implemented.
This feature can be used to help isolate PC users who may be using
old versions of the TeamLinks for Windows client.
Version logging is enabled whenever additional connection tracing is
enabled. To enable additional connection tracing define the system
logical name as follows:
$ def/sys A1MAIL$CONNECT_INTERNAL_TRACE "CON"
Extra logging lines will then be added to the
A1MAIL$TEST:A1MAIL$CONNECT_EVL_nodename.LOG file.
An example of an entry for a TeamLinks V2.5-003 Client connecting
follows:
1996101609413997 CON>S0027D618, Connect request from user dmw_20,
node myownpc.reo.dec.com.
1996101609414026 CON>S0027D618, User dmw_20 connected from node
myownpc.reo.dec.com
1996101609414217 CON>S0027D618, User dmw_20 Client API/SPI Versions,
CFC 2.5, CFCX400 2.5.004
Note that only TeamLinks for Windows Clients V2.5 and later will
cause the Client API/SPI version logging to occur. Thus any entries
that omit this line indicate a user that is not using TeamLinks for
Windows V2.5 or later. The CFCX400 versions indicated correspond to
specific versions of the TeamLinks Client as indicated below:
Also the connection Log entries due to DDS lookups will not have the
extra logging line indicating the Client version.
TeamLinks Version CFCX400 CFC
V2.1 SSB and
V2.1 ECOs no entry logged for API/SPI Version
V2.5 SSB 2.5.002 2.5
V2.5-002 2.5.003 2.5
V2.5-003 2.5.004 2.5
T2.7(EFT1) 2.7.000 2.7
T2.7(EFT2) 2.7.001 2.7
T2.7(EFT3) 2.7.002 2.7
V2.7 SSB 2.7.002 2.7
The additional connection logging should only be used for
diagnostic purposes. See section 3.1.5.2 of the System Managers
Guide.
10.MUAS$SERVER Access Violation occurred on ALPHA machines. This
problem occurred more frequently after installation of ICF 36 if
Internal_trace was switched on.
11.Access Violations in the A1MAIL$CONNECT process could occur; for
example if the PAB File cabinet location was found to be invalid.
12.Extra logging has been introduced to log the Session ID of the User
who causes an ACCVIO to occur in the A1MAIL$CONNECT Process. Note
that connection logging will need to be switched on before this
extra information can be used to isolate the User.
This extra logging can be used if Access Violations are being logged
in the A1MAIL$CONNECT_EVL_nodename.LOG. Access Violations in this
log would indicate that a particular user's connection had failed
due to some task they were performing at that time. Normally the
Users session would hang and they should report the failure. As much
information as possible on what tasks the user was attempting to
perform at the time and prior to the failure should be gathered.
In situations where the A1MAIL$CONNECT server itself fails due to an
Access Violation then all users will be affected. In this situation
and in other situations where Access Violations are reported in the
A1MAIL$CONNECT_EVL_nodename.LOG but the user affected cannot be
easily identified then Connection logging should be enabled as
indicated in problem 9 above. The log file can then be searched to
find the previous matching session ID to that indicated in future
Access Violations.
e.g.
If log contains an entry such as:
1997021212081163 SVR>S011D14D8> Entering condition handler with a...
1997021212081054 %SYSTEM-F-ACCVIO, access violation, reason mask ...
then search the log for the preceding connection entry that contains
a matching session ID (i.e. 'S011D14D8') -
1997021212064248 CON>S011D14D8, Connect request from user system,
node ...
This User should then be contacted to gather information on tasks
they were performing prior to the failure. This information together
with a DMW$COLLECT_INFO saveset should then be forwarded with any
problem report.
|