OK, Bob,
Seems that I have to go a bit deeper into the details to get a better
answer.
My program uses existing interface, so it is out of my control.
It works as follows:
API response can be of any length. When it is called first time, it reads a
question and generates a reply, which is actually a set of records - can be
1 record, can be 10,000.
The response can be sent as a 3000 byte block. So API places as much records
as they fit into this blocks and sends reply back whith a flag, saying, that
there is more data. In this case the calling program must make additional
calls to this API, until it gets the last data.

I had no special ILE-C or AS/400 experience when I started, so the largest
problem for me was how to keep information inside my API on where to get
next data between the calls. With a little help from the community I found,
that QTRMP suits exactly.
So when first called API generates a reply and writes it into the PF,
created in QTEMP. Then it starts to place records to buffer one by one,
deleting a record, once it is placed. So it is actually a loop of _Rreadf
and _Rdelete.
So making CLRPFM once is not an option for me. Actually I can do that, but
it will not ever do anything usefull...
There where 2 other advises - to use stat() or access(), but I could not
find them in the manual :-((

Regards,
Eugene.



>Eugene,
>
>The first thing to do would be keep the job active and let it handle
>all requests.
>
>Regards to clearing/creating your QTEMP file, always chose the option
>that generates the fewest exceptions.  So if some step is called
>multiple times such that most of the time the QTEMP file exists, but
>the first time it does not, then I would use the following code:
>CLRPFM QTEMP/MYTEMP
>MONMSG CPF3142 DO(CRTDUPOBJ xxxx)  /* File Not Found */
>
>This way, most of the time it is just the clrpfm that is executed.
>
>Regarding deleting all the records after the work unit and then doing
>CLRPFM, that is an extra step.

>I can't say for certain, but I would expect the single CLRPFM to be
>faster than deleteing individual records (especially if access paths
>are involved).  So I would NOT delete the records as you send them
>back, and just do the CLRPFM.  This has the added benefit that by
>opening in read-only mode, you allow better blocking to take place.





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 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 here. If you have questions about this, please contact [javascript protected email address].