Re: SAV... not writing over expired files. -- MIDRANGE-L

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Methinks thou art right.   Thus what I intend to do instead is CHKTAP,
retrieve the volid, and INZTAP to that same volid.  Alas, no *MOUNTED on
the VOLID for a INZTAP.  The reason I am going this way instead of
SEQNBR(1) is one of our backups is split among two data queues to two tape
drives.  The CHKTAP/INZTAP combo sound better than saving a dummy object
to get the first sequence.  Oh, I suppose I could count my own sequence
variable in the data queue loop.  We'll see...

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin




neilp@dpslink.com
Sent by: midrange-l-admin@midrange.com
12/27/2002 04:15 PM
Please respond to midrange-l

        To:     midrange-l@midrange.com
        cc:
        Fax to:
        Subject:        Re: SAV... not writing over expired files.


Sorry Rob, I missed that in the DSPTAP.  Yes, if the file shows as expiry
date 12/25/02 I would think it would overwrite it on 12/26/02 - IF you
specified SEQNBR(1) as the default is SEQNBR(*END). You wouldn't have
needed the CLEAR(*ALL) on 12/26/02 but would if you had wanted to
overwrite it prior to 12/25/02.

...Neil







rob@dekko.com
Sent by: midrange-l-admin@midrange.com
2002/12/27 15:07
Please respond to midrange-l


        To:     midrange-l@midrange.com
        cc:
        Subject:        Re: SAV... not writing over expired files.


This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Neil,
The expiration date for the data already existing on the tape was:
Expiration
Date
12/25/02
The expiration date for the new SAVLIB command was:
EXPDATE('01/01/03')

Shouldn't it have written over this?  Or did we require the SEQNBR(1)
CLEAR(*ALL)?
I don't believe that this has been the case on our other tapes.

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin




neilp@dpslink.com
Sent by: midrange-l-admin@midrange.com
12/27/2002 02:57 PM
Please respond to midrange-l

        To:     midrange-l@midrange.com
        cc:
        Fax to:
        Subject:        Re: SAV... not writing over expired files.


Not if the expiration date for the first save was January 1st, 2003 as
shown in your SAVLIB statement.
It correctly read to end of volume looking for an expired file, and as the
last file continues on a different volume the tape is full and you can't
write to it.
If you want to replace the first file specify SEQNBR(1) CLEAR(*ALL).

...Neil





rob@dekko.com
Sent by: midrange-l-admin@midrange.com
2002/12/27 13:32
Please respond to midrange-l


        To:     midrange-l@midrange.com
        cc:
        Subject:        SAV... not writing over expired files.

We have a 3581 tape drive.  A typical save does the following:
SAVLIB LIB(QUSRADSM) DEV(TAP04) EXPDATE('01/01/03') ENDOPT(*LEAVE)
OUTPUT(*PRINT)
On Thursday, December 19 we ran this.  And some other saves.  The results
(as displayed via DSPTAP) are:
5722SS1 V5R2M0 020719
Device . . . . . :   TAP04
Owner ID . . . . :   GDI
Type . . . . . . :   *SL
                              Record
                   File       Block
Data File Label    Sequence   Format
QUSRADSM           0000000001 *U
PCBACKUP           0000000002 *U

 TAPE VOLUME INFORMATION         4THU1
     Volume . . . . . :   4THU1
     Density  . . . . :   *ULTRIUM1
     Code . . . . . . :   *EBCDIC

Recg  Record  Block   File        Mvol
Tech  Length  Length  Length      Ind
P     00000   262144  0000001442
P     00000   262144  0000417780  CONT

     GDIHQ       12/27/02 10:53:31




Mvol        Date      Expiration
Sequence    Created   Date
0000000001  12/19/02  12/25/02
0000000001  12/19/02  12/25/02

However, when we went to save on it on the night of Thursday December 26,
we received the following errors:
CPF4284-Cannot add file sequence number *END to full volume 4THU1.

Shouldn't this just get written over?

Rob Berendt





_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.