Hi,

I think under the circumstances the best option is to get
help from IBM Informix Tech Support. Since this is an
old version (10+ years) you will have to negotiate something
on a time+materials basis. Then they will be able to analyze
the problem and possibly advise how to fix it (permanently).

> Upgrading is not an option; they are locked into this version
> due to regulatory constraints.

Hmm. I would like to see the "regulatory constraints" that force
e.g. a viable logistics business to still use trucks that are
10 years and older, preventing them from modernizing their
fleet of vehicles. Everybody sees that such regulation would
be quite stupid ... but with software? ;-)

Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

IBM Deutschland GmbH
Chairman of the Supervisory Board: Hans Ulrich Märki
Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael
Diemer
Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart,
HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940

informix-list-bounces@iiug.org wrote on 25.06.2007 22:27:50:

> I'm looking for assistance with Online version 5.0.5. I need to know
> if there is a way to detect problems at the system level of an Online
> 5 instance besides using tbcheck.
>
> Informix version: Online version 5.0.5 UC1
> OS: SCO Unix System 5 Ver. 3.2
>
> The whole story:
> One of my clients provides software and servers to a number of their
> clients. Their application is running on Online 5.05.UC1 on SCO
> boxes. Upgrading is not an option; they are locked into this version
> due to regulatory constraints. The application database never exceeds
> about 500 MB; they provide a process to remove old records as the
> database grows so that their clients never have to be concerned with
> adding disk space or other administration tasks.
>
> The problem is this: They've run into an issue with several of their
> biggest clients where informix tbtape archives stop working properly.
> Rather than taking an hour as expected, the archive takes just 5-10
> minutes, then when my client tries to restore their archive to his
> server, the restore completes in just 5-10 minutes but doesn't really
> restore anything and the database is "broken" (tbchecks against the
> resulting database report errors). Tbtape reports no errors; the
> normal archive started and completed messages appear in the online
> log. No errors appear in the online log of the restored instance,
> either.
>
> I've had him run tbcheck -cr, -cc, and -ce on the originating
> instance, and all come back with no errors. There are no tbcheck data
> or index errors in the databases of the originating instances and the
> application works without error. The only symptom (and problem) is
> that an archive won't work.
>
> Because the problem is apparently at the system level of the instance,
> a workaround is to dbexport the data, reinitialize the instance, then
> reload the data. This does correct the problem. However, it would be
> preferable to have a way of recognizing that the problem exists
> without having to rely on spotting a bad archive. In some cases,
> tbstat -d and tbcheck -pe return negative page counts, which makes it
> obvious. But in most cases there is nothing at all to indicate that
> something is wrong.
>
> So, back to my original question: Is there a way to detect that there
> is something wrong at the instance level besides using tbcheck? Since
> this is version 5, there is no sysmaster database to query.
>
> Thank you in advance for any assistance you can give me,
>
> Barrie Shaw
> Xtivia, Inc.
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list