I ran into the SYSTEMOBJECT expiration bug when I went to 5.1. The UPGRADEDB
actually codedumped with an error message about the orphan objects. I had to
put my system back to the previous level and run the CLEANUP BACKUPGROUPS
command. This freed up lots of space and the upgrade went smoothly after
that.

Bill Boyer
DSS, INc.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Thomas Denier
Sent: Monday, April 07, 2003 11:01 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Server upgrade hung


We are attempting to upgrade our OS/390 TSM server from 4.2.3.2 to
5.1.6.2. We shut down the 4.2.3.2 server. A number of migration
processes were moving data at the time, and some other migration
processes and some onsite reclamation processes were waiting for
tape drives. We updated the product files and the started task JCL
and started the server with the /upgradedb parameter. The early
initialization messages indicated that the server was now at 5.1.6.2.
The usual sequence of ANR messages followed, with one extra message:
an ANR0363I message announcing that the database had been upgraded.
A couple of minutes after the ANR2100I message announcing that the
activity log process had started the server began requesting tape
mounts. The 4.2.3.2 server always displayed a sort of phony command
prompt on the system console within a couple of seconds of the first
tape mount requests. The 5.1.6.2 server has never displayed the phony
command prompt. The server has never accepted TCP/IP sessions. We used
an OS/390 modify command to issue a 'halt' command. The server displayed
an ANR5965I message noting the command, but not an ANR2701I message.
There is no sign that the server is in the process of halting. A
subsequent attempt to issue a 'q pr' command with the OS/390 modify
was rejected by OS/390 with the message: 'IEE342I MODIFY   REJECTED-
TASK BUSY'. We have already placed a severity 1 call to IBM support.
However, I have found that queries to this list almost invariably
get quicker and more useful responses than calls to IBM. What do we
do next?