Why is FUP LOAD faster than FUP COPY?

[Shiva]

Of course it should be because of some system procedure call logic, but what exactly is the reason?

[Keith Dick]

Shiva wrote:
> Of course it should be because of some system procedure call logic, but what exactly is the reason?

FUP COPY writes one record at a time like a normal user program would.

FUP LOAD understands the structure of Enscribe files, builds the data blocks, index blocks, and bitmap blocks in memory and writes them to the file using multi-block unstructured writes.

So LOAD avoids a message per record and writes many blocks in each I/O. It also avoids some minor overhead involved in record-level access to the data, but the reduced number of messages and the larger data transfers are the main reasons for its much better performance.

[Shiva]

Great! That explains it. Thanks, Keith! :)

[wbreidbach]

Am Dienstag, 26. Mai 2015 19:57:30 UTC+2 schrieb Shiva:
> Great! That explains it. Thanks, Keith! :)

Just 2 things: If you have alternate key files, copy maintains these files, load needs a separate step to fill the alternate key files.
In addition you should be aware that FUP is not able to process an audited file as target!

[wbreidbach]

Oops: I forgot to mention: FUP COPY supports parameters LOAD does not support, just a few days ago I had this problem and the missing parameter was COUNT (J06.13). You can COPY a fixed number of records but you cannot LOAD a fixed number of records.
another problem might be that the target file is marked as CORRUPT during the LOAD, a monitoring tool might produce some messages.
But if you are able to use LOAD it is significantly faster than COPY.

[Shiva]

Yes, I've noticed the things that you have mentioned - Wolfgang. Thanks a lot! :)