Is CPYTOIMPF to qtemp faster than to other library?

Question

I am a programmer working on IBM AS400 V5R4. I create 2 CL programs, both of which use CPYTOIMPF to format a list of AS400 PFs to character delimited files. The difference between them is: one formats files to qtemp(PGM A), while the other one formats files to a library other than qtemp(PGM B).

I called the 2 program separately to format about 90 files, with total about 8 million records. Both of the programs consumed more than 1300s CPU time, while PGM A used about 5% less CPU time than PGM B. I have tryied several times and the result is similar.

May I know why CPYTOIMPF to qtemp is faster than copy to other library, though just a little difference?

Answer 1

If you don't get an answer here. Try posting it to MIDRANGE-L. There is a large community of IBM i (or AS/400) experts there. Someone could probably answer it there.

Answer 2

Interesting experiment.

Are you using the SIZE atttribute on the CRTPF command when you create the output file in QTEMP or the other library? I'd suspect extending the file is faster in QTEMP than it is in the other library. Setting the number of records in the SIZE attribute to the number of records on the input file might remove the difference in performance as the files no longer have to be extended.

Answer 3

QTEMP is always in the library list of a iSeries Job (with a normal configured iSeries). Did you do your - interesting! - experiment with a library that is in the library list too?

I don't know if syslibl, curlibl of usrlibl may be of any importance.

Answer 4

To Mike Wills: Thanks for ur advice! I will try ur advice.

To Paul Morgan: Both TOFILE has the same size(*nomax). So that during the process it did not extend the files. Thanks for ur advice!

To robertnl: Yes, both qtemp(of course) and the other testing library are in library list. Thanks for advising!

Answer 5

QTEMP and it's contents are not required to survive beyond the life of the job, so it may well be optimized to not commit things to disk or to do so less often, and it may not need to create file system transactions for object changes either, since if the system goes down uncontrolled QTEMP is simply blown away with the job.

Also, QTEMP does not need to worry about security resolution and object controls since it is private to the job.

These things, and similar, can make accessing QTEMP require less work than a normal persistent library.