John:
      I tried to answer the questions as you asked them. Please see the notes
      immediately following
your queries.  One additional note I misquoted the person that was in over the
      weekend about the 36 hours clock time to
run the EXPIRE INVENTORY.  He corrected me this morning and it should have been
      6 Hours.  He gave
me the wrong start time when we spoke.  I did not want to scare you any more
      than necessary.

      The reason for my original question is that we have been amassing far more
      copies of datasets
without expiring the older versions.  My mailbox backup in Notes is only
      supposed to have 20 Versions at all
times.  I checked yesterday and found that I have 30.  The EXPIRE INVENTORY only
      appears to have
changed the Deactivation Date for the 10 oldest Versions to the day when we ran
      the command.  I thought that
some process would start cleaning out all of the un-needed versions and would
      start reclaim processing in
my tape pool.

                                              Bob Bunt
                                              rmbunt AT nyseg DOT com




        I am about to do this upgrade on an OS/390 1.3 server platform
(mainframe).  I have read many letters in this bulletin board about the
Expire Inventory not working properly in earlier releases and running long
at 3.1.2.xx releases.  I am at server 3.1.1.3 now, about to go to 3.1.2.20.
I read the Samplib member about the AUDIT RECLAIM process you speak of and
the UPGRADE option that needs to be specified.
1.      Where and when and how often do you specify UPGRADE?
     --> UQ28274 indicated that if you have NOT applied service level 3.1.2.0
with
          PTF UQ20342 OR 3.1.2.1 with PTF UQ23882 prior to applying this PTF
that
          this service level requires the use of the UPGRADEDB parameter when
          starting ADSM.
2.      Is it a PARM on the execute card of the ADSM address space JCL?
     --> Yes, the point at which you call the program DSMSERV. For example:
          //SERVER  EXEC PGM=DSMSERV,PARM='/UPGRADEDB',
3.      Do you specify it only the first time you come up under the upgraded
software?
     --> When we brought up ADSM for the first time under Version 3 (from
          Version 2) we had to include the Parm for Upgradedb and then
          run with the Parm for the Web Services.
4.      After you have come up successfully, do you remove the UPGRADE
phrase?
     --> Yes
5.      It sound like the AUDIT process is performed after you have come up
with UPGRADE specified. Is that correct?
     --> We keyed it in from the line mode as an administrator.
6.      I have read of other users whose first EXPIRE INVENTORY took days to
execute.  It sounds like you expected that.
     --> Under Version 2, Expire Inventory took a great deal of time to execute.
          We had it slated to run everyday at around 2 PM in the afternoon.
          The problem was that we could not access or establish a session during
          the time when it was running.  At this point, we changed to running
the
          process once a week during a low level access time period.

        I am very interested in your experience upgrading to 3.1.2.20. Do
you have any tips or warnings? We are upgrading all our clients first to
3.1.0.6 before we do the server.  I would be very greatful for any info on
your testing plan and the  confirmations that were done after you upgraded.
I plan on backing up all my ADSM files using DF/DSS ad well as the ADSM
database backup utility before upgrading.
     --> We also backup the Server with DF/DSS and also with the Database
          backup process from ADSM.  I have restored the database from
          the backup tapes that ADSM created.  It did not take that long to
          reload.  It was the AUDIT process that you have to run to clear
          up the cobwebs that takes so long to execute.  The actual upgrade
          to the V3 server from V2 was very painless.  We followed the
instructions
          in the ADSM/MVS V3 implementation guide.
John

John Morlier
Manager of Technical Services and Operations Support
, Integrated Product Data Environment

Avondale Industries, Inc.
IPDE Technology Division

%   Voice: (504) 436-5213
*  Fax:  (504) 437-5534
):    Email:  jmmorlier AT avondale DOT com <kgmyers AT avondale DOT com>


        -----Original Message-----
        From:   Robert  Bunt [SMTP:rmbunt AT NYSEG DOT COM]
        Sent:   Monday, April 19, 1999 10:51
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Expire and reclaim after 3.1.2.20 Upgrade

        We have just upgraded our ADSM/MVS server to 3.1.2.20 over this past
        weekend.  Following the normal process checks, the EXPIRE INVENTORY
        command was executed.  This ran for approximately 36 hours and
issued
        a successfully completion message.  This is only set to run once a
week
        by schedule.

        Today, we ran the follow up to the upgrade which was the execution
of the AUDIT
        RECLAIM Utility.  The message was returned that no items were
identified
        as needing to be processed.  The RECLAIM_ANALYSIS table was empty.

        I had expected that (at the very least) the growing number of backup
copies
        found in the inventory would be reduced to the VEREXISTS parameter
as
        set up in the copygroup.  The large number of tapes that had grown
to hold the
        non-expiring inventory are still present and do not appear to be
going away
        anytime soon.

        Did I miss something?  Should one or both of these utilities reduce
the
        inventory
        back to what is specified in the respective management class copy
groups?