ontape problems still

I am still having problems archiving using ontape. Level 0 archives prompt for 2nd tape but get an error -28 before prompting for a third. Level 1 archives do not prompt for a 2nd tape, I just get the error -28. I know I need to get a higher capacity tape drive ( I am about to raise hell about it, as I've been asking for 3 months.). But..does anyone know if there is a constraint on number of tapes used for various level archives? I have toyed with the TAPESIZE variable to no avail.

Error 28 (on HP-UX at least) is no space left on device. I have heard of archives with way more tapes than 3 or 4. I would decrease TAPESIZE further. aj Keith Sharp wrote: > > I am still having problems archiving using ontape. Level 0 archives prompt > for 2nd tape but get an error -28 before prompting for a third. Level 1 > archives do not prompt for a 2nd tape, I just get the error -28. I know I > need to get a higher capacity tape drive ( I am about to raise hell about > it, as I've been asking for 3 months.). > But..does anyone know if there is a constraint on number of tapes used for > various level archives? I have toyed with the TAPESIZE variable to no > avail.

Keith Sharp wrote: > > I am still having problems archiving using ontape. Level 0 archives prompt > for 2nd tape but get an error -28 before prompting for a third. Level 1 > archives do not prompt for a 2nd tape, I just get the error -28. I know I > need to get a higher capacity tape drive ( I am about to raise hell about > it, as I've been asking for 3 months.). > But..does anyone know if there is a constraint on number of tapes used for > various level archives? I have toyed with the TAPESIZE variable to no > avail. If reducing the TAPESIZE parameter drastically does not solve this then your problem is most likely that you have run out of tempdbspace NOT tape space. There is not constraint on the number of volumes a tapeset can contain in any archive level. You do not state what version of IDS you have. If 7.2x you need to have one VERY big tempdbspace for archiving purposes, for 7.3x the archive algorithms changed and archives can successfully use several smaller, but preferably equal sized, tempdbspaces. What is happening is that during the archive any physical log pages that will need to be archived are copied to temp tables in tempdbspace one per dbspace. In 7.2x these tables all live until the ENTIRE archive is completed, even though its contents have been dumped to tape when the corresponding dbspace has been archived, and each temp table lives in one tempdbspace with the tables assigned to tempdbspaces round robin as they are created. If two active dbspaces happen to have their temp tables in the same tempdbspace you can imagine that that tempspace may fill while there is still plenty of space in the others. If this happens the archive will exit with errno 28. For this reason you should have only one or perhaps two large tempdbspaces to prevent them from filling during archives, even though sorting will be faster with more smaller tempdbspaces. In 7.3x each temp table created for the physical log pages (indeed any temp table) is fragmented across ALL tempdbspaces and each table is dropped once its dbspace has been successfully archived and the physical log pages it holds have been dumped to tape. This means you need less tempdbspace and can take advantage of more tempdbspaces for better sort performance. Let's put this one in the new FAQ, but perhaps use my last response to it, which may have been clearer (I'm tired). Art S. Kagel

Is this right? In the circumstances you describe (tempdbs fills during archive) I seem to remember getting an ISAM error, not an OS error (i.e error -28). Neil Art S. Kagel wrote in message <37D6C54A.C65752B5@bloomberg.net>... >Keith Sharp wrote: >> >> I am still having problems archiving using ontape. Level 0 archives prompt >> for 2nd tape but get an error -28 before prompting for a third. Level 1 >> archives do not prompt for a 2nd tape, I just get the error -28. I know I >> need to get a higher capacity tape drive ( I am about to raise hell about >> it, as I've been asking for 3 months.). >> But..does anyone know if there is a constraint on number of tapes used for >> various level archives? I have toyed with the TAPESIZE variable to no >> avail. > >If reducing the TAPESIZE parameter drastically does not solve this then >your problem is most likely that you have run out of tempdbspace NOT tape >space. There is not constraint on the number of volumes a tapeset can >contain in any archive level. You do not state what version of IDS you >have. If 7.2x you need to have one VERY big tempdbspace for archiving >purposes, for 7.3x the archive algorithms changed and archives can >successfully use several smaller, but preferably equal sized, >tempdbspaces. > >What is happening is that during the archive any physical log pages that >will need to be archived are copied to temp tables in tempdbspace one per >dbspace. In 7.2x these tables all live until the ENTIRE archive is >completed, even though its contents have been dumped to tape when the >corresponding dbspace has been archived, and each temp table lives in one >tempdbspace with the tables assigned to tempdbspaces round robin as they >are created. If two active dbspaces happen to have their temp tables in >the same tempdbspace you can imagine that that tempspace may fill while >there is still plenty of space in the others. If this happens the archive >will exit with errno 28. For this reason you should have only one or >perhaps two large tempdbspaces to prevent them from filling during >archives, even though sorting will be faster with more smaller >tempdbspaces. > >In 7.3x each temp table created for the physical log pages (indeed any >temp table) is fragmented across ALL tempdbspaces and each table is >dropped once its dbspace has been successfully archived and the physical >log pages it holds have been dumped to tape. This means you need less >tempdbspace and can take advantage of more tempdbspaces for better sort >performance. > >Let's put this one in the new FAQ, but perhaps use my last response to it, >which may have been clearer (I'm tired). > >Art S. Kagel

Except in private communication Keith tells me he has no tempdb space so his temp tables may be going to filesystem space in /tmp which would get the errno 28, I guess.?? Keith mentions he tried reducing TAPESIZE and I did imply that he should try reducing it drastically to eliminate the possibility that his assumption of running out of tape is correct. Art S. Kagel Neil Truby wrote: > > Is this right? In the circumstances you describe (tempdbs fills during > archive) I seem to remember getting an ISAM error, not an OS error (i.e > error -28). > > Neil > > Art S. Kagel wrote in message <37D6C54A.C65752B5@bloomberg.net>... > >Keith Sharp wrote: > >> > >> I am still having problems archiving using ontape. Level 0 archives > prompt > >> for 2nd tape but get an error -28 before prompting for a third. Level 1 > >> archives do not prompt for a 2nd tape, I just get the error -28. I know I > >> need to get a higher capacity tape drive ( I am about to raise hell about > >> it, as I've been asking for 3 months.). > >> But..does anyone know if there is a constraint on number of tapes used > for > >> various level archives? I have toyed with the TAPESIZE variable to no > >> avail. > > > >If reducing the TAPESIZE parameter drastically does not solve this then > >your problem is most likely that you have run out of tempdbspace NOT tape > >space. There is not constraint on the number of volumes a tapeset can > >contain in any archive level. You do not state what version of IDS you > >have. If 7.2x you need to have one VERY big tempdbspace for archiving > >purposes, for 7.3x the archive algorithms changed and archives can > >successfully use several smaller, but preferably equal sized, > >tempdbspaces. > > > >What is happening is that during the archive any physical log pages that > >will need to be archived are copied to temp tables in tempdbspace one per > >dbspace. In 7.2x these tables all live until the ENTIRE archive is > >completed, even though its contents have been dumped to tape when the > >corresponding dbspace has been archived, and each temp table lives in one > >tempdbspace with the tables assigned to tempdbspaces round robin as they > >are created. If two active dbspaces happen to have their temp tables in > >the same tempdbspace you can imagine that that tempspace may fill while > >there is still plenty of space in the others. If this happens the archive > >will exit with errno 28. For this reason you should have only one or > >perhaps two large tempdbspaces to prevent them from filling during > >archives, even though sorting will be faster with more smaller > >tempdbspaces. > > > >In 7.3x each temp table created for the physical log pages (indeed any > >temp table) is fragmented across ALL tempdbspaces and each table is > >dropped once its dbspace has been successfully archived and the physical > >log pages it holds have been dumped to tape. This means you need less > >tempdbspace and can take advantage of more tempdbspaces for better sort > >performance. > > > >Let's put this one in the new FAQ, but perhaps use my last response to it, > >which may have been clearer (I'm tired). > > > >Art S. Kagel

Art S. Kagel wrote in message <37D7D901.A7668C53@bloomberg.net>... >Except in private communication Keith tells me he has no tempdb space so >his temp tables may be going to filesystem space in /tmp which would get >the errno 28, I guess I suppose it just reinforces the maxim "Don't comment when you know only half the story" But it's a lesson that,try as I might, I just don't learn!

In article <37D7D901.A7668C53@bloomberg.net>, kagel@bloomberg.net (Art S. Kagel) wrote: > Except in private communication Keith tells me he has no tempdb space > so his temp tables may be going to filesystem space in /tmp which would > get the errno 28, I guess.?? Keith mentions he tried reducing TAPESIZE > and I did imply that he should try reducing it drastically to eliminate > the possibility that his assumption of running out of tape is correct. > > Art S. Kagel > Isn't that insider dealing:-)) That's frowned on in the UK financial markets, maybe the US is different :-)) Paul Watson # I don't suffer from WF Software Ltd. # stress, I'm just Tel. (+44) 1436 674729 # a carrier Fax. (+44) 1436 678693 # www.wfsoftware.com

Neil Truby wrote: > > Art S. Kagel wrote in message <37D7D901.A7668C53@bloomberg.net>... > >Except in private communication Keith tells me he has no tempdb space so > >his temp tables may be going to filesystem space in /tmp which would get > >the errno 28, I guess > > I suppose it just reinforces the maxim "Don't comment when you know only > half the story" But it's a lesson that,try as I might, I just don't learn! Nor I, sadly. :-( Nor I. Art S. Kagel