Re: Un-attended Large Archives

Naomi Walker writes: |> Speaking of which, on page 3-113 of the Online 5.0 System Administrators |> manual (my bible), there is a list of "THINGS to AVOID in the ONLINE |> ENVIRONMENT". Item #3 states: |> |> Do not define your archive tape devive (TAPEDEV) as a named pipe. |> |> Can anyone please tell me why not? We have been doing our archives thru |> a named pipe on many production systems, and have restored with no problems. |> Maybe i'm headed for trouble and dont know it yet. When you perform a system archive, it has the potential to be multi-volume. If you fill up a volume, you will be prompted to mount a new volume. When you do so (and type "yes" or whatever), the first thing tbtape does is read the first block from the tape, to make sure that it is not the tape that it just finished writing (just in case you type "yes" before you change the tape ;-)) It determines this by checking the tape header that is written to the beginning of every tape. If it is the same tape, it will write a message telling you to mount a *new* tape. Thus, tbtape will not allow you to overwrite one volume of an archive with another. If the tape passed the check, it rewinds the tape (by closing it then reopening it) and starts writing to it. The first thing it writes is a new tape header. Now according to the info I have on FIFOs (named pipes), written data is read back in FIFO order, and single write and read system calls are guaranteed to be atomic. Data once read can't be read again. Herein lies the problem. If you write the last batch of volume one to the FIFO, and tbtape closes it and prompts for the new tape, then opens the FIFO again (thinking it the new tape) and reads the first block to do the tape header check, one of two things will occur: first, if the reader of the pipe (i.e. the process on the "other end" reading tbtape's stuff) has read all the stuff from the FIFO, then tbtape's read for the header check will fail; or, if the reader did not read it, then tbtape will read it and that reader will lose the end of the previous volume, rendering the archive corrupt. You will not be able to restore from such an archive. Based on your account of the FIFO working, I'll assume you never get into multiple volume situations. Indeed, if you can guarantee single volume archives (make your TAPESIZE parameter bigger that the total amount of data that could be contained in the archive), this probably could work. Of course, given that blurb in the manual, Informix does NOT support archives done in this manner, and any problems you incur with it are *your* problems. One final note: if you do choose to use the (unsupported) named pipes for your archives, you should set your BLOCKSIZE (in OnLine) to be <= the "capacity" (or buffer size) of the pipe. Of course, if my understanding of the nature of named pipes is incorrect, none the above (other than my first paragraph) does not apply... Dave Disclaimer: These opinions are not those of Informix Software, Inc. ************************************************************************** "I look back with some satisfaction on what an idiot I was when I was 25, but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney