Hi Dave,
Off-hand I'd say that there is a high degree of
probability that your problem is indeed II08975.
I can't *guarantee* this, though, as I have not
worked on your problem; it is conceivable that
there is an underlying problem different than the
one resolved by II08975, but showing the same
symptoms of II08975. But given your current level
of maintenance, II08975 is the likely candidate.
Reorganizing the AS.Volume.Assignments table fixes
this problem; there is no need to reorganize the
entire database.
There are too many factors involved to give reasonable
estimates when it comes to reorganizing the ADSM
database. However based on my previous experience
with other customers having this problem, I'd say
that this should not take *too* long, i.e. on the
order of hours, not days.
The cause of II08975 is already fixed in the level
of maintenance you are at, so once you do the
re-org, you should not see it again.
Just an FYI... the ADSM for MVS Version 2 server goes
out of service at the end of 1998. You may already be
aware of this, but I figured I'd mention it anyway
just in case...
Regards,
Andy
Andy Raibeck
IBM Storage Systems Division
ADSM Client Development
e-mail: storman AT us.ibm DOT com
Mark, we've had that same error outstanding for a long time. I'm on MVS V2
but the same context of the message. I've asked several times about other
folks and how they've dealt with the problem (reorg the table vs. the db)
but have never gotten a response. I'm in the process of having a totally
isolated environment (a Y2K isolated MVS-LPAR) that I'm going to use for
experimentation. I can't take an outage without having a high degree of
confidence or time estimate. I can't get either from support.
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: Mapes, Mark [SMTP:MWM4 AT PGE DOT COM]
> Sent: Monday, October 12, 1998 10:37 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Errors: ANR0104E and ANR9999D
>
> Hello,
>
> We just started getting these error last Thursday, and now get many a day.
>
>
> ANR0104E asvolut.c(2225): Error 2 deleting row from table
> "AS.Volume.Assignment".
>
>
> ANR9999D afmigr.c(517): Error checking pending volumes for completion of
> reuse delay period.
>
>
>
> We upgrade our AIX/ADSM from 3.1.1.3 to 3.1.2 last Monday (and before that
> we applied a patch last Spring and upgraded from 2.1 to 3.1 and AIX 3.2 to
> 4.2 in January and sometime before that we went from v1.x to v2.1).
>
> In IBMLink, I could not find a direct hit on these messages. The closest
> I
> found was APAR II08975, dated 02/13/97 and refers to V1 to V2 migration.
> It
> suggests that the AS.Volume.Assignment table be reorganized. Is that what
> I
> want to do? Should I follow the instructions that are specified in that
> APAR, which is just the reorg of that on table or do I want to do an
> entire
> reorg of the ADSM database (perhaps fixing other problems and/or achieving
> some performance gains)?
>
> How serious is this problem? Is there something else that can be done,
> such
> as an AUDIT LIBRARY command.
>
> Thanks for you help.
>
> Mark Mapes
> PG&E
|
