Specifications

Patches Issued After the CS1/MMS1 Release
Software Superseded by CS3/MMS3 Software Release Notice for 5.0rev1
5-14 CS3 and MMS3
SPECTRUM_5.0rev1.P39
On Windows_NT, the SpectroSERVER is crashing after a couple of
minutes. This is caused by the fact that we don't properly handle
changing the icmp packet size on NT. We change the send size, but we
don't account for the larger packet on the return. This has been
resolved by changing the code to account for the larger packet size.
NOTES
1. The following corrected anomaly was included in Patches P40, P41,
P42, P43, P44, P45, P47, P48, P49, P50, and P51.
When you run an Online Backup from the VNM icon, the status in the
Online Backup window reports that the backup failed. VLAN Manager
1.8 is also installed on the machine. This happens only during a very
specific set of events that can come from a vpapi client (VNM, etc.) as
follows:
a. Thread A sends a ticket request for the start of a process in the
foreground.
b. Thread B sends a ticket request for process is alive.
c. Thread B receives a response on process is alive.
d. Thread A receives a response that the foreground process has
died.
In this case, the information returned to Thread A in the actual ticket
is incorrect with respect to what was sent in the parm block. This
occurs because the exchange id and function id are replaced from Step
3 to Step 4. For example, if Thread A relies upon the exchange id to
ensure that it is dealing with a certain message, then the information
is incorrect. Since another ticket is not sent back, a deadlock results.
The resolution was to change the way some information is stored
between client requests.
2. The following corrected anomaly was included in P42, P43, P44,
P45, P47, P48, P49, P50, and P51.
The SpectroGRAPH does not connect to a newly started and running
SpectroSERVER; however, it does connect after several attempts. The
cause is that processd is not sending a reply to the “ticket is ready”
message back to the SpectroSERVER with the correct exchange id.
This causes the SpectroSERVER to block before it has called accept on
its listen socket. The resolution was to include the ticket in the
exchange id from the CsVnmMsg, rather than to include it in the reply.