2. PLANNING › 2.5 Special Considerations › 2.5.3 Shared DASD Considerations

2.5.3 Shared DASD Considerations

In nonshared DASD environments, VCC is normally allowed to
process all DASD volumes and catalogs.  It is run once a day
at a user-specified time to collect the data that will be
used to manage and account for DASD space.  In shared DASD
environments, however, VCC must be handled in a different way
to account for the following:

    o  Duplicate DASD volume serial numbers on each CPU that
       can be accessed by the same unit address, but are
       physically different devices (for example, the IPL
       volume for each CPU).  Furthermore, data set names may
       be duplicated within each volume such as SYS1.NUCLEUS,
       SYS1.LPALIB, or SYS1.MANA.

    o  Devices that are accessible from one CPU but not from
       another, when all other devices are shared.

    o  Catalogs that are accessible from one CPU but not from
       another, when all other devices are shared.

    o  VSAM data sets on nonshared volumes that are pointed
       to from catalogs on shared volumes, and vice versa.

    o  A master catalog from one CPU that is defined as a
       user catalog in another CPU's master catalog.

    o  Large online applications (such as IMS) that hold
       long-term device reserves that may interfere with VCC
       trying to process that device from another CPU.

These situations require a site with shared DASD to carefully
plan the methodology that will be used to collect DASD space
data.  We recommend that you use the following procedure:

    o  Create a separate VCC job stream for each CPU within
       the complex.  Each job should be tailored to collect
       data for those devices that are accessible only from
       that CPU (that is, nonshared DASD devices and
       catalogs).  VCC will add the SYSID to each volume and
       data set name that is collected, making each name
       unique.

    o  Create a VCC job stream to process only those DASD
       volumes and catalogs that reside on shared devices.
       Catalogs on nonshared devices should be excluded.  The
       CPU that is issuing the long-term reserves should be
       selected to run this VCC job.  The long-term reserve
       devices can be determined by examining RMF reports for
       the time period during which VCC will be run:

       -  the Direct Access Device Activity Report
          (the % DEV RESV field)

       -  the Reserve Activity Report (a Monitor II display)

      If the preferred CPU is down, another CPU in the
      complex can be used; however, the SYSID will be
      different for this collection run.  You may want to
      wait until the preferred CPU is fixed.

Failure to use EXCLUDEVOL techniques on "secondary" VCC runs
will result in duplicate data collection.  If duplicate data
set names or duplicate volume serial numbers are encountered,
the SYSID will make each data set name and volume serial
number unique.  Thus, shared DASD data sets that are
reprocessed again by another VCC will be treated as different
data sets and will be entered into the CA MICS Database
twice.  This would increase the size of the database and
would lead to overcharging for DASD space.  You can solve
this with careful use of EXCLUDEVOL lists.

VSAM data sets on shared volumes that are pointed to from
catalogs on nonshared volumes (and vice versa) cannot be
collected.  You must identify and handle these data sets
separately.

Make sure that master catalogs are not processed twice.  It
is common to have a master catalog from one CPU defined as a
user catalog in another CPU's master catalog.  These
connected master catalogs should be excluded.

VCC uses the VCCNTROL file to retain information between
executions. Information such as timestamps, and device and
data collection statistics are recorded in the VCCNTROL file.
This information is then used to adjust VCC processing
according to your particular site. Some of this information
is passed to the CA MICS Space Analyzer Option in order to
properly compute the DURATION, a key element for accounting.

It is vital that each VCC run associated with a given SYSID
DASD configuration be controlled by its own VCCNTROL file.
VCC uses both ENQUEUE and RESERVE processing to ensure data
integrity of the VCCNTROL file. The ENQUEUE or RESERVE of the
VCCNTROL file is of short duration.

For a shared DASD environment, the VCCNTROL file cannot be
shared between a VCC job to collect VSAM, non-VSAM, or DFHSM
data, and the job to collect file system data.

ADDITIONAL CONSIDERATIONS FOR FILE SYSTEMS:

For HFS scan jobs collecting information on file systems
which are shared between z/OS images, it is vital that each
HFS scan job executing on separate systems do not share the
same VCCNTROL file.

This situation requires a site with file systems shared
between two or more z/OS images to carefully plan the
methodology that is used to collect file systems data.  CA
recommends that you use the following procedure:

    o  Create a unique HFS scan job stream for each CPU
       within the complex.  Each job should be tailored to
       collect data for those file systems that are
       accessible only from that CPU.  HFS scan adds the
       SYSID to each volume and file system that is
       collected, making each name unique.

    o  When running HFS scan jobs in multiple images
       collecting information on file systems, care must be
       taken to exclude file systems that are shared among
       the multiple images to avoid duplicate data and over
       charging.  This can be accomplished by coding the
       EXCLUDEDSN parameter to exclude the shared file
       systems that are already scanned by another HFS scan
       job.

       For file systems, using EXCLUDEVOL to avoid scanning
       of shared file systems that reside on shared DASD
       would result in dropping File Systems that are local
       to the system and should be scanned.