Why does FASTCOPY load a new PDS/E in multiple extents.

book

Article ID: 20074

calendar_today

Updated On:

Products

CA Endevor Software Change Manager (SCM) CA Endevor Software Change Manager - Natural Integration (SCM) CA Endevor Software Change Manager - ECLIPSE Plugin (SCM) CA Endevor Software Change Manager - Enterprise Workbench (SCM) CA PDSMAN

Issue/Introduction

Description:

When FASTCOPY loads a new PDSE, it is allocated in multiple extents, unless the file is a NON-SMS file without RLSE coded. This issue even occurs with CONTIG coded.

The same allocation parameters when used with IBM's IEBCOPY creates a PDSE in a single extent.

Solution:

FastCopy processing may cause a new PDSE to use multiple extents under the following conditions:

  1. PDSMAN FastCopy is active
  2. The output PDSE DD is specified within a step invoking IEBCOPY and

    1. Specifies DISP=NEW

  3. Specifies space release, by using either

    1. A MGMTCLAS defined with IMMED or COND release

  4. A SPACE= parameter with ,RLSE.

Before the COPY (or MOVE) operation, FastCopy does an OPEN for Output followed by a CLOSE to force the VTOC to be updated with DCB information.

This CLOSE causes space to be released before the COPY operation which means the new PDSE may start with a small primary allocation and require secondary extents.

There are a couple of circumventions:

  1. Allocate the NEW PDSE in a previous step which does not do an OPEN (for example, using IEFBR14).
    Then, use a refer back to allocate the PDSE in the IEBCOPY step.
    The PDSE will no longer be a new library and the space release performed during CLOSE does not occur.

  2. Do not specify RLSE or a Management Class with Release during Closedefined.

Environment

Release: PDSMA100200-7.6-PDSMAN-PDS Library Management-ONE COMPONENT
Component: