Created On: 10 October 2010
Problem:
We are receiving an error when trying to create a line sequential file bigger than 2GB. Why is this?
Resolution:
Since version 6.0.0 it is possible to access to sequential and relative files larger than 2GB on UNIX and Windows ports where such access is permitted by the OS.
Some UNIX ports will not be able to use this functionality either because the operating system just doesn't support it, or because the functionality was not detected at port time. To see if any given port has this functionality compiled in, the SYSTEM-INFORMATION structure (returned by ACCEPT FROM SYSTEM-INFO) in samples/def/acucobol.def has a new field, HAS-LARGE-FILE-SUPPORT. If the value of this field is "Y", the port supports this feature compiled in; "N", it doesn't.
Even if HAS-LARGE-FILE-SUPPORT is "Y", the underlying system must also support access to files larger than 2GB in order for this feature to work properly. Things that can preclude access to files larger than 2GB are:
* lack of kernel support
* lack of support in filesystem
* resource limits (ulimit -a, etc.)
A command such as:
$ yes | dd of=./bigfile bs=8192 count=327680
which will create a 2.5GB file named "bigfile" filled with "y", can help determine if a UNIX system is capable of supporting this feature.
If the system utilities such as "dd" or "cat" are unable to create a file this large, then the system as a whole is unlikely to support it as well. In order to use the large file API on UNIX, the config variable USE-LARGE-FILE-API must be set. (Setting this config variable on Windows is not necessary and has no effect.) On UNIX ports without large file support compiled in, this config variable will have no effect and the regular 32-bit file API will be used. On UNIX ports with large file support compiled in, setting this config variable will cause the new 64-bit file API to be used. Otherwise, the regular 32-bit file API will be used. This allows the large file support to be turned off on those systems which have the support compiled in, but which do not support it for one of the reasons listed above.
Some UNIX ports will not be able to use this functionality either because the operating system just doesn't support it, or because the functionality was not detected at port time. To see if any given port has this functionality compiled in, the SYSTEM-INFORMATION structure (returned by ACCEPT FROM SYSTEM-INFO) in samples/def/acucobol.def has a new field, HAS-LARGE-FILE-SUPPORT. If the value of this field is "Y", the port supports this feature compiled in; "N", it doesn't.
Even if HAS-LARGE-FILE-SUPPORT is "Y", the underlying system must also support access to files larger than 2GB in order for this feature to work properly. Things that can preclude access to files larger than 2GB are:
* lack of kernel support
* lack of support in filesystem
* resource limits (ulimit -a, etc.)
A command such as:
$ yes | dd of=./bigfile bs=8192 count=327680
which will create a 2.5GB file named "bigfile" filled with "y", can help determine if a UNIX system is capable of supporting this feature.
If the system utilities such as "dd" or "cat" are unable to create a file this large, then the system as a whole is unlikely to support it as well. In order to use the large file API on UNIX, the config variable USE-LARGE-FILE-API must be set. (Setting this config variable on Windows is not necessary and has no effect.) On UNIX ports without large file support compiled in, this config variable will have no effect and the regular 32-bit file API will be used. On UNIX ports with large file support compiled in, setting this config variable will cause the new 64-bit file API to be used. Otherwise, the regular 32-bit file API will be used. This allows the large file support to be turned off on those systems which have the support compiled in, but which do not support it for one of the reasons listed above.
Incident #2478277
Support
Documentation
Learning Services
Partner Programs
