5.16 SAS Configuration Options Used by CA MICS


Your sharedprefix.MICS.PARMS library contains SAS
configuration members that are used to set necessary and
optimal SAS system options for the operation of CA MICS in
several scenarios.

The following are the configuration members.  A brief
description for each member is also given.

  ICFBATCH - options for MICF batch execution
  ICFDMS   - options for MSAS
  MABATCH  - options for batch PROCS except MICSRPTS
  MATSO    - options for MICF foreground executions, and MICF
             Production and User Reporting job streams
  MQRBATCH - options for the Q&R Mainframe Server

Since SAS system options vary depending on the version of SAS
being used, CA MICS supplies copies of these members that are
version specific.  The names of these version-specific
members are as follows:

  ICFBTCHx
  ICFDMSx
  MABATCHx
  MATSOx
  MQRBTCHx

where x is 7 for SAS version 8, or 9 for SAS version 9.

During the construction of a new CA MICS complex, the
appropriate version-specific members are copied to the
configuration members. For example, if you are using SAS
version 9, the PARMS member MABATCH9 is copied to member
MABATCH.

Comments are provided in these members to indicate which
options are required for CA MICS operation and which may be
changed.  Note that CA MICS has been certified to run only
with the distributed options and mandatory settings.

To add or change SAS configuration options, modifications
should be made to the version-specific members so that the
modifications will not be backed out by future maintenance.
Then a run of the job in sharedprefix.MICS.CNTL(MICSLS1) will
copy the correct version-specific members to the
configuration members.

User modifications should be documented in the same manner as
your other local modifications in
sharedprefix.MICS.LOCALMOD.CNTL.  This will serve as a record
of your local modifications to the delivered CA MICS values.

The following steps should be executed when user
modifications are done to one of these members:

__  1. Make your change to the version-specific member
       that corresponds to the version of SAS being used
       at your installation.

___ 2. Make the same change to any higher SAS version
       version-specific members that may be present in
       sharedprefix.MICS.PARMS.

___ 3. Edit and submit the job contained in
       sharedprefix.MICS.CNTL(MICSLS1) to activate the
       appropriate members for the SAS version you are using.

       +----------------------------------------------------+
       | Reference(s): Section 3.2.5 (Adapt CA MICS Complex)|
       +----------------------------------------------------+

5.17 Converting CA MICS Libraries to PDSE Format


This section contains information related to converting CA
MICS libraries to PDSE format, and is presented in the
following topics:


     5.17.1 - Overview of PDSEs
     5.17.2 - Limitations of using PDSEs with CA MICS
     5.17.3 - Considerations of using PDSEs with CA MICS
     5.17.4 - CA MICS Support of PDSEs

5.17.1 Overview of PDSEs


Historically, CA MICS has been installed as a collection of
primarily partitioned data sets along with several SAS data
libraries, and a few physical sequential data sets.

We recognize the benefits of migrating from partitioned data
sets to partition data set extended format data sets.
Following are the advantages of using PDSE data libraries:

o  A PDSE can automatically reuse space within the data set
   without having to periodically run a utility to reorganize
   it.  It can use noncontiguous space, reclaimed from deleted
   members.

o  The size of a PDSE directory is flexible and expands to
   fit the members stored in it.

o  The system reclaims space automatically whenever a member
   is deleted or replaces, and returns it to the pool of
   space available for allocation to other members of the
   same PDSE.  The space is reused without having to do an
   IEBCOPY compress.

o  PDSE members can be shared.  This allows modification of
   separate members of the same PDSE, at the same time.

o  Reduced directory search time.  The PDSE directory, which
   is indexed, is searched using that index.

o  Allows creation of multiple members simultaneously.

o  PDSEs can reside in up to 123 extents.

o  When written to DASD, logical records are extracted from
   the user's blocks and reblocked.

5.17.2 Limitations of using PDSEs with CA MICS


LOAD Modules:

As of this writing, the CA MICS LOAD library
(sharedprefix.MICS.LOAD) cannot be converted to a PDSE.  The
CA MICS installation and PSP refresh processes utilize the
STOW macro for storing the load members into a PDS.  This
macro can no longer be used to store program objects.

SAS 8.2:

SAS 8.2 has several known issues related to PROC PDS and PDSE
data sets, as well as non-SMS managed PDSE data sets and
simultaneous update.  As SAS no longer actively develops new
solutions for version 8.2, we recommend that you only convert
your CA MICS installation (complex) to PDSE format if you are
at SAS 9.1.3 or higher.

5.17.3 Considerations of using PDSEs with CA MICS


Each member of a PDSE library must reside in its own 4K block
while it physically resides on DASD.  For libraries with many
small members, such as the CA MICS data dictionary and
documentation libraries, (sharedprefix.MICS.DIC.TEXT and
sharedprefix.MICS.DOC.TEXT, respectively), this results in a
larger space requirement for these libraries.  Our own
in-house test results reflected a 50% increase in the space
used by the dictionary library, and a 26% space increase in
the documentation library.

Most other libraries also increased in size.  We recommend
when reallocating/copying a CA MICS PDS to a PDSE library,
allocating 20% more space.  Especially since, while it is
possible to expand a PDSE data set up to 123 extents, to
achieve the best performance you should avoid fragmenting
your data sets whenever possible.

When allocating a PDSE library, directory blocks are not
required when using ISPF to allocate the PDSE library.  If
you are going to use JCL to allocate the new PDSE library,
you will need to specify the number of directory blocks or
the job will fail with a JCL error.  The directory block
specification is only used should the PDSE library be
converted back to a PDS library.

5.17.4 CA MICS Support of PDSEs


With the exclusion of the LOAD library as discussed earlier,
existing CA MICS complex and unit level partitioned data sets
(PDSes) can be MANUALLY converted to partition data
set-extended data sets (PDSEs).

The CA MICS installation jobs as well as the Optional Product
Installation jobs have been modified to allocate the
installation (complex) data sets as either partitioned or
partitioned-extended data sets by the use of a user specified
parameter.  The default is still PDS format.

The PSYyymmL job has been modified such that it recognizes a
PDSE data set.  Currently during the maintenance unload job,
the PSP libraries generally get deleted and reallocated for
one or both of the following two reasons:

o  Insufficient directory blocks on the PDS to support the
   additional unloaded members

o  Insufficient space allocated to the PDS to support the
   additional unloaded members

If during the maintenance unload job a library is identified
as a PDSE, the directory blocks will no longer be
interrogated to determine whether or not to delete and
reallocate the PSP library.  Only insufficient space will
result in deletion and allocation of a new PSP data set.

Any data sets already converted to PDSE format will be
reallocated in the same format.  In addition, the PSP refresh
processes have all been enhanced to allow specification of
the data set type.  Any libraries that get reallocated will
use this parameter to determine data set format (PDS or
PDSE).   The default is PDS format.