MF Cobol Sorting large files problem

[C Kishore]

On our production machine while doing sort through COBOL (file which is of 640 MB size.), we got cobol run time error

--------------------------------------------
"mergetemp(): mFt_os_write() failed errno: 27 (File too large) fe_stat: 28

I/O error : file 'SORT-FILE'
error code: 9/194 (ANS74), pc=0, call=1, seg=0
194 File size too large

HP/MF COBOL Version: B.13.40
HP-UX unibank B.11.00 U 9000/800
pid: 21874 gid: 105 uid: 104
Thu Jan 1 04:40:18 2004
4:40am up 6 days, 11:14, 5 users, load average: 0.31, 0.22, 0.19
Thread mode: No Threads
RTS Error: COBOL
Sync Signals: COBOL
ASync Signals: COBOL
cobtidy on exception: False"
----------------------------------------------

We enable largefile of the file system where the sort file is residing. Still we are getting the same error.

Is it required to review any unix kernel parameter for this problem.

Versions:

HP-UX 11.0 (RP7400)
MF Cobol 4.1 (Bundled with HP-UX)

This is very urgent, can any body please repond.

[Steven E. Protter]

The only thing I can think of is that you are trying to generate a file larger than 2 GB. Thats the exact operating system code you'd get back if you tried to create a file say 2.2 GB on a filesystem that doesn't have largefiles enabled.

Perhaps the cobol application is trying to create data files too large.

You can use the fsadm tool to convert the filesystem. Then just umount it, change the mount option to largefiles and mount it again.

SEP

[C Kishore]

We have already enabled largefiles for that file system. But still we are facing the same problem.

[Bill Hassell]

Was the COBOL program compiled for 64bits? If not, you'll likely need to change the code to change lseek to lseek64 (and equivalent file positioning calls). The filesystem may be capable but the program can't read or write beyond 2Gb.

[C Kishore]

Our cobol compiler (MF COBOL 4.1) is 32 bit.
We are using SORT verb of COBOL in the cobol applications, we are not using lseek.

[A. Clay Stephenson]

I have a hard time believing, even with very stupid indexing schemes, that code could create a sorted file over 3X bigger than the original 640MB file to reach the 2GB limit.

There are 2 other things that can trigger an errno = 27: 1) ulimit 2) quotas

Use ulimit -a to check ulimits and also check to see if quotas are in play on this filesystem.

Plan B. Format your data and call the UNIX sort utility.

[A. Clay Stephenson]

I have a hard time believing, even with very stupid indexing schemes, that code could create a sorted file over 3X bigger than the original 640MB file to reach the 2GB limit.

There are 2 other things that can trigger an errno = 27: 1) ulimit 2) quotas

Use ulimit -a to check ulimits and also check to see if quotas are in play on this filesystem.

Plan B. Format your data and call the UNIX sort utility.

Note also that the process itself can set ulimit which would not be visible to the calling shell. You really need to proble your code and determine ulimit at run-time.

If would be helpful to monitor the size of this file while the process is running and determine the size at failure (or as near as you can get it).

[Bill Hassell]

One other possibility is that the COBOL sort verb uses temp files located on volumes that are not largefile-enabled. In the meantime, use Clay's suggestion to call the HP-UX sort command.

[Sylvia Welch]

This is really wierd. We're having the same problem. We're investigating. We also found that even if TMPDIR is set for somewhere else, MFCOBOL is using /var/tmp to write its temporary sort file.

We cannot use the UNIX sort either.

[Bill Hassell]

If the MFCOBOL docs do not document the choice for a sort directory, try setting TEMP and TMP as well as TMPDIR. You might also see if strings prog_name shows /var/tmp hardcoded in the program. However, /var/tmp is the SysV V.4 filesystem layout location for application temp files, so you can always make /var/tmp a separate mountpoint and make it dozens of Gb in size if necessary.