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




On 18/05/2006, at 10:27 PM, Adrienne McConnon wrote:

Below is the code that was used to display the displays above. I did change the first parm to be 'by reference' instead of by value. As you can see by the results below, it is still writing garbage.

Ah, I thought you were using write but I see you are using fwrite. Different set of parameters required. See below.

Currently, I will be R/W to byte-stream files. I have another question - is there any benefit to maniputating these files in libraries?

If by "these files" you mean stream files then they can't exist in libraries. You can use fwrite (and its sister APIs) on *FILE objects but that's a dumb idea. COBOL has better support for *FILE objects in its native I/O operation codes.

Does the files origin have any impact over which API's I use?

Of course. Use stream file APIs for stream files and native op-codes for *FILE objects.

One possible exception is the C _Rxxxxxx APIs which will handle *FILE objects but again COBOL has much better native support.

Thanks again for your help!

Adrienne



0107.30                DISPLAY 'IFS-FWRITE'.
0107.32                DISPLAY 'LENGTH=', LENGTH OF BUFFER.
0107.33                DISPLAY 'Buffer before write:' BUFFER.
0107.36
0107.37                CALL PROCEDURE '_C_IFS_fwrite'
0107.38                    USING BY REFERENCE BUFFER,
0107.39                           BY VALUE LENGTH OF BUFFER,
0107.40                           BY VALUE FILE-PTR.
0107.41       *        CALL PROCEDURE '_C_IFS_fwrite'
0107.42       *            USING BY VALUE ADDRESS OF BUFFER,

fwrite requires FOUR parameters. You are only passing three. You need to pass the buffer, the size, the count, and the file pointer. I'm surprised that your code works at all--it probably depends on whatever is previously in your code. You should be coding something like:

        CALL PROCEDURE '_C_IFS_fwrite'
                 USING BY REFERENCE BUFFER,
                 BY VALUE LENGTH OF BUFFER,
                                  COUNT,
                                  FILE-PTR.

COUNT should be set to the value 1. NOTE: SIZE and COUNT work together. In your case, because you are writing bytes, you can set SIZE to 200 and COUNT to 1 or SIZE to 1 and COUNT to 200.

In your code the COUNT is taken from the first four bytes of the value of FILE-PTR so you are writing 200 bytes times whatever that value happens to be. In essence you are writing the 200 bytes from your buffer plus whatever crap happens to be in storage after the buffer for however many bytes is indicated by the first 4 bytes of FILE-PTR.

Personally I think you'd be better off avoiding fwrite and just use the lower-level Unix file descriptor based APIs. That is use open, read, write, and close. Give fopen, fread, fwrite, fclose, _C_IFS_fopen, _C_IFS_fread, _C_IFS_fwrite, and _C_IFS_fclose a miss. The Unix file descriptor APIs are simply easier to use.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------



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.