Thanks Andy!

Your CML pals, say hi!

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: Andrew Raibeck [SMTP:storman AT US.IBM DOT COM]
> Sent: Wednesday, October 14, 1998 10:56 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Errors: ANR0104E and ANR9999D
>
> 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