4. Operation › 4.3 Operations Reference › 4.3.12 Special Processing Considerations › 4.3.12.3 Impact of Seasonal Time Changes on CA MICS
4.3.12.3 Impact of Seasonal Time Changes on CA MICS
All data sources that are processed by CA MICS are sensitive
to a time of day adjustment that usually occurs in the spring
and fall of the year. The United States calls this "Daylight
Saving" versus "Standard" time. Other countries have
different names, such as "Summer Time" in parts of Europe.
A time adjustment occurs twice a year: in the spring, clocks
are set ahead one hour, and in the fall they are set back one
hour. That is, one early morning in the spring, 2:00 a.m.
becomes 3:00 a.m., and hour 2 of that day is totally missing
from any system measurement. One early morning in the fall,
2:00 a.m. becomes 1:00 a.m., and hour 1 of that day occurs
two times. The change of time is usually accomplished in the
operating system by an IPL, or by dynamically changing the
system clock or SYSPLEX timer.
This can be graphically illustrated:
In the spring:
time changes here----------+
|
V
|--------|--------|--------|--------|------->
hour 23 hour 0 hour 1 hour 3 hour 4
In the fall:
time changes here----------+
|
V
|--------|--------|--------|--------|------->
hour 23 hour 0 hour 1 hour 1 hour 2
The way your installation handles these time changes can have
an effect on the input data supplied to CA MICS. The
problems associated with these time changes and the
consequences of actions that your installation might take are
described below.
NOTE: Neither the spring nor fall time change will have an
effect on your installation's input data if no jobs
are executing during the time change (for example, in
an installation that has no midnight shift). The
system is simply IPLed on Monday morning with the
correct time.
SPRING
The time change in the spring has a much smaller impact on
the CA MICS Database than the one that takes place in the
fall. The degree of impact is also dependent on the way your
installation handles the time change.
There are several points to keep in mind if the system is in
operation when the clock is advanced one hour. If batch jobs
are running, or if online sessions are active, advancing the
clock will result in elongated run times and response times.
If priority charging is in effect, the service objectives of
the installation might not be met. These events can affect
the chargeback system. CA MICS files, plots, graphs, and
reports will contain very little data for the 02:00 to 02:59
hour (that is, HOUR = 2) because very few ENDTS time stamps
will be recorded for that period. This may affect your
exception reporting.
Elongated job run times, response times, and their resultant
effects upon the chargeback system can be avoided by using
one of the following methods.
o Schedule preventive maintenance during the time change
period. This method requires the least amount of manual
intervention on the part of the installation.
o Shut down or quiesce the system at 01:59 standard time,
and then IPL the system at 03:00 daylight saving time
(elapsed down time: one minute). If the system is shut
down, one hour of input data will be missing from CA MICS.
If it remains active, then batch jobs and online sessions
will have their elapsed times extended by one hour. If
this method is used, the operations staff must be careful
to IPL the system at 03:00 daylight saving time.
Otherwise data may be produced for a nonexistent hour.
The above methods result in very little data for the 02:00 to
02:59 hour and may inconvenience your operations staff and
active online users; but installations that use SMF data for
accounting and chargeback purposes often choose one of these
two methods in order to preserve the validity of the
chargeback system.
Other alternatives include:
o Issue the SETCLOCK command from the OS operator console to
temporarily increase the Greenwich mean time (GMT) offset
by one hour; but be careful. Some CA MICS products
process data in which event time stamps are offset by the
GMT offset. These products are the CICS and SRL products,
but it is expected that more products will eventually be
affected. CA MICS only supports one definition of a GMT
offset per system or subsystem processed. This creates a
problem IF the GMT offset changes when the local time of
day changes. CICS and LOGREC data collected with the old
GMT offset must be processed by CA MICS, then the GMT
offset in the CICS or SRL OPTION statement changed, then
an ALLPGEN run--all before the new GMT offset data is
processed by CA MICS.
o Recognize that a problem may exist with the data and be
prepared to ignore the problem.
FALL
There are several difficulties that arise when the system is
in operation when the clock is turned back one hour.
If the system is allowed to run in the "second" hour 1 in the
fall, some unusual time stamp events occur. For example,
batch jobs may complete or print before they start or online
sessions may end before they begin. CA MICS treats such
obviously impossible input queue times as bad data and sets
the incalculable interval to a value of zero or a missing
value. Jobs, transactions, and system measurement intervals
that span these time changes may have incalculable values for
many data elements. These data elements may include (but are
not limited to) queue times, elapsed times, print times,
reader times, and DURATION. CPU times are rarely affected.
The CA MICS DETAIL file will contain twice as much data for
the 01:00 to 01:59 hour. Service objectives will be invalid
and certain times will be missing because they were negative.
In the summary files (such as DAYS and WEEKS), the hourly
summaries will contain twice the volume (for example,
DURATION = 2 hours). In addition, the zone summaries in the
MONTHS and YEARS files will contain an extra hour. Plots and
graphs will report inflated values for the 01:00 to 01:59
hour and lose their significance.
As mentioned earlier, the CICS and SRL products process data
in which event time stamps are offset by the GMT offset. In
addition, it is expected that other products will eventually
be affected. CA MICS supports only one definition of a GMT
offset per system or subsystem processed. If the local time
of day changes at the same time as the GMT offset, this
causes a problem. Before CA MICS processes the new GMT
offset data, you must: 1) have CA MICS process the CICS and
LOGREC data collected with the old GMT offset; 2) change the
GMT offset in the CICS or SRL OPTION statement; and 3) run an
ALLPGEN.
Some solutions include:
o Ignore the data for that time period. Reports would have
to be ignored or deleted. All users would have to be
warned that their reports were erroneous or notified that
the daily reports had been eliminated.
o Shut the system down at 01:59 daylight saving time, turn
the clock back and wait one hour; then IPL the system at
02:00 standard time. This method is rather drastic as it
loses an hour of processing time, but it may be justified
in those shops that cannot afford to have invalid data for
that period. Installations that use SMF data for
accounting and chargeback purposes often choose this
method in order to preserve the validity of the chargeback
system.
When using this method unless the operations staff is
EXTREMELY careful, the change of time can occur at an odd
point. For example, if the system is allowed to run until
02:15 and is then reset to 15 minutes after the new hour,
this can produce data with unusual overlaps.
o Apply GMT offset specifications to CA MICS coupled with
monitor stoppage at the time change point. This allows a
clean break at the time change point. If the SMF logs are
dumped at the time change, CA MICS can process data from
before the time change in one run and can process data
from after the time change in the next run. This will
cause data to be dropped, because data up to 02:00 would
have been processed by the first run. Data for the period
01:00 to 02:00 would also occur in the second run, and be
discarded due to the overlap of hour 1.
o Schedule hardware preventive maintenance over the time
change period. This is usually practical because the time
change is normally on a Sunday morning.
