Confounding -567 error
We have a 4GL report (r4gl 7.32, hitting IDS 10.00.UC5, Solaris 8) that occasionally fails with error -567 (cannot write sorted rows), ISAM -2 (no such file or directory). I have no earthly idea why. We do have PSORT_DBTEMP set to three different file systems, all of which are writable by Informix, and all of which have plenty of space available. Also, the temp spaces listed in DBSPACETEMP (which should be irrelevant with PSORT_DBTEMP set) have gobs of space available. Yes, we have support, and yes, I've opened a PMR (pending), but I was hoping someone here could shed some additional insight. As an added bonus, the problem seems to prefer to occur during the wee hours of the morning. I need to confirm with our developers, but I'm reasonably sure that the report runs from an automated nightly job -- when run manually, I believe the report runs successfully, with no such error. Any ideas? I'd be glad to provide whatever additional information you dee
Tom- I can't find the manual entry for it, but I seem to remember seeing that the PSORT_DBTEMP entries need to be writable by the user doing the sort as well as Informix. If that's not the case, try unmounting the file systems and look at the permissions on the unmounted directories. I've run across an instance where a mounted filesystem claimed to be rwxrwxrwx, but only root could write there. I unmounted the system and discovered the underlying permissions were something like rwxr-xr-x. Just something to look at... --EEM -----Original Message----- From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] On Behalf Of Tom Girsch Sent: Thursday, March 22, 2007 12:38 AM To: informix-list@iiug.org Subject: Confounding -567 error We have a 4GL report (r4gl 7.32, hitting IDS 10.00.UC5, Solaris 8) that occasionally fails with error -567 (cannot write sorted rows), ISAM -2 (no such file or directory). I have no earthly idea why. We do have PSORT_DBTEMP set to three different file systems, all of which are writable by Informix, and all of which have plenty of space available. Also, the temp spaces listed in DBSPACETEMP (which should be irrelevant with PSORT_DBTEMP set) have gobs of space available. Yes, we have support, and yes, I've opened a PMR (pending), but I was hoping someone here could shed some additional insight. As an added bonus, the problem seems to prefer to occur during the wee hours of the morning. I need to confirm with our developers, but I'm reasonably sure that the report runs from an automated nightly job -- when run manually, I believe the report runs successfully, with no such error. Any ideas? I'd be glad to provide whatever additional information you dee _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list
Everett Mills wrote: > Tom- > I can't find the manual entry for it, but I seem to remember > seeing that the PSORT_DBTEMP entries need to be writable by the user > doing the sort as well as Informix. Thanks. I'll double-check, but I believe the directories are world-writable. If not, I'll try setting them that way. > If that's not the case, try unmounting the file systems and look > at the permissions on the unmounted directories. I've run across an > instance where a mounted filesystem claimed to be rwxrwxrwx, but only > root could write there. I unmounted the system and discovered the > underlying permissions were something like rwxr-xr-x. None of the directories used are in the root of their respective filesystems. We have three very large file systems, we'll call them /fs1, /fs2, and /fs3. PSORT_DBTEMP=/fs1/psort:/fs2/psort:/fs3/psort