HELP PLEASE - Informix PTMAP errors and Turbo Hang

%UNIPLEX %TO informix-list@rmy.emory.edu %CC ELLIS Dave, ROWLANDS Paul, HESKETT Tony %FROM jgordon %SYSTEM DHLNET %SUBJECT HELP PLEASE - Informix PTMAP errors and Turbo Hang %VERIFY y %DATE 17/04/91 11:41 %REFERENCE 29955 Hullo, Help - PTMAP errors Turbo Hangs We have a problem with Informix Turbo .03L4 running on a Pyramid MIS Server 12/4 running OSX 5.0d. After installing a new application we have had 4 Turbo hangs stopping all operational applications using Turbo. Before the hang occurs, and it may be up to 24 hours before, we get a single ptmap error such as ptmap pagenum 426246476 partnum 1000015 The page number and partnum are always different but always in the rootdbs which doesn't contain any databases. We also sometimes see a logundo message this is always type 12 iserrno 135 and may occur several times. At the time of the hang we see I/O bad request chunk 0 pagenum 4 pagecnt 0 messages repeating endlessly in the log and these continue until Turbo is taken Off-line. At the same time the applications which are using E-SQL/C database driver routines start generating error messages showing that they are no longer talking to the Turbo backend. The Message queues used by these processes fill up and all informix work grinds to a halt. The first three occasions we took Turbo Off-line and then On-Line the fast recovery did not do any recovery and we continued as we could not find any database corruptions. The last occasion we had rebooted the computer, done full format read scans of the drives to check for bad blocks (None found), checked adm/messages for any other hardware failure messages (none) and done a complete disk initialisation of Turbo, recreated the chunks and reloaded the databases from ASCII unloads. With this completely clean environment we had a ptmap failure within 10 hours of bringing Turbo online, within 2 hours of bringing the application online and a hang 10 minutes later. No logundo messages were generated on this occasion. All four occasions appear to have been during busy periods for the new application. We are now attempting to duplicate the problem on a test machine so that we can analyse it, our view at the moment is that it appears to be a shared memory error but this may not be the case. If anyone out there has any suggestions on what might be causing the problem, previous experience with a similar problem and methods used to resolve problems like this we would very much like to hear from you. Any help/views on setting things up to try and force duplication of the problem would also be very useful. Any suggestions welcome. Thanks Jim Name : Jim Gordon Internet Address: jgordon@lhr-sys.ssf-sys.DHL.COM Organisation : DHL Systems Ltd (UK) Address : Kings House, Great West Road, Brentford, Middx, UK TW8 9HS Telephone : (+44) 81 747 8330 Ext 318 %UEND