Volume *N on device TAP02 wrong type (C INZ R).
Iain Wilson
Relatively new administrator here with a plea for help.
We have a scheduled backup process which consists of
A CL program which calls an RPGILE program which calls a CL.
(Selected source at bottom)
The first CL collects all the libraries and stores the data in a
table.
The RPGILE program sequences the libraries to be backed up and
passes the next library name and sequence number to the second CL
The Second CL does the save to Tape.
This process worked perfectly well until last weekend. However, the
job is now changing to MSGW state when attempting to write to the tape
in the second CL for the first time. The message is as follows
---------------------------------------------------------------------------
Message . . . . : Volume *N on device TAP02 wrong type (C INZ R).
Cause . . . . . : Volume *N on device TAP02 is the wrong type for
*SL file
QSYSTAP in QSYS. A standard label volume is required for a *SL or
*BLP file.
A nonlabeled volume is required for a *NL, *NS, or *LTM file.
Recovery . . . : Do one of the following:
-- Use C to cancel processing.
-- Use INZ to initialize the current volume to the correct format.
-- Put the correct type volume on the tape drive, and use R to
try the
operation again.
---------------------------------------------------------------------------
Once I answer INZ the process continues on it's merry way.
I don't understand. If I go behind the job (5 then 10) I can see that
the first CL did in fact initialise the tape (Nonlabeled tape volume
initialized).
Any adive or ideas would be appreciated
Thanks in advance for any help offered
Iain
******************************************************************************
/* CL Program Number 1 */
/* This program initialises the tape, */
INZTAP DEV(TAP02) NEWVOL(*NONE) CHECK(*NO)
MONMSG CPF9999
/* Get the library information */
DSPOBJD OBJ(*LIBL/*ALL) OBJTYPE(*LIB) DETAIL(*BASIC) +
OUTPUT(*OUTFILE) OUTFILE(MAPMODF/TOK004AP)
/* The data is filtered here. A RPGILE program is called */
/* which in turn calls the Second CL program to do the actual */
/* Save */
/* Security And Configuration Data Is Saved */
SECDATA: SAVSECDTA DEV(TAP02) SEQNBR(*END) OUTPUT(*PRINT)
CFGDATA: SAVCFG DEV(TAP02) SEQNBR(*END) OUTPUT(*PRINT)
/* Now read tape of the libraries backed up */
DSPTAP DEV(TAP02) OUTPUT(*PRINT) /* Read tape to print */
******************************************************************************
/* The second program */
/* The second program which is called from the RPGILE program */
/* The library, object type and the next sequence number are */
/* passed into this program */
PGM PARM(&TLIB &TOBJ &TSEQ)
DCL VAR(&TLIB) TYPE(*CHAR) LEN(10)
DCL VAR(&TOBJ) TYPE(*CHAR) LEN(10)
DCL VAR(&TSEQ) TYPE(*DEC) LEN(3 0)
IF (&TSEQ *GT 1) (GOTO NXT)
/* Save the first library in the sequence */
SAVLIB LIB(&TOBJ) DEV(TAP02) SEQNBR(&TSEQ) +
ENDOPT(*LEAVE) SAVACT(*LIB) SAVACTWAIT(1) +
OUTPUT(*PRINT)
MONMSG CPF9999
GOTO END
NXT:
/* Save all the rest of the sequences */
SAVLIB LIB(&TOBJ) DEV(TAP02) SEQNBR(*END) +
ENDOPT(*LEAVE) SAVACT(*LIB) SAVACTWAIT(1) +
OUTPUT(*PRINT)
MONMSG CPF9999
END:
ENDPGM
F.Langner
in this way
INZTAP DEV(TAP999) NEWVOL(LOLA) NEWOWNID(LOLA) CHECK(*NO)
--
Fred Langner
f.la...@nospamtcs-gmbh.com
remove nospam to answer
"You do not have to develop the wheel again..."
Iain Wilson <iwi...@dundee.tokheim.com> schrieb in im Newsbeitrag:
2174c13c.02092...@posting.google.com...
Iain Wilson
I will change the script accordingly.
However, it does not explain why the process worked fine for
at least 6 months until last weekend and now requires a lable.
I would be interested to know of possible reasons why
Once again thanks
René H. Hartman
Look at your source change dates. Saves have _never_ worked with NL
(Non-Labeled) tapes. Since tapes are labeled in your first CL, any SL
(Standard Label) tape would have been re-initialized as NL, and hence
could not have worked. My hunch is that someone changed the first CL.
One catch: initializing tapes at backup time, from your backup routine,
has two major drawbacks:
1. Regardless of the tape in there, you erase it. You may have picked
the wrong tape, or left one from a restore, and it's gone.
2. You can only initialize the first tape in a set this way. If your
save requires a second tape, and that has *PERM for expiration, your
save will issue a SYSOPR msg and wait for a reply. Next morning, when
you come in, the system's down and you don't have a proper backup.
HTH
--
Vriendelijke groeten / Kind regards
René H. Hartman
R.H. Hartman Automatiserings Consultancy
www.hac-maarssen.nl
-----= Posted via Newsfeed.Com, Uncensored Usenet News =-----
http://www.newsfeed.com - The #1 Newsgroup Service in the World!
-----== 100,000 Groups! - 19 Servers! - Unlimited Download! =-----
F.Langner
intialized with nolabel
--
Fred Langner
f.la...@nospamtcs-gmbh.com
remove nospam to answer
"You do not have to develop the wheel again..."
Iain Wilson <iwi...@dundee.tokheim.com> schrieb in im Newsbeitrag:
2174c13c.02092...@posting.google.com...
Kim Kuras
If your save is unattended and it uses more than one tape, add reply
list entries (ADDRPYLE) for CPA4278 to reply with to I and CPF4901 to
reply with G.
Iain Wilson
Iain Wilson
not run on to 2 tapes
Iain Wilson
René H. Hartman
Iain Wilson wrote:
> Source has not been changed since it was created so it must have
> worked
When was it created / first put in use? Maybe it's an front end, added
later on for the sole purpose of initializing the tape.
Do a DSPTAP on one of the tapes that were created before your problem
started and look what the tape label is. I cannot believe that these
tapes
has no label. As stated before, you cannot save to a Non-Labeled tape.
This was already the case when the AS/400 first came out, and probably
before that on the S/38.
On your comment only using one tape: that still leaves you vulnerable to
erasing the wrong tape. In my opinion, INZTAP should not be part of the
backup process, but part of tape picking and preparing. Or, like BRMS,
you can set proper expiration dates for your tapes, so INZTAP will not
be necessary.