Yesterday I upgraded the TSM server code on one of our zSeries Linux
systems from 6.2.2.0 to 6.2.5.0. There were two exciting moments that
didn't occur when I performed the same upgrade in a test environment.

The first exciting moment occurred while I was running './install.bin -i
console' to install the updated server code. I accepted the default
locale and selected the server as the only product to be installed. I
eventually saw the pre-installation summary and pressed the 'Enter' key
to proceed. Some minutes later a long list of subroutine names appeared
on the screen. I scrolled the screen buffer back to the top of the list
and discovered a message stating that malloc had discovered corrupted
data in memory. Many minutes after that the installer reported that it
had successfully installed the TSM server, DB2, and the TSM client API.
Is the reported memory corruption a known problem? Is it reasonable to
take the claim of successful installation at face value?

The system hosts two TSM server instances: a library manager and an
instance for storing client files. The library manager was started in
the foreground, halted, and restarted in the background without incident.
The file storage instance was started in the foreground and completed
initialization with no obvious signs of trouble. When I halted the
instance it apparently went into a loop that consumed most of the CPU
capacity. A default 'kill' signal had no effect. When the instance had
used more than five minutes of CPU time I reluctantly resorted to the
'kill -9' command. I was then able to restart the instance in the
background. Is looping after a halt request a known problem for the
6.2.5.0 server level?

Thomas Denier,
Thomas Jefferson University Hospital