ISAM error code -79 (No record locks available) when creating a n ew table

OK, I plead ignorance as to "our" record locking scheme. Actually, I believe we have none. I continue to receive this error, even after a cold-boot, and the system is essentially "quiet" Any pointers or gentle reminders? SE 05.00.UC6

"Pachiano, Vince" wrote: > > OK, I plead ignorance as to "our" record locking scheme. > Actually, I believe we have none. > I continue to receive this error, even after a cold-boot, and > the system is essentially "quiet" > > Any pointers or gentle reminders? > > SE 05.00.UC6 If memory serves, SE can lose track of locks in a crash and the earlier versions, ie <7.xx, used files for locking. Look in the database directory for lock files. I no longer remember what they are called. Art S. Kagel

Vince, I would suggest the engine is using kernel locking and the error indicates that you don't have enough locks configured in the kernel, given that you have rebooted unix and the problem still occurs. Pachiano, Vince wrote: > > OK, I plead ignorance as to "our" record locking scheme. > Actually, I believe we have none. > I continue to receive this error, even after a cold-boot, and > the system is essentially "quiet" > > Any pointers or gentle reminders? > > SE 05.00.UC6 -- Gordon Hooker Informix Software (Sydney, OZ)

Thanks Gordon for your reply. I believe you have told me exactly what the manual/finderr for error 79 states. So.... Now what? Is there a file somewhere that Informix uses to store locking information? Is it internal to the O/S? > -----Original Message----- > From: Gordon Hooker [SMTP:ghooker@informix.com] > Posted At: Thursday, August 05, 1999 8:26 PM > Posted To: informix > Conversation: ISAM error code -79 (No record locks available) when > creating a new table > Subject: Re: ISAM error code -79 (No record locks available) when > creating a n ew table > > Vince, > > I would suggest the engine is using kernel locking and the error > indicates that you don't have enough locks configured in the kernel, > given that you have rebooted unix and the problem still occurs. > > Pachiano, Vince wrote: > > > > OK, I plead ignorance as to "our" record locking scheme. > > Actually, I believe we have none. > > I continue to receive this error, even after a cold-boot, and > > the system is essentially "quiet" > > > > Any pointers or gentle reminders? > > > > SE 05.00.UC6 > > -- > > > Gordon Hooker > Informix Software (Sydney, OZ) << File: Card for Gordon Hooker >>

Art S. Kagel wrote: > "Pachiano, Vince" wrote: > > OK, I plead ignorance as to "our" record locking scheme. > > Actually, I believe we have none. > > I continue to receive this error, even after a cold-boot, and > > the system is essentially "quiet" > > > > Any pointers or gentle reminders? > > > > SE 05.00.UC6 Hmmm. This is not deemed Y2K-compliant. Consider an upgrade. If you ever use 2 digits to identify years, the SE software will continue to add 1900 to the date, even after the end of this year. See the documentation -- it means what it says! > If memory serves, SE can lose track of locks in a crash If either the system or sqlexec crashes, then you lose the locks if the kernel is handling the locking -- there is no central daemon hanging around to clean them up (and no way for a central daemon to do it even if one were created). > and the earlier versions, ie <7.xx, used files for locking. Some older versions of SE used lock-file locking, which used a .lok file in the dbase.dbs directory. However, this was always a last resort -- the performance is much worse and Informix would use fcntl(), locking(), flock(), lockf() - or probably any other kernel locking mechanism which was available. One of the last holdouts of CREATLOCK locking (named after the #define in the source code) was SunOS 4.x; I do not recall exactly when it switched, but it was nearly 10 years ago, in the early 5.0x time-frame. There are many disadvantages to lock files. They are slow, you can only have 64 locks per file (to limit the slowness), and if a process dies without releasing its locks, the rest of the code continues to note that the locks exist. So, if the SE is using lock files, then the locks are not lost when the engine crashes, but they aren't any real use either. If you're sure no-one is using the system, you can clean up stray locks by removing all the lock files. > Look in the database directory for lock files. systables.idx systables.dat systables.lok > I no longer remember what they are called. I guess your are not using RAID10 :-) ...and addressing the original problem... You need to check your kernel configuration to establish whether any file locks are provided by default. If not, you will need to reconfigure (rebuild?) your kernel and (probably) reboot. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>