Issue:
Mature version 9.1e character base application ... simple schema change generating core dumps with kmkinit idx errors when attempting to either:
a) load a df file
or
b) manually update the schema in the RRE
Background:
- added a date field to a table that tracks user logins (initial value ?)
- added this new field to a new index via the RRE - Data Dictionary - Schema - Edit Index
- any attempt to accept/apply the new index causes a core dump with a kmkinit idx error
- any attempt to load a df file also causes a core dump with a kmkinit idx error
- there are several area's assigned to this db ... tried assigning this index to an area not currently used by the specific table
- ProKB only references kmkinit as some v11.0 temp-table issue ... this KB reference doesn't sound like it is related to the error I am receiving
- as a work around, I was able to add the index as inactive ... then successfully activated the index using idxbuild from the OS command line
- 18+ years of working with Progress and never seen this issue before
- we had a 3rd party do some maintenance on the db recently but they are not aware of doing anything that would cause this
- kmkinit is not listed anywhere in _index and is not part of the application so expecting this is some Progress internal process
Questions:
1) is this an error anyone has seen before?
2) is there some diagnostic/log/trace I can run or view to help identify the source of this process error?
ultimately the biggest concern is this error may have implications beyond just a simple schema change
Thank-you in advance for your time.
Re-index of the 11.6 version of the db corrected the kmkinit idx issue ... we are going to attempt to do a reindex of the 9.1e version as well only because it will take some time to complete testing required on the 11.6 version before it can go live.
For some reason, the AVM's cache of the indexes does not have an index number for a specific index. This is as internal condition that should not occur. Until we know the cause, I cannot guess any implications. I would recommend contacting Tech Support, to see if this is a known bug. There have been a couple of bugs related to this fixed since 9.1E. I cannot guarantee you'll get a fix in 9.1E, being so old.
Standard response for ancient versions.... Your version is ancient and if you care about your data an upgrade to a modern release is in order. At least make sure you are on a decent SP level for 9.1E to start.
Now for some level of help :-)
According to the help message for error 131...
SYSTEM ERROR: kmkinit -- idx not found. (131)
An unexpected system error has occurred. Please do the following:
1. If the error occurred while running an existing application or
during database admin functions, the error may be due to a
hardware/system problem, r-code corruption, or data corruption.
Note what was processing during the time the error occurred.
Check your system error logs and Progress database log file for
any additional errors.
I would check the database log file for any other errors... and probably run a few checks against a restored copy of this database.
Also I would compare your current OS version against what is actually supported for 9.1E. If you are running on 9.1E era hardware you are likely to have a few issues.
Ancient kbase article:
Solution: 17990 Type: N
Title: SYSTEM ERROR: kmkinit -- idx not found. (131)
Written by damore 01/06/98
Modified by damore 01/06/98
SYSTEM ERROR: kmkinit -- idx not found. (131)
This error typically shows up when changed indexes are being updated. Index keys are being checked for validity and created if needed throughout this process. We are checking for the type of update being peformed, such as SQL for example, and making the necessary changes to the index. (creates, updates, deletes etc.)
When we get to the stage when we are adding a new index entry, we are scanning through all of the records validating all the keys. If we encounter a duplicate key at this point, an error message will be sent out and the index would have to be repaired, preferably with idxfix.
If we don't have a problem with the index key validation process, we then assign an initialized status to the index. This is the point where we can see the SYSTEM ERROR: kmkinit -- idx not found. (131). Before kmkinit can assign a status to the index,we must go through the index manager to find the index. If we don't find it, then we see the error.
It seems strange that we are in the process of validating components of the index, yet when it is time to assign a status to the index we cannot find it. If this sounds like index corruption to you, then you are heading in the right direction. In most cases, and index rebuild should eliminate this error and has been very effective in doing so. A potential cause of the problem may be an error process of modifying, creating , or deleting an index. However, the proutil -C idxbuild should get you around the problem.If not, then test indices could be run, and that would take significantly longer.
SDA 6/1/98
Thank-you for all the feed back ... a copy of this 91e db was just moved to a new machine loaded with the latest version of OpenEdge 11.6 but still has the kmkinit idx issue ... have requested that the person(s) involved with this new install do a complete re index of the db ... will post an update once that is completed
Re-index of the 11.6 version of the db corrected the kmkinit idx issue ... we are going to attempt to do a reindex of the 9.1e version as well only because it will take some time to complete testing required on the 11.6 version before it can go live.