× 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.



Although a natural assumption, I guess Lim, it's "he" and not "she" when
you are talking about me.

http://www.mc-store.com/shanod.html


Ah...the dangers of assuming...




-----Original Message-----
From: rpg400-l-bounces+sodonnell=turbogorilla-software.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+sodonnell=turbogorilla-software.com@xxxxxxxxxxxx]
On Behalf Of Lim Hock-Chai
Sent: Friday, November 30, 2007 1:17 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Send_File API versus Send API over a Socket

Thanks for the explanation. As mentioned before, I'm not very familiar
with those functions.

My assertion merely base of parameters of fread() and read(). As you
might notice in Shannon's email that she was not very clear on the 2nd
(unitSize) and 3rd (Number of Unit/Item) parameters in fread(). Unlike
i-Serial, database is not part of unix OS. Hence, sometime unix
programmer write application to store DB like data into a stream file,
which make me to think that fread() is intended for this type of stream
file.



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Friday, November 30, 2007 12:14 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Send_File API versus Send API over a Socket

Actually I *did* suggest that Shannon use read() in a prior message.
However, I disagree with your assertion that fread is unsuitable. It's
not. fread is intended for this type of thing.

The difference between read() and fread() has to do with their origin.
read() is a system API -- a component of the operating system. fread()
is part of the ILE C runtime library.

read() comes from Unix and is intended to be available with the same
syntax on all POSIX compliant systems (read: Unix systems). i5/OS
supports it as part of the "Unix-type APIs". It is not part of the C
language, however. read() can be expected to exist on any compliant
system, even if you don't have a C runtime installed on that system.

However, fread() is part of the C language. Any system that supports
ANSI C will always have an fread() function, even if it doesn't make any
attempt to conform to POSIX. For example, Windows has an fread()
function, but not read().

So the difference isn't really what purpose their suited for -- the
difference is what environment you're in. Both functions are suitable
for reading binary objects, including image files. (However, fgets() is
not -- and that was the original problem.)

In RPG on i5/OS, the distinction doesn't matter much to us, since both
are always available. If Shannon prefers to use fread(), let him use
fread().


Lim Hock-Chai wrote:
fread() function seems to be designed to read stream file where data
in the file is segmented and, just like record in a database file,
each segment has the same length. Of course, by passing those
parameters the way you suggested would allow Shannon to know the
length of data that this api has read. I'm just curious as why not
just use the read() function. This function seems to be a more
suitable function to use when needing to read an image file.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.



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.