Microsoft Mail v3.0 (MAPI 1.0 Transport) IPM.Microsoft Mail.Note
From: FOSTER, Simon,  SADS
To:  'INTERNET:adsm-l AT VM.MARIST DOT EDU'
Subject:  RE: Backup DB & Del Volhistory
Date: 1996-09-20 13:18
Priority: 3
Message ID: E21B5346BD12D011B0C140000006A509
Conversation ID: RE: Backup DB & Del Volhistory

------------------------------------------------------------------------------
Stick that delete volhistory command in an administrative schedule, set
Stick that delete volhistory command in an administrative schedule, set
it up to run every day, well before you run the backup, and everything
will be fine. We do this and have no problems.



Simon Foster
System Services
Distributed Systems
Technical Operations
Level A/3
National Westminster Bank PLC
Goodmans Fields
74 Alie Street
London     E1 8HL
Phone: (+44/0) 171 480 2168      <ITS: 73-2168>       <Mobile: (+44/0)
802 187593>
Fax: (+44/0) 171 480 2848      <ITS: 73-2848>
GOAP: Y001SF3
Internet: simon.foster AT natwestuk.co DOT uk



 ----------
From:  INTERNET:owner-adsm-l AT VM.MARIST DOT EDU/
Sent:  19 September 1996 21:57
To:  INTERNET:ADSM-L AT VM.MARIST DOT EDU/
Subject:  Backup DB & Del Volhistory

Hello ADSMers,

We just upgraded from AIX ADSM server v1.2.0.9 to v2.1.0.9 over the
weekend.
The
upgrade went fine. My problem is with changing from DUMP DB to BACKUP DB
to
back
up my database. I was dumping the db to tape daily and cycling thru 7
tapes
for
each day of the week via a scheduled job which invokes a simple macro.
When I
changed from DUMP to BACKUP, the command would not use the specified tape
and
would end up using a scratch tape. It turns out the BACKUP command will
not
write
over a tape that is still logged in the database as being used for
backing up
the
database. To get around this, I thought I could simply stick the
following:

 DELETE VOLHISTORY TODATE=TODAY-7 TYPE=DBBACKUP

into the macro and be done with it. Unfortunately, when I did that, the
job
hangs
and I can't even get rid of the session with the cancel session
command.When I
reported the problem to IBM, I was told that the DELETE command was
hanging
the
session waiting for a confirmation reply and was working as designed.

If anybody out there has figured out a way to do something similar to
what I
am
trying to do I would love to hear his/her solution.