STATUS UPDATE:  On V5R2, if I explicitly define _LARGE_FILES &
_LARGE_FILE_API on the compile in addition to the SYSIFCOPT(*IFS64IO)
option the fwrite() seems to work as well.  My current guess is there is
a typo in one or more of the IBM header files that define which logic is
actually called under the covers.  

However, I still can not get it to work on V4R5.  Compiled on V4R5 I
still get the OBJECT TO LARGE error, and if I back compile the code on
V5R2 to V4R5, I get an error that the filename is not specified
correctly.  The earliest release I can back compile to is V5R1.  

> Chris,
> I can't be of much help as I haven't done it myself but since forum is
> quick to reply to your question today I figured I'd chime in.
> I can tell you that I didn't have much luck with fopen and other f*
> apis but have had great success with their sister apis like open,
> write etc.
> Perhaps you would have the same luck with those?
> HTH.
> Elvis
> -----Original Message-----
> Subject: [C400-L] Writing LARGE FILES
> I am trying to compile a C program that can read and write LARGE FILEs
> (> 2GB) to IFS.  I am using the fopen/fread/fwrite/fclose functions
> compiled with the *IFS64IO option.  The fread() can read the large
> but fwrite() still fails when it reaches 2GB.  I even tried explicitly
> using fopen64(), etc.  Still No Joy.  All that happens if I specify
> '#define __IFS64_IO__' is a warning that I can't redefine the macro.
> I even called IBM Software Support, and they currently have no ideas
> about why this is happening.
> I'd like this to work on V4R5, but would be satisfied with V5R1+.
> Has ANYONE gotten a C routine to write an IFS file larger than 2GB,
> how did you do it?
> Thanks

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].