Kuli, I've tried the whole process #1 (on a 9GB DB it took 9 hours for the
dump/load). It's still broken.
I've never been told about the second process. In fact, I sent the IBM
support person the doc for me doing that process that DIDN'T fix it with a
question about what to do next (and I know he read it courtesy of email
receipt) but haven't heard from him in 2 days.
This is a good value of this forum that enhances (replaces?) some official
support!!!! I'll follow up on your #2 option!!
Thanks.
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: Wednesday, December 09, 1998 4:59 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Reuse delay period.
>
> 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).
>
> ================================================================
|
