Re: Unattended ontape

In a previous life of mine, I had a 'c' program that wrapped ontape via IPC pipes. So when the program would get messages from ontape, it would figure out what to do. If anything really wierd occured, then alarms would go off. Also, this was used with a multi-tape stacker. So the program did all of the mt commands to unload one tape, advance the tape loader, and load the next tape when it was time. It would zap the tape a bit so to ensure that the tape was loaded and then issue a 'mt rewind' command. Finally it would send the '\\n' to ontape via the pipes. Also this little 'ole program attached to an IPC shm that was allocated and kept a status of what was going on. This then was based and read by a monitor program that displayed on a gui command center termal so that all coporate operational statuses could be viewed from a single terminal. So from one control center, I could monitor my backups, monitor my disk usage, monitor txn rates, monitor my locks, etc... Also, I had this thing set up, so that all of the 4GL app programs could be traced dynamically, so that I could see what functions they were entering, how many machine cycles they spent in any functions, etc.... Also I could cause error statuses to be returned to the control center so that I would know of a problem that an agent might be having, even before they called with a problem. Really cool stuff. Then disaster.... We had a head crash. I went in to try to restore the server. When I tried to restore, I quickly discovered that what were marked as db backups were really system backups. So I ask --- what's going on here.... They said, the DB back only uses two tapes, so we started doing system backups immediatly after the DB backups. Then I say - how do you know that there are only two DB backup tapes. They said -- because that's what it was last year. Then I say --- yes - but the database has more than doubled in size since then. To make matters worse, the backups were simply tossed into a box when they removed them from the tape loader. Hundreds of dat tapes --- all unlabled. DB backups mixed up with system backups. Then it dawned on me that we had made it too easy for the operators... I was able to piece the system back together - took a lot of really fancy programming to do that. That's just about the time that I decided that it was time to leave... M.P. "Andy Kent" <andykent.bristol1095@virgin.net> wrote in message news:ac5fb36.0404190013.5203a518@posting.google.com... > I thought unattended anything was expressly discouraged with ontape? > > What if you get an error message, what if it needs to issue you with a > prompt you weren't expecting, etc. > > Andy > > Jonathan Leffler <jleffler@earthlink.net> wrote in message news:<VT4gc.13917$A_4.13712@newsread1.news.pas.earthlink.net>... > > Doug Lawry wrote: > > > Some recent threads implied that you cannot use ontape unattended. > > > I disagree! See Shell script below. > > > > > > Regards, > > > Doug Lawry > > > www.douglawry.webhop.org > > > > > > > > > # Run an automated Informix "ontape" backup > > > > > > # Doug Lawry, 20/11/95 > > > > > > case $1 in > > > '') set -- 0 ;; > > > [012]) ;; > > > *) echo "Usage: $0 level (0-2)" ; exit 1 ;; > > > esac > > > > > > AWK='NF > 0 && $0 != last {print ; last = $0}' > > > > > > exec echo | ontape -s -L $1 | tr '\\b' '\\n' | awk "$AWK" > > > > Interesting. Perfectly feasible as long as all the data always fits > > onto one backup device. Not sufficient for the more general case > > (larger database) where several backup devices are needed. If you're > > clever, you can use 'expect' to drive it more intelligently.