RE: SAVxxx SEQNBR(11) bombs if #11 already on tape??? -- MIDRANGE-L

It really did work on reel-to-reel tapes.  Streaming drives, designed for
"bulk processing" (save/restore) are much different from reel-to-reel
drives, which were originally designed to process (meaning lots of
back-and-forth stuff, the crap you see on really bad sci-fi movies) tape
data, before disk technology took off.

For example, the 2240 drive was built by Siemens; "beautiful" is the only
adjective you can use to describe the engineering and manufacturing.  Even
IBM's 3410 and 3411 were pretty good units!  It takes fairly sophisticated
electrical, mechanical, and pneumatic technology to move a tape to the right
tape mark, nothing more than a burp on the tape about 1/8" wide, indicating
some sort of control information (volume or tape label).  The hardware
technology on r-2-r tapes allows precise positioning, and that makes
SEQNBR(11) work.  An additional challenge on r-2-r is the large mass (10.5"
tape) you're trying to control; it makes dancing on the head of a pin sound
easy.  But I don't miss reel-to-reel backups one bit!

I think Honeywell focused on tape technology and IBM focused on disk
technology.  And the winner is...

-----Original Message-----
From: midrange-l-admin@midrange.com [mailto:midrange-l-admin@midrange.com]On
Behalf Of barsa@barsaconsulting.com
Sent: Thursday, August 30, 2001 9:31 AM
To: midrange-l@midrange.com
Subject: RE: SAVxxx SEQNBR(11) bombs if #11 already on tape???


To my knowledge, the SEQNBR number doesn't (and has never) really worked.
The only two acceptable values are "1" and "*END".  If I am wrong, would
someone please correct me.

Al

Al Barsa, Jr.
Barsa Consulting Group, LLC

400>390

914-251-1234
914-251-9406 fax

http://www.barsaconsulting.com
http://www.taatool.com






                    neilp@dpslink.com
                    Sent by:                  To:
midrange-l@midrange.com
                    midrange-l-admin@mi       cc:
                    drange.com                Subject:     RE: SAVxxx
SEQNBR(11) bombs if #11 already on tape???


                    08/29/01 07:59 PM
                    Please respond to
                    midrange-l






All drives support SEQNBR(1) CLEAR(*ALL) but only a few (reel to reel for
example) will support CLEAR at other than SEQNBR(1).
SEQNBR(1) CLEAR(*ALL) is very useful for a backup where you don't
want/need to reinitialize the tape but want to erase previous data.

...Neil





"Reeve Fritchman" <reeve@ltl400.com>
Sent by: midrange-l-admin@midrange.com
2001/08/29 13:11
Please respond to midrange-l


        To:     <midrange-l@midrange.com>
        cc:
        Subject:        RE: SAVxxx SEQNBR(11) bombs if #11 already on
tape???


Dan, I think it's something to do with the nature of streaming tape
drives:
the tape transport can't position the tape to the tolerance required for
overwriting.  Overwriting did work on reel-to-reel tapes, but then it's
embarrassing to admit I know that.

Maybe you need to change users instead of changing tapes...

-----Original Message-----
From: midrange-l-admin@midrange.com
[mailto:midrange-l-admin@midrange.com]On
Behalf Of Bale, Dan
Sent: Wednesday, August 29, 2001 12:27 PM
To: midrange-l@midrange.com
Subject: RE: SAVxxx SEQNBR(11) bombs if #11 already on tape???

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
I was wondering the same, whether this only works with reel tapes.  If
so, it seems odd that IBM chose to leave the help text I referenced
unchanged (even on our V4R4 box!), without at least some note that this
only works for reel (or non-7208?) tapes.  I mean, really, who uses reel
tapes for backing up their AS/400 anymore?

Regardless, it seems odd that this is an issue with any tape drive,
don'tcha think?  Go to sequence# 11 on the tape, ignore what's there,
and start writing.  What's so hard about that?

<sigh>  Making a mountain out of a molehill, I guess.

Dan "there's just gotta be a way!" Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com

> -----Original Message-----
> From: Reeve Fritchman [SMTP:reeve@ltl400.com]
> Sent: Wednesday, August 29, 2001 11:41 AM
> To:   midrange-l@midrange.com
> Subject:      RE: SAVxxx SEQNBR(11) bombs if #11 already on tape???
>
> I think non-reel tapes have a problem with overwriting sequence
> numbers;
> I've encountered the same problem as you.  And since the end labels
> probably
> weren't written, the 7208 won't know where SEQNBR(12) should start.
>
> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On
> Behalf Of Bale, Dan
> Sent: Wednesday, August 29, 2001 11:14 AM
> To: MIDRANGE-L@midrange.com
> Subject: SAVxxx SEQNBR(11) bombs if #11 already on tape???
>
> This morning, someone at one of our remote branches inadvertantly
> ejected the backup tape on our V3R7 system before it was finished
> backing up a save file via SAVSAVFDTA.  Strangely enough, a DSPTAP of
> the tape shows the ten libraries that were saved normally via the
> SAVLIB
> that runs prior to the SAVSAVFDTA.  It also shows sequence number 11
> for
> the library being saved via SAVSAVFDTA, but the Date Created and
> Expiration Date are from the save that occurred last week.  This may
> or
> may not be a moot point...
>
> I attempted to restart the SAVSAVFDTA.  First, I cancelled the backup
> job that had the message waiting because the tape had been ejected.
> Then I submitted:
>      SAVSAVFDTA SAVF(AOSLIB$SFL/AOSLIB$SAV)
>        DEV(TAP03) VOL('TUE1W1' 'TUE2W1') SEQNBR(11)
>        ENDOPT(*LEAVE) CLEAR(*ALL) EXPDATE(083001)
>        COMPACT(*DEV) OUTPUT(*PRINT)
>
> Note: This save would fill up the remaining portion of TUE1W1 and
> continue to TUE2W1.  According to the help text on SAVSAVFDTA's CLEAR
> parameter, specifically the *ALL option:
>
>     If tapes are used and a sequence number is specified on the SEQNBR
>
>     parameter, the first tape is cleared beginning at that sequence
> number.
>     All tapes following that first tape are completely cleared.
>
>
> Using this information, I presumed that using CLEAR(*ALL) & SEQNBR(11)
> would enable the save command to overwrite whatever was sitting at
> that
> spot on the tape.  However, when I submitted this command, I got
> message
> CPF4249, which states:
>  Message . . . . :   File sequence number 11 already exists on volume
> TUE1W1.
>  Cause . . . . . :   File sequence number 11 already exists on volume
> TUE1W1,
>   and the device TAP03 is a 7208 type tape device. After a tape volume
> has
>   been initialized, this type of tape device can only add files to the
> end of
>   the volume.  Therefore, a sequence number cannot be specified which
> already
>   exists on the volume. Recovery  . . . :   Specify a sequence number
> (SEQNBR)
>   one larger than the last file on the volume with the Override Tape
> File
>   (OVRTAPF) command, or load the correct volume on the tape device and
> try the
>   operation again.
>
> Why is the 7208 "picked on" here?  More importantly, is there a way I
> can clear SEQuence NumBeR 11 on that tape so that I can run the
> SAVSAVFDTA?
>
> Dan Bale




_______________________________________________
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





_______________________________________________
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.