BSTXCOPY performance

Products

• Endevor

Issue/Introduction

Endevor BSTXCOPY utility may show poor performance when used to copy a lot of members, for example, during migration of libraries.

Is there anything that could be done to improve that?

Cause

BSTXCOPY utility normally copies members record by record which is the slowest way to proceed.

The exception is when any of the libraries involved in the copy is a PDS/E program library. In this case, since IBM does not document the internal format of the library, BSTXCOPY uses the binder API (IEWBIND) to perform the copy. 

Resolution

IMPORTANT: This description applies only to BSTXCOPY executed as a regular copy utility OUTSIDE an endevor processor.

BSTXCOPY is documented to preserves endevor footprints which might be lost when using utilities like IEBCOPY.

However, it must be noted that the only footprints that could be lost with IEBCOPY are the 'load module' ones which, in the footprint displays and reports, show up with special CSECT name *LOADMOD. Any other footprints are preserved when using IEBCOPY.

Therefore, it is safe to use IEBCOPY for mass copies of libraries when

• Copying non-loadlib PDS or PDS/E libraries
• Copying loadlibs at the cost of possibly sacrificing the *LOADMOD footprints

The reason is that, for non-loadlibs, the footprint is stored in the 'user data' portion of the directory entry for each member. This is where, for example, ISPF statistics are stored. This data is always copied by IEBCOPY so using this utility will preserve these footprints in all cases.

For load modules, the footprints are stored in the form of 'user identification records' (IDRU) which are stored within the load module or program object.

The format of the IDRU records includes a CSECT name which relates each IDRU with its CSECT. This poses a problem with *LOADMOD footprints, which are stored in IDRU records with a null CSECT name.

Depending on unknown factors, IEBCOPY may omit copying these 'orphaned' IDRU records. When this happens, the copied load module loses its *LOADMOD footprint, although it keeps the footprints for each CSECT. If this loss can be afforded, then IEBCOPY may be used for these copies as well.

As noted above, IEBCOPY should not be used within a processor. If this is done, endevor does not detect the members created by the utility and therefore it cannot:

• Footprint IEBCOPY outputs
• Capture IEBCOPY outputs into component lists
• Capture package backout information for IEBCOPY outputs