From: Mike Knight, IBM GS Central, (314)234-5096, KNIGHTM at ISSCVM
Inet:                                             KNIGHTM AT VNET.IBM DOT COM
Subject:  Error in moving data since migration VM/ADSM V1 to V2

On Mon, 1 Dec 1997 11:42:25 EST, Werner Sailer asked:

>Since we migrated from ADSM for VM/ESA V1 to V2 last weekend ...
>Following error occurs :
>
>  ANR0104E DFTXN(731): ERROR 2 DELETING ROW FROM TABLE "DF.MIGRCANDIDATES".

This sounds exactly like what we had after upgrading our AIX servers.  We
corrected it by following the procedure in informational APAR II08975.
While dumping and loading part of the database is dangerous, it worked fine
for us and only took 40 minutes.

Of course you may have a different problem, but coming after an upgrade,
it will probably turn out to be the same.

I included an edited version of APAR II08975 below.  Caution, it is 100 lines.

    Mike (Personal opinion, just another user, not ADSM support) Knight

 ==========================================================================

  ANR0104E ASTXN.C (898) ERROR 2 DELETING ROW FROM TABLE
  "AS.VOLUME.ASSIGNMENT" OR "DF.MIGRCANDIDATES"

  This problem not only affects users of ADSM V2 at levels below
  0.2/0.2 it can also affect users migrating from and ADSM V1 server
  to an ADSM V2 server.  Here is a suggestion for checking on the V1
  server to see if you might have the problem.  This problem can then
  be corrected on the V1 server before migrating to the V2 server.

  For the DF.MigrCandidates table:

  1 - Run Q OCC STG=xxxx to get an occupancy report for the disk storage pools.
  2 - For each disk storage pool determine if a client has between
      2G and 4G for a single backup filespace or between 2G and 4G
      of archive data in that disk storage pool.
  3 - For these storage pools change the high migration and low
      migration thresholds to force that data to be migrated to
      the next storage pool in the storage pool hierarchy.

  For the AS.Volume.Assignment table:

  1 - Run a Q VOL to get a list of the volumes, their estimated
      capacity and percent utilized.
  2 - For each of the tape volumes multiply the estimated capacity
      by the percent utilized to determine if the volume currently
      contains between 2G and 4G of data.  Since rounding errors
      can occur in the calculation allow for a little under 2G
      and a little over 4G as volumes that are suspected as
      having the problem.
  3 - For the tapes that contain between 2g and 4g of data do a
      move data on these volumes.

  Make sure that there are no clients backing up data, and no
  expiration or migration activity is occurring since these can
  change the utilization on the tape volumes.  This is an
  iterative process since the move data can cause new tapes to
  have between 2G and 4G of utilization.

  To permanently correct this problem if it was discovered after
  migrating to V2 do the following:

  1) Obtain and install the latest Version 2 server (Level
     0.2/0.2 or higher) from your service representative.

  2) Specify a device configuration file in the server options
     file using the DEVCONFIG parameter. Device configuration
     will be written to this file by the server when device
     classes are changed or when the BACKUP DEVCONFIG command is
     specified at the server console or from an administrative client.

     On AIX, OS/2, and VM:
     DEVCONFIG /usr/lpp/adsmserv/device.configuration

     Device class information in the device configuration file is
     used by the server when running in stand-alone mode to
     access all device class information required to mount volumes.

  3) Start the server and issue the BACKUP DEVCONFIG command to copy
     server device class information to the device configuration file.

  4) When the server is not active with client, migration, reclamation, or
     backup stgpool operations HALT the server using the QUIESCE option:

           HALT QUIESCE

     This command should be entered at the server console or from
     an administrative client.

  5) Use the stand-alone DUMPDB command to copy the server
     database to sequential media:

   On AIX, OS/2, and VM:
   dsmserv -t AS.Volume.Assignment dumpdb dev=myclass vol=myvol

     The table name AS.Volume.Assignment is CASE-SENSITIVE and
     must be entered exactly as specified above.  If the problem
     was with the DF.MigrCandidates substitute that table name
     in place of AS.Volume.Assignment in the example.  This table
     name is also case sensitive.

  6) Use the stand-alone database load utility to re-load the
     AS.Volume.Assignment object. The following command
     illustrates the syntax to perform this operation:

   On AIX, OS/2, and VM:
   dsmserv -t AS.Volume.Assignment loaddb dev=myclass vol=myvol

     The table name AS.Volume.Assignment is CASE-SENSITIVE and
     must be entered exactly as specified above.  If the problem
     was with the DF.MigrCandidates substitute that table name
     in place of AS.Volume.Assignment in the example.  This table
     name is also case sensitive.

  7) If the server was halted with quiesce then you can
     safely ignore the message that states an AUDIT is
     required.  The AUDIT DB does NOT need to be performed.

  8) Restart the ADSM server and resume normal operation.

============================ END ==========================================