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
