Miscellaneous data items describing your database unit are
specified to CA MICS via the parameters in
prefix.MICS.PARMS(SITE). The SITE designation means that the
parameters here are specific to the database unit associated
with the "prefix" rather than to all CA MICS databases that
are installed at your site. The parameters specified include
headers for CA MICS reports, special calendar definitions,
the start of the week, and an option to control the
activation of the YEARS timespan.
A subset of these parameters (YEARS TIMESPAN, WEEKSTART, and
13MONTHYEAR) default to the values you specified in
sharedprefix.MICS.PARMS(CPLXDEF). You have the option to use
the complex-level default, or to override the complex-level
parameter specification to define unique options for this
unit database. In either case, the parameter specification
(either explicit or default) is implemented by running the
BASPGEN job in this unit database. See Section 2.3.1.8 for
more information on specifying this parameter at the complex
level.
Figure 2-12 is a worksheet to help you collect the data
needed to complete prefix.MICS.PARMS(SITE). As with most
CA MICS PARMS members, the format of statements is free-form
but positional. Comments are coded by beginning the
statement with an asterisk (*). Blank statements are
allowed.
We recommend that you modify the sample SITE member supplied
with the distributed MICS.PARMS library rather than code it
from scratch. Starting with an existing, correct
specification can prevent syntax errors. A sample SITE
member is shown below:
*
* SITE PARAMETER DEFINITIONS
*
NAME 'C A'
YEARS TIMESPAN INACTIVE
WEEKS TIMESPAN INACTIVE
WEEKSTART SUN
13MONTHYEAR NO
CKPTCNT 100
*CKPTLIMIT 180
AUDITCYC 10
The following items are specified once for each database unit
(the statement name is given in parenthesis):
Installation Name (NAME):
The 1- to 66-character name used to identify the site.
This statement is required. Note that all percent signs
(%) in the name will be translated to blanks to avoid
conflicts with SAS macro definition conventions.
YEARS TIMESPAN Option (YEARS TIMESPAN):
The files in the YEARS timespan are updated as part of
the MONTHLY processing job if the YEARS timespan is
active at your site.
The default unit database parameters are distributed as:
YEARS TIMESPAN INACTIVE
This saves both DASD space and processing time by not
updating the YEARS files.
Delete this parameter to use the complex-level default
from sharedprefix.MICS.PARMS(CPLXDEF).
If you decide that the YEARS timespan should be used to
update the YEARS file, specify ACTIVE for this option.
Note that CA MICS still maintains a prefix.MICS.YEARS
data set when the YEARS timespan is inactive. The files
in this data set contain zero SAS observations and are
not updated during MONTHLY processing.
If the YEARS timespan is changed from ACTIVE to INACTIVE
after data is processed by CA MICS, any SAS observations
in the year-to-date files are dropped during the MONTHLY
process following the parameter change. Data in files
other than the year-to-date files are not affected by
changing the parameter to INACTIVE from ACTIVE.
WEEKS TIMESPAN Option (WEEKS TIMESPAN):
The files in the WEEKS timespan are updated as part of
the DAILY processing job if the WEEKS timespan is
active at your site.
By default, the unit database parameters are distributed
without the WEEKS TIMESPAN statement. Insert this
parameter to override the complex-level default from
sharedprefix.MICS.PARMS(CPLXDEF) to deactivate the WEEKS
timespan.
Note that CA MICS still maintains a prefix.MICS.WEEKS
data set when the WEEKS timespan is inactive. The files
in this data set contain zero SAS observations and are
not updated during DAILY processing.
If the WEEKS timespan is changed from ACTIVE to INACTIVE
after data is processed by CA MICS, any SAS observations
in the week-to-date files are dropped during the DAILY
process following the parameter change. Data in files
other than the week-to-date files are not affected by
changing the parameter to INACTIVE from ACTIVE.
WEEKSTART Option (WEEKSTART):
This option specifies the first day of the week. This
value can be changed from SUN to one of the following:
MON TUE WED THU FRI SAT. Only use the WEEKSTART option
if you intend to override the complex-level default
specified in sharedprefix.MICS.PARMS(CPLXDEF). WEEKSTART
is used to compute the value of WEEK from a given date.
Before you specify this parameter, first
consider the impact of having different week definitions
in different unit databases. In general, you should
define WEEKSTART for your site once in
sharedprefix.MICS.PARMS(CPLXDEF) in order to have a
consistent definition of WEEK across all units. Then,
specify WEEKSTART in prefix.MICS.PARMS(SITE) only for
those unit databases that require a unique week
definition to address specific requirements; such as,
those resulting from a unit database supporting a remote
data center, or from a unique isolated workload.
Thirteen Month Fiscal Year Option (13MONTHYEAR):
The standard definitions used by CA MICS for DAY, WEEK,
MONTH, and YEAR are based on a calendar year beginning
January 1 and having 12 months, with the number of days
per month varying from 28 to 31 depending on the month.
Data is summarized in the CA MICS database according to
these standard definitions. If your organization
operates on the standard 12-month year and follows the
common North American understanding of the first week of
a new year, DO NOT code this option.
The default for this option is NO. Only use this option
if you intend to override the default. Before doing so,
we strongly recommend that you review Section 4.7.2 in
the System Modification Guide for information about
adjusting algorithms and year-end boundaries.
Note: If you defined your special fiscal calendar in
sharedprefix.MICS.PARMS(CPLXDEF), then you can
omit the 13MONTHYEAR parameter for this unit
database. The complex-level default will be
applied. However, if you want this unit database
to operate under the standard 12 month calendar
AND you defined a special fiscal calendar in
CPLXDEF, specify the following:
13MONTHYEAR NO
to force this unit database to use the standard 12
month Gregorian calendar.
13MONTHYEAR has been provided to enable non-standard
calendar-related options. In particular, it enables
CA MICS to summarize and store data for an organization
that operates on a 13-month fiscal year. It also allows
a year to have up to 380 days.
Note: The CA MICS Accounting and Chargeback component
includes facilities for defining a unique
accounting calendar separate from the global
CA MICS calendar definitions. This capability is
designed to help you meet your requirements for
chargeback and accounting relative to your
company's fiscal calendar while continuing to use
the standard 12-month calendar for the majority of
your CA MICS information. See the CA MICS
Accounting and Chargeback guides for more
information before altering the global CA MICS
calendar.
Before specifying this parameter, you should first
consider the impact of having different calendar
definitions in different unit databases. In general, you
should define your fiscal calendar once in
sharedprefix.MICS.PARMS(CPLXDEF) in order to have a
consistent calendar definition across all units. Then,
specify the 13MONTHYEAR parameter in
prefix.MICS.PARMS(SITE) only for those unit databases
that require a unique fiscal calendar to address specific
requirements; such as, those resulting from a unit
database supporting a remote data center, or from a
unique isolated workload.
This statement can be formatted in any of the following
ways:
13MONTHYEAR NO
13MONTHYEAR NO #DWMY=memname
13MONTHYEAR YES ddmonyy ddmonyy ... ddmonyy
13MONTHYEAR YES #DWMY=memname ddmonyy ddmonyy ...
Note: Only one 13MONTHYEAR control statement is allowed.
Subsequent 13MONTHYEAR statements replace prior
13MONTHYEAR statements.
where:
13MONTHYEAR is the option keyword.
NO is specified if you use a standard 12-month year
beginning on January 1 and ending on December 31. The
default value shipped with CA MICS is NO. It causes the
SOURCE member #DWMY12 to be used.
YES is specified only if your organization operates on a
13-month year.
memname is a member that contains date macros. It MUST
begin with the characters #DWMY. For example: #DWMYUSR.
The ddmonyy keyword defines the year's starting date.
Valid values are:
dd 01 to 31 to specify a day of the month
mon JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC
to specify the month
yy two digits to specify the year
Dates must be in ascending order and a year cannot
contain more than 380 days. You cannot code two dates
using the same year value (that is, 01JAN12 and 28DEC12).
You can specify a maximum of eight dates (that is, the
13MONTHYEAR statement can define no more than 8 years).
Here is an example:
13MONTHYEAR YES 01OCT11 30SEP12
is interpreted as fiscal year 2011, which begins on
October 1, 2011 and ends on September 29, 2012. Fiscal
year 2012 begins on September 30, 2012 and ends on
September 29, 2013.
#DWMY=memname allows you to change the definition of
date-related SAS macros and affects the entire CA MICS
system. Sharedprefix.MICS.SOURCE(memname) contains these
macros that define the day, week, month, year, year start
date, previous week (used to select data for weekly
reports), and the number of months per year. Use
the supplied member #DWMY12 (containing macros
corresponding to the data dictionary definitions), or
#DWMY13 (supporting a 13 month calendar), or #DWMYWK1
(supporting a 12 month calendar with the first week of a
year being the first week with 4 or more days in that
year) as guides for constructing new members. For
example, when #DWMY12 is modified directly, you must also
make the same changes to $DWMY12. The #DWMY members
contain macro definitions written in SAS MACRO
statements, while the $DWMY members contain the
corresponding macros written in SAS MACRO language.
If this option is used to change the definition of one or
more macros, you can retain the other macro definitions
by starting your #DWMY member with a %INCLUDE statement
to include one of the standard #DWMY members, followed by
a redefinition of the macros you want to change.
Note: CA MICS abends if data is encountered for a year
that does not have a defined starting date.
When you activate the Thirteen Month Fiscal Year Option,
you change the definitions of the following CA MICS data
elements:
YEAR - the fiscal year minus 1900 is set according to the
first calendar year of the fiscal year (for
example, if the start of your fiscal year is
October 1, 2011, the data element YEAR equals 111
(2011-1900) for the fiscal year October 1, 2011 to
September 30, 2012).
If your fiscal year value is different from the calendar
year of the date that starts your fiscal year, edit the
_YEAR macro of sharedprefix.MICS.SOURCE(#DWMYxx) and the
YEAR macro of sharedprefix.MICS.SOURCE($DWMYxx) to
reflect the correct year value. The standard macro
computation subtracts 1900 from the calendar year of the
fiscal year start date to produce the YEAR value. The
1900 value is the one you need to edit for both the _YEAR
and YEAR macros. For example, if your fiscal year is one
greater than the calendar year, change the macros as
follows:
default macro shipped with CA MICS in #DWMYxx:
MACRO _YEAR _SETYRST YEAR=YEAR(YRSTART)-1900; %
customized macro for your site:
MACRO _YEAR _SETYRST YEAR=YEAR(YRSTART)-1899; %
default macro shipped with CA MICS in $DWMYxx:
%MACRO YEAR;
%SETYRST;
YEAR=YEAR(YRSTART)-1900;
%MEND YEAR;
customized macro for your site:
%MACRO YEAR;
%SETYRST;
YEAR=YEAR(YRSTART)-1899;
%MEND YEAR;
MONTH - the month of the year ranges from 01 to 13 and is
based on 28-day time periods. For example, if
your fiscal year begins on October 1, the last
day of MONTH01 is October 28 and the first day of
MONTH02 is October 29.
WEEK - the week of the year ranges from 01 to 54 and is
based on the first day of the fiscal year you
specify. By default, CA MICS weeks always end on
Saturday. For example, if your fiscal year
begins on Wednesday, October 1, WEEK01 spans
Wednesday, October 1 through Saturday, October 4.
WEEK 02 spans Sunday, October 5 through Saturday,
October 11.
The WEEKSTART option defined earlier in this section
enables you to change the Sunday default that is shipped
with CA MICS.
DAY - the day of the month ranges from 01 to 28, with
the day determined by its position relative to
the first day of the 28-day month. The exception
to the 28-days-per-month rule comes in MONTH13,
when DAY is greater than 28, if the year has more
than 364 days. For example, if the fiscal year
begins on October 1, the last day of MONTH01 is
October 28. October 28's DAY value is 28.
October 29 has a MONTH value of 02 and a DAY
value of 01.
Consult the data dictionary appendixes in your DIA guides for
more information on these data elements, and the CA MICS
System Modification Guide, Section 4.7, for more information
on calendar derivation.
Changing the values of the DAY, WEEK, MONTH, and YEAR data
elements to match the Thirteen Month Fiscal Year Option
changes the summarization of the DAYS, WEEKS, MONTHS, and
YEARS timespans in the CA MICS database.
Use of the Thirteen Month Fiscal Year Option also affects
operational and scheduling processes due to the new
definitions of the DAY, WEEK, MONTH, and YEAR data elements.
For example, monthly jobs are scheduled to run based on a
28-day month instead of on a standard month (for example, a
month that might end on the 30th).
CA MICS uses MNTHFMT, a SAS format, to provide the full name
of a month from a number (for example, December from 12).
Modify sharedprefix.MICS.SOURCE(MNTHFMT) if you want to name
the 13th month. The MNTHFMT format is recreated every time
ALLPGEN or BASPGEN is run.
Checkpoint Size (CKPTCNT):
The CA MICS checkpoint (prefix.MICS.CHECKPT.DATA) is
critical to proper CA MICS operation and data validity.
By default, the checkpoint tracks up to 100 unique
system, subsystem, and product combinations. This
default is adequate for most sites and should NOT
be changed unless you encounter CA MICS user abend code
U410.
Note: There is NO complex-level default for the CKPTCNT
parameter. Increasing checkpoint size for one
unit database does NOT impact any other unit
databases, and there is no risk that a
complex-level change will result in unexpected
changes to checkpoint size.
If you have exceeded the current checkpoint entry limit,
you can increase the size of your checkpoint file up to a
maximum of 9999 entries. However, you should first
review your CA MICS configuration for alternatives that
will improve CA MICS performance while concurrently
resolving your checkpoint size constraint.
For example, if you frequently move systems or subsystems
from one LPAR to another, thereby changing the ORGSYSID
which causes additional entries to be inserted into the
checkpoint file, consider activating the
automated checkpoint clean up facility, which is
controlled by the CKPTLIMIT parameter in
prefix.MICS.PARMS(SITE). This keyword/option is
discussed in detail later in this section.
Checkpoint file size alone has negligible impact on
CA MICS daily update performance; however, a large
checkpoint file often indicates a heavily loaded unit
database and long daily update elapsed times. You can
improve daily job performance by splitting your database
into two or more database units so that you can perform
more of your daily CA MICS processing in parallel. The
side benefit of splitting your database is that each of
the database unit checkpoint files carries a subset of
the original checkpoint entries and thus does not need to
be as large as a single composite checkpoint.
Either of the database splitting techniques described
below can be used independently or in conjunction with
increasing checkpoint file size. Both can significantly
reduce the overall CA MICS update batch window.
o Split processing by product
The most common approach is to define a separate unit
for each CA MICS product or related group of products.
In this way, you can concurrently process data for
multiple products, reducing overall daily update time.
This approach is especially recommended for database
products such as CICS, IMS, IDMS, and DB2, and network
products such as SNT. These products are often
characterized by multiple system/subsystem
combinations and therefore require multiple checkpoint
entries for each system. Quite often, the raw input
data for these products (for example, a transaction
log tape) is isolated from the data processed by other
CA MICS products (for example, the system SMF log).
Likewise, you might choose to keep products like SMF
and RMF in a single unit database because of their
shared input data source, the system SMF log.
o Split processing by subsystem
Once you split CA MICS processing by product, you may
find that you can gain additional parallelism by
splitting the processing of multiple subsystems of a
single product.
For example, you might define a unit database for
selected groups of IMS or CICS processing regions,
possibly separating processing for major application
areas or departments. If you are processing data from
multiple remote locations, you might define a separate
unit for each location, letting you parallel SMF and
RMF processing for multiple locations.
If, after reviewing your CA MICS configuration, you
still need to increase checkpoint size, then you can do
so as described in section 5.14, Vertical Checkpoint
Expansion.
Automated Checkpoint Cleanup Option (CKPTLIMIT):
By default, the checkpoint tracks up to 100 unique
system, subsystem, and product combinations. The
Automated Checkpoint Cleanup Option allows you to set a
limit on how long out-of-date checkpoint time range
entries should be retained. Once this option is
activated, every execution of the DAYALL step will
compare the highest timestamps from the time range
records within the checkpoint file(s), to the retention
limit you specify in CKPTLIMIT, (number of days) and
remove any entries with an earlier high timestamp.
For example, if CKPTLIMIT is set to 120, and the
execution date of DAYALL is December 31, 2012, any
entries earlier than September 2, 2012 are removed.
Removed entries are written to the MICSLOG of the DAYALL
step.
This facility can help avoid U410 abends in the DAILY
and/or incremental update steps.
Note:
1) There is no default limit for this option. If
CKPTLIMIT is not specified, no automated cleanup
occurs.
2) This option applies to the database unit checkpoint
file as well as any incremental update checkpoint
files associated with this unit. All unit related
checkpoint files are processed in DAYALL.
Input cycles for Audit Archive (AUDITCYC):
This option provides control over the number of cycles
that are selected and written to the audit archive
within this unit.
The default for this option is 10. This option is most
useful if your site executes multiple AUDIT archive jobs
within a week, or if you keep fewer than 10 cycles and
execute the AUDIT archive job more than 10 days after the
start of the week. In these scenarios you could either be
writing redundant data, or missing cycles that are no
longer online and available at the time the AUDIT archive
job executes.
+--------------------------------------------------------------------------+ | INSTALLATION PREPARATION WORKSHEET: Site Characteristics Definition | | | | PARMS Library Member is SITE | | | | Reference Sections: 2.3.2.4 | +--------------------------------------------------------------------------+ | | | | | INSTALLATION NAME: | | NAME '__________________________________________________________________'| | | | YEARS TIMESPAN OPTION: | | YEARS TIMESPAN ________ (ACTIVE or INACTIVE) | | | | | | WEEKSTART OPTION: (default is SUN) | | WEEKSTART ________ (MON TUE WED THU FRI SAT) | | | | | | 13MONTHYEAR OPTION: (default is NO) | | 13MONTHYEAR NO #DWMY=________ | | YES ________ ________ ________ | | | | CKPTCNT OPTION: (default is 100) | | CKPTCNT ____ (100 - 9999) | | | | CKPTLIMIT OPTION: (default is no action) | | CKPTLIMIT ____ (1- 999) | | | | AUDITCYC OPTION: (default is 10) | | AUDITCYC __ (1 - 99) | | | | | +--------------------------------------------------------------------------+ | ....5...10...15...20...25...30...35...40...45...50...55...60...65...70.. | +--------------------------------------------------------------------------+
Figure 2-12. Site Characteristics Definition Worksheet
|
Copyright © 2014 CA.
All rights reserved.
|
|