At Compupay/Benefitmall we moved our Production system from Florida to a Tennessee server. Ever since this move we have been getting Device 20 Errors on one particular ISAM-A file during repeat Delete'Record calls. The program is looping thru the index: Get'Next, Get'Locked the record and then Delete'Record the record until we reach the end of what we want deleted. I added TRACE=BASERR to the miame.ini and here is the log detail from ashlog.log below. Can you make any sense of this to give us a clue of how to resolve. We did ISMUTL and REBUILD, I wrote a program to create a new empty file and then copied the records. Same issue on the new file so it is not the index or record pointers. I rearranged the logic in the program performing this loop/delete and same result. This did not happen on our previous server.

Jack R.


13-Sep-18 15:10:15 [p17696110-j0]<> jcbrebuild #0
13-Sep-18 15:13:10 [p30344540-j42] Isam error: mode:8, chan:8561, iserrno:27, filstat:-1
13-Sep-18 15:13:11 [p30344540-j42] Trapped Basic Error #20 last line # 3234 (location 28276)
13-Sep-18 15:13:11 [p30344540-j42] System Error Log: C errno:27, last instr:0x39, host OS error:27, DDB error:7, mode:6, chan:8561
13-Sep-18 15:13:11 [p30344540-j42] >>File too large (/miami_admin/trs0/777001/td2018)

More detail. It says the FIle too Large but it isn't that I can see:
TD2018 DAT 2528771 TRS0:[777,1]
TD2018 IDX 455776
Total of 2 files in 2984547 blocks

More detail: The # of records (approx. at last ISMUTL STAT) was "Number of records loaded: 6451252" and counting.

Hmmm......

Is this AIX? A-Shell version?

Errno 27 really is "file too large" under both AIX and Linux, but since it's not close to the 2 GB threshold, it's probably related to the ulimit settings. What does ulimit report?

It's strange that a ulimit problem would appear on a delete rather than an add, but if you moved these files from another system, you may have done so under a different login that had unlimited ulimit, and now the ulimit is being enforced only on write operations(?) or just periodically(?)

ulimit say "unlimited". Yes, AIX.
Have to sign off for the day. I will check back tomorrow. Thanks.

It's hard to see what other kind of threshold you would be hitting in the vicinity of 1.2GB. Let's double-check the file size using ls -l to make sure DIR isn't misreporting it.

If it really is hitting 2 GB, then we could have another issue. You'll need to have ISAM-A version 6.11l or higher (I suspect you have 6.11j).

But back to the immediate problem, let's check your /etc/security/limits file to make sure that all the users that matter (especially the user that owns the ashell executable, assuming you have the +s bit set) have no hard or soft size limitations. One theory would be that [i]your[/u] ulimit is unlimited, but ashell's is not. Similarly, if there is some kind of IBM storage manager overlay (or NFS?), it might have its own user identity and limits.

Basically, I'm having a hard time seeing how OS error 27 (file too large) could be anything other than a system-imposed limitation.

If you have enough disk space, it might be interesting to create a simple program which just keeps adding records to see how far it goes before getting an error.

Thanks, Jack M. I will work with Helmuth (our unix support) on my end and see what we can find.

Here are the file sizes:
JRR-PAYROLL) host ls -l td2018.*
-rw-rw-rw- 1 breamg payopt 1296345897 Sep 14 00:32 td2018.dat
-rw-rw-rw- 1 breamg payopt 233884672 Sep 14 00:32 td2018.idx

Well, seems Helmuth is out today. Will take this up with him on Monday. Your mentioning it truly should get an error when adding records but this is added to each night without fail. The file continues to grow daily. The Delete function is the only statement having the issue and it is only used when a payroll is recalculated so the program needs to delete the records so replacements can be added. Very strange.

Have a great weekend.

OK, that just confirms that the sizes listed in the earlier DIR were correct. They are big files, but not big enough to suspect 32 bit problems. Sure seems like a system restriction, ulimit or otherwise.

Oops, crossing posts. The fact that the file continues to grow seems to undermine my theory. It's very weird that Delete would be special. I'm beginning to wonder if it could be some glitch in the ISAM-A logic that is causing it to come up with a bad offset in the course of the delete operation.

Do you have any other files this large?

Does that error location (last line # 3234, location 28276) point to delete'record statement?

What does ISMUTL report as the version, i.e.

(It's the character after the 6.11 that would be important to make sure we are on the same page.)

I'll review the code to see what other ideas might come to mind.

I created a test file here, doing adds and deletes well beyond the size of your file. I didn't encounter any problems with either the current 6.4 version or an old 6.0.1240.2 version.

If your version is older than that, let me know what it is (and maybe you'll need to email me a copy) and I can try ruling out the possibility of the problem being version-related.

ISMUTL is Version: 6.11l MS9632/0999
Yes, we have files much larger than this but do not delete records from them. Yes, the basic error line is on the delete record.

Helmuth researched all ulimit settings and even compared the new server to the old. He found that root for one specific account was set incorrectly. He has changed that now and we are refreshing any ashell jobs that need so they get the new root. We shall watch the next few days and see if this persists. I'll keep you posted. Thanks for the help as always.

Follow up on this. Once we had all users log off ashell and log back in to get the new root file size ulimit we have not had any further device 20 errors; been nearly 6 days now.

Thank you for your support and knowledge.

Jack R.

Thanks for the follow-up. Apparently, it's trickier than expected to get the new ulimit to take effect!