anomalous tbtape behavior

OnLine 5.03 running on Sun workstations (SunOS 4.1.2); 8mm tape drive Same setup we've always had, doing Level 0 archives and Logical Logs routinely, no problem. Except recently we have attempted Level 0 archives--no system changes we know of--and the archive would only progress partway, stop (for example, at "24 percent done") and prompt to mount next tape and continue. It does this despite the fact that it has plenty of tape left to write to. When it continues, it does another few percent (usually to roughly 27-30% done), stops, prompts; continues with another few percent (usually to roughly 40% done), and on the last continuation it completes (that is, does the last 60% or so in one swat). So the archive ends up completed, but has taken 3-4 files instead of the expected 1 (one). Now, here's the tricky part: Informix technical help brought to my attention that our device name includes the "no rewind" option--i.e., /dev/nrst8-- which, according to the OnLine Administrator's Guide, V. 5.0, p. 1-28, is a no-no: "Tape devices that do not rewind automatically before opening and on closing are considered incompatible with OnLine operation." I don't really want to change the device name, since with our non-Informix tape routines--e.g., mt, tar--we always use no-rewind followed by mt... status so we know exactly what/how many files are on the tape. We always used tbtape followed by mt...status previously with no problem, despite the "incompatibility" alleged in the documentation. And we can label our tapes with exactly what files are on them, rather than trusting to the mysterious Informix tape numbering system. The last Level-0 archive prior to the recent problematic ones, was back in October with same tape drive, same OS, same computer, same version of OnLine, same device name, and it ran fine. Any hints as to what might be going wrong? Informix tech support said that as long as the archive completed we shouldn't have to worry about a catastrophe, but I'm not so sure. We are protecting ourselves with frequent UNLOADS and DBSCHEMAS but they sure tie up a lot of disk. Mark Heinicke mheinick@Glue.umd.edu