When we install the 5.0 version do we need to recompile all programs especially those using ISAM-A. I am beginning to see some ISAM free list errors using programs compiled under 4.9 and then running under 5.0. And it’s not every run on the ISAM-A file. It is random. Under 4.9 on production we have been running ISAM-A now for a month without a glitch.

Typically, I would recompile under the latest release, but with 800 programs this takes a bit.

Is this a 5.0 issue or a compile under one vers and then run under the new vers?

As a general rule, I don't think that recompilation is necessary. However, there have been a lot of compiler and runtime improvements between 4.9.949 and 5.0.992, so to eliminate this as a concern, I would probably recommend recompilation. (It would be interesting to do a before/after verify to see if the hash really changed on any of the programs though. If the hash does change, use VERSYS to verify that the header signature, which depends on the compil flags, hasn't changed. If the signature stays the same, meaning that you have the same flags, and the hash changes, it might be worth sending me the program to see what the explanation for the changed hash is.)

As for the logistics of recompiling, there are a number of utilities floating around that will effectively perform a wildcard compile. One is RECOMX.BP (You need to modify the CMPSWITCHES value and recompile it first, so that it uses the desired switches. Then just execute RECOMX in a directory to recompile all the programs in that directory. It will tell you which ones didn't compile, but because of the uncertainties surrounding your query, I recommend making a backup copy of the RUNs and creating a DIR/D/V/H OLD.DIR=*.RUN listing which you can use VERIFY on afterwards.

There's another thread here discussing bulk recompilation which you might want to review: http://www.microsabio.net/ubb2/ultimatebb.cgi?ubb=get_topic;f=13;t=000095#000001

Finally, when you say you've been getting some free list errors, this is worrisome, but can you be more specific? Are you getting Basic errors? ashlog.log messages? Do you mean on old ISAM or ISAM-A? Note that ISMUTL has a nice VERIFY function to check the file structure - is that reporting any errors? There is also a nice utility, ISMCHK, which you can find in the [908,33] directory of the SOSLIB, which is similar to the ISMUTL VERIFY but designed to run unattended, producing a log, possibly even emailing/faxing it to you.

There really haven't been many reports of chronic ISAM-A problems, and there are quite a few sites with large numbers of users and/or large files. But obviously we don't want to let the problem fester so let's try to dig up whatever information we can to isolate it.

The free list errors were BASIC error code 231 - ISAM file must be rebuilt using ISAM-A running under 5.0.999.2 with programs compiled under 4.9. I then used ISMUTL VERIFY which told me the Free List was trashed. I did a REBUILD and all is well.

I will work on getting all under 5.0.999.2, compiling and trying it this way. I'll also compare the hash codes.

I think this error has been added since 4.9, in fact I may be the cause of it being added! Before, it was not giving any error, but I can't remember how it was caught. I have used the new ISAM for 5 or 6 years with 1 site having a file over 2 GB. I can, almost every time we have a problem with an index, pin it on the server rebooting unexpectedly or being shut down due to power failure and the battery backup failing. There are times we don't know what caused it, but I would guess it's not A-Shell.

One thing we have resorted to when the rebuild does not work is to rename the file, allocate a new one, copy the dat file back and then do the rebuild. This has always worked for us.

What I guess I'm trying to say is, I doubt the problem has anything to do with going from 4.9 to 5.1, just the addition of this check that is now telling you something that you didn't know before, but existed.

Thanks for the reminder about that, Herman. Looking through the code, it is true that a number of additional consistency checks were added to make sure that the key and associated data record matched, all of which generate error 231 (which is supposed to mean simply "ISAM+ index must be rebuilt"). I thought all of those checks had been in place by 4.9.949, but I'm not positive about that. (Herman is working in Windows, so I was focused on the issue there, and it's possible that there was a delay in migrating the changes to the AIX version.)

In any case, I think I would start by running the ISMUTL VERIFY on all of your ISAM-A files, as it may well be that you are only now noticing corrupted indexes that have been there awhile.

As for Herman's comment about the "rebuild-of-last-resort", the issue is that most of the file structure information (rec size, keys, etc.) is in the index file, so if it becomes too badly corrupted, the auto-rebuild cannot fix it. The workaround described works because it creates a fresh new index with the correct structure information. Then the rebuild option can use the correct index structure with the current data file to update the index. However, this is a fairly rare situation, and you would be able to detect it by running the ISMUTL VERIFY, or ISMCHK, after rebuilding in the normal way.

I setup ISMCHK and ran it on my production for well over 400 clients. Due to the limited time (one month) we've been using ISAM-A there are not a lot of record, but average is a few hundred records per index file. I found no errors at all under 4.9 AShell files.

I did have another error 231 today under 5.0. I am doing a lot of checking to see if I can narrow down the cause. But, a REBUILD fixed it.

Friday night we will be upgrading another AShell partition to 5.0. We will then compile and RUN under 5.0 and see if we get any further errors.

Very strange and hard to isolate.

Alas, this issue has been resolved with much digging. Two problems: One was a Basic LOOKUP statement returning 0 if the ISAM-A .DAT file had zero blocks. This result was being used to condition whether to create an empty ISAM-A (assuming the file did not exist). Long story short we lookup the IDX now instead. Second problem was an archive issue in this old software I'm attempting to REWRITE. It was archiving the .DAT isam-a file and not the .IDX. When a restore was done it would replace the .DAT and not the .IDX eventually causing a mismatch.

So, no AShell 5.0 issue and I am happy ISAM-A is working because my job depends on this working.

Thanks, Jack