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.