Dave,
Have you tried the IBM recommended 'work around' for this problem?
I was recommended 2 methods to solve this issue. Here is the text that i was
sent from IBM :
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.
example:
On AIX, OS/2, and VM:
DEVCONFIG /usr/lpp/adsmserv/device.configuration
On MVS:
DEVCONFIG 'ADSM.DEVICE.DEFS'
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
On MVS:
//SERVER EXEC PGM=ANRSERV,
// PARM='/-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
On MVS:
//SERVER EXEC PGM=ANRSERV,
// PARM='/-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.
The Level 0.2/0.2 (or higher) ADSM server will prevent this
situation from re-occurring.
We apologize for this error and will assist in an way possible
with these corrective actions.
>>> Here is method 2 :
The way to correct is is still to dump and reload the
table using DUMPDB and LOADDB as outlined in II08975.
As you say, this was for a different problem, but the correction of the
symptoms is the same.
Sounds like you're getting this message every hour when expiration
runs. I think we might be able to avoid the need to dump/load the
Volume Assignments table.
The Reuse delay is used for tape volumes in Copy Stgpools. When
reclamation runs on the Copypool volumes are returned to scratch only
after the reuse delay period (to give you time to get the new volumes
written to by reclamation offsite). Sounds like this process has gone
wrong somewhere.
Check your reuse delay period qy doing Q STGPOOL F=D for the copypool.
Then do: Q VOL * STATUS=PENDING F=D
to see if you have any volumes in pending state. If you have, you
should be able to move the data off and then delete the volume. There
should be no need to use discarddata=yes. If you can remove any
volumes in this state I think the ANR0104E messages will stop.
>>>END
Deleting the volumes manually 'seems' to have stopped the problem as the
message is no longer
appearing on our ADSM log.
If you need any more info drop me a mail on the address below.
Thanks,
Kuli.
Kulbinder Toora
01384 296191 x3498
e-mail - Kulbinder.toora AT meb.co DOT uk
> -----Original Message-----
> From: Sanders, David [SMTP:DSanders AT INTERNAL.MASSMUTUAL DOT COM]
> Sent: Tuesday, December 08, 1998 6:05 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Reuse delay period.
>
> Hi Kuli;
> Did I hear you right that you experienced this error for the first time
> with
> the MVS V3 server?? Yikes, I've been struggling for 6 months trying to
> get
> it solved (due to the 9G size of my DB and scheduling an outage which I
> resolved using a Y2K duplicated system envrionment). My understanding was
> that it had been cause by a V1 entry, V2 had the permanent fix to overcome
> future breaks, and I waited until I had V3 hoping the the performance
> would
> be substantially better. As I mentioned, I'm still trying to fix MY
> problem, it's very disheartening to find that I might have another future
> problem. Ouch.
>
> Dave Sanders
> Sr. Technical Consultant
> DSanders AT massmutual DOT com
> MassMutual / The Blue Chip Company
> 1295 State St, E060, Springfield, MA 01111
> 413-744-5095
>
>
>
>
> > -----Original Message-----
> > From: Toora, Kuli [SMTP:kulbinder.toora AT EXCHANGE.MEB.CO DOT UK]
> > Sent: Tuesday, December 08, 1998 8:49 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Reuse delay period.
> >
> > Season greetings,
> >
> > On Monday i came into the office and saw the following message on the
> ADSM
> > server log :
> >
> > ANR0104E ASVOLUT(2202): Error 2 deleting row from table
> > "AS.Volume.Assignment
> > ANR0104E .
> >
> > ANR9999D AFMIGR(500): Error checking pending volumes for completion of
> > reuse
> >
> > delay period.
> >
> >
> > Our server runs on OS390 1.2 and our ADSM server level ,is at 3.1.1.3.
> >
> > I contacted IBM regarding this and found information regarding this
> error
> > that was identified in version 1 and version 2.
> >
> > Here is the text from Dial IBM Support :
> >
> >
> > IBM ADSM development discovered and corrected a minor server
> > database problem in the ADSM Version 2 Server Level 0.0/0.0. The
> > correction is included in the HSM refresh for the Version 2
> > product, which displays a server level of "Level 0.2/0.2"
> > or for the OS/2 and VM server at level "0.9/0.9".
> > If you are running the "Level 0.0/0.0 or 0.9/0.9" server,
> > you may encounter occasional error messages involving the
> > AS.Volume.Assignment database object or the DF.MigrCandidates
> > object during backup, migration, or reclamation
> > The messages usually indicate an "Error 2" deleting updating,
> > or inserting new information in the database for the
> > AS.Volume.Assignment or DF.MigrCandidates object: msganr0104e
> > 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.
>
> ================================================================
> This incoming e-mail (and any attachments) has been checked at MEB
> (UK 01384 296191), and has been found to be clean from any
> virus infection (using Dr Solomon's v7.90).
>
> If you have any queries about viruses, please contact PC Tech
> Support (09 3521) or about the external e-mail system, contact
> David Perry (09 3673).
>
> ================================================================
================================================================
This outgoing e-mail (and any attachments) has been checked
(using Dr Solomon's v7.90) at MEB (UK 01384 296191) before
despatch, and has been found to be clean from any virus infection.
If you have any queries about viruses, please contact PC Tech
Support (09 3521) or about the external e-mail system, contact
David Perry (09 3673).
================================================================
|
