What?  Is the reclamation problem with v 3.1 still existent?  Is there
anyone out there on an OS/390 1.2 or 2.4 (MVS) server that has gone to ADSM
3.1, applied the zap (IX74458) and is successfully reclaiming tapes?  I am
getting ready to convert to 3.1, and may consider holding off if this is
still a problem.

                         Thx,

                         Ginny




Sheelagh Treweek <sheelagh.treweek AT COMPUTING-SERVICES.OXFORD.AC DOT UK> on
02/23/98 04:50:44 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: Virginia L Hysock/HI/CSC)
Subject:  Re: Reclamation error





Eugene,
We too have stopped RECLAMATION, again (having applied the ZAP for the
aggregation problem) because we have experienced the same symptoms as
you the first time we ran RECLAMATION following the update.
I have reported this new problem to IBM and was informed:
  "defect 14127 is fixed with 14397. The latter is PQ12370 and they will
   make it into the next server refresh."
which doesn't really help us much at all!
In the meanwhile, we have been using MOVE DATA to empty volumes :  but
you need to script it so that they run serially ...  (and MOVE DATA with
wait=yes doesn't seem to work, which I haven't had time to report).
We have also had some other worrying failures at Version 3 including 3
tapes which we can't read at all without the session/process dying and
the tape and drive resources hung until the ADSM server restarts.
We have had RECLAMATION and MOVE DATA processes just aborting :
  ANR9999D asalloc.c(2182): Attempt to apply archival segment.
  ANR1156W Move data process terminated for volume M00224 -
           internal server error detected.
and on a retry behaving fine - so no diagnostics possible and no
progress in resolving the underlying problem.  It has been suggested to
me that I run AUDIT DB for this one which is something not to undertaken
lightly on a large ADSM DB!
Our service is still running but I am a bit worried about the integrity
of (some of) our data and it's taking rather more hand-holding than is
usual.
Our platform is AIX 4.2.1 by the way.
Regards, Sheelagh
---------------------------------------------------------------------------
---
---
Sheelagh Treweek                         Email:
Sheelagh Treweek                         Email:
sheelagh.treweek AT oucs.ox.ac DOT uk
Oxford University Computing Services     Tel:   +44 (0)1865 273205
13 Banbury Road, Oxford, OX2 6NN, UK     Fax:   +44 (0)1865 273275
---------------------------------------------------------------------------
---
---
> From owner-adsm-l AT VM.MARIST DOT EDU  Mon Feb 23 06:41:11 1998
> From owner-adsm-l AT VM.MARIST DOT EDU  Mon Feb 23 06:41:11 1998
> MIME-Version: 1.0
> Date: Mon, 23 Feb 1998 08:34:49 +0200
> From: Joubert Eugene Datavia <EugeneJo AT TRANSNET.CO DOT ZA>
> Subject: Reclamation error
> To: ADSM-L AT VM.MARIST DOT EDU
>
> Hi
>
> We have no reached a stage where we are now running out of sequential
> storage on our ADSM for MVS V3.1.0 due to our reclamation's not
> completing successfully. Whether this error has anything to do with the
> TAPE RECLAMATION PROBLEM identified by IBM, I don't know. The ZAP
> identified by IBM to solve the problem was of no help.
> If anybody could share some light on the problem it would be greatly
> appreciated.  The error encountered can be viewed below.
>
> 02/23/1998 07:12:52      ANR9999D SSRECONS(1969): Wrong sequence number
> found in
>                           frame header.
>
> 02/23/1998 07:12:52      ANR9999D SSRECONS(1975): Actual:
> Magic=E2C7C6D9,
>                           SrvId=0, SegGroupId=38117483, SeqNum=3.
>
> 02/23/1998 07:12:52      ANR9999D SSRECONS(1982): Expected:
> Magic=E2C7C6D9,
>                           SrvId=0, SegGroupId=38117483. SeqNum=2.
>
> 02/23/1998 07:12:52      ANR9999D AFCREATE(980): Unexpected result code
> (35) from
>                           ssReconstruct.
>
> 02/23/1998 07:12:52      ANR0985I Process 3012 for SPACE RECLAMATION
> running in the
>                           BACKGROUND completed with completion state
> FAILURE at
>                           07:12:52.
>
>
> Thank You
>
> Eugene
> EugeneJo AT Transnet.co DOT za