× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



The APIs are prototype don the rpgiv.com website.
http://www.rpgiv.com/downloads/

The directly link to the page you want is:
http://www.rpgiv.com/cgi-rpg/viewsrc?FILE=QCPYSRC&LIB=RPGLAB&MBR=IFSPROTOS

Read and Write use either "handle" to read the data. You have, what about a
2GB "limit" on the data you read at once, but that doesn't mean you can't
read multiple times to get all the data.
Scott K. would know this stuff best, but I don't think it matters which
open() or open64() you use when reading the file. I always use open64()
since it is actually 'faster' according to IBMers.


-Bob Cozzi
www.RPGxTools.com
If everything is under control, you are going too slow.
- Mario Andretti


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Chris Wolcott
Sent: Wednesday, July 06, 2005 1:16 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: MCH3601 error (Jeffrey Young)


Thanks.  This brings up another question I had about Large File Support.
Does the O_LARGEFILE value act the same as SYSIFCOPT(*IFS64IO) in a C
create command?  

If so, is the return from the read/write not a 20U 0, not a 10I 0?
(Along with the nbyte field -- unsigned long long instead of a signed
long (int)?)  From another project enabling our C programs for large
files, I know that off_t and size_t get redefined as unsigned long longs
when using *IFS64IO. 

Do the unix style calls have 64 bit versions, as fopen() =>> fopen64()?

> ------------------------------
> 
> message: 4
> date: Wed, 6 Jul 2005 08:26:33 -0700 (PDT)
> from: Jeffrey Young <cooljeff913@xxxxxxxxx>
> subject: Re: MCH3601 error
> 
> Try using the UNIX style API's ... open, close .. etc.
> 
>> SOME REMOVED <<

>      D*                                            Large file access
>      D*                                            (for >2GB files)
>      D O_LARGEFILE     C                   536870912
> 

>> MORE REMOVED <<





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 by midrange.com 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.