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)|
+----------------------------------------------------+
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
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.
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.
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.
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.
| Copyright © 2011 CA. All rights reserved. | Email CA Technologies about this topic |