The parameter file contains the initialization data for the subsystem GET-TIME, which provides the user with information on the standardized world time and time offsets via the system function GTIME. The operating system also requires this information.
For information on initializing and administering the system time, see chapter "System time administration".
Systems support specifies the relationship between the system time (local time) and the universal world time UTC by means of different parameters. These give both the system and the user of the GET-TIME subsystem access to a local time and a clear time reference system (UTC) which is available across system boundaries.
Without this data (from the parameter file or interactively via the console), system initialization cannot be performed.
Except for an automatic restart or guest system operation, the SVP clock must contain the correct local time (system time) for system initialization.
The keyword for setting the relationship between system time and universal world time in the parameter file is GTIME.
The maximum number of permissible parameter records is 256.
Format of the parameter record for system time control
Format | Meaning |
[NEXTZONE] | Start of a new GTIME parameter block. |
ZONE = +hh:mm / -hh:mm | Time zone |
DIFF = h:mm | Magnitude of time jump (difference) |
SEASON = S / W | Summer/winter time prior to the first time change |
| EPOCH = 00 / nn | Epoch for the TODR (2 hexadecimal characters). EPOCH=00 specifies the default epoch from 1900 to 2042. |
CHDATE = yyyy-mm-dd/hh:mm | Time reset point 1 |
| SINGLE | No future changeover dates (single season) |
However, changes to time reset points by means of commands must be entered manually in the parameter file if they are to apply in the next session.
NEXTZONE
This separates the GTIME parameters of different time zones from one another. This means that the data for more than one time zone may be included in the GTIME parameter file. This operand may be omitted if the parameter file contains data for only one time zone.
ZONE = -/+hh:mm
Time zone in hours and minutes.
This value describes the local, legal time zone in comparison to Greenwich Mean Time or UTC (Universal Time Coordinate).
Range: -12:00 <= hh:mm <= +11:59
For example, central European time is one hour ahead of UTC; the value to be specified is thus +01:00.
The value of ZONE must be specified in the parameter file.
DIFF = h:mm
Magnitude of the time jump between summer and winter time.
Range: 0:00 <= h:mm <= 9:59
The value of DIFF must be specified in the parameter file.
If DIFF is not 0:00, the SEASON operand and at least one CHDATE must be specified.
SEASON = S / W
Specifies whether Summer or Winter time was applied before the first reset. (“winter time” is taken to be the actual standard time: “daylight saving time” which deviates from the standard time is taken to be “summer time”.)
This value must be specified for internal time calculations if a time reset is declared with the CHDATE operands. The system function GTIME must determine the valid time from this value, even after several resets.
This value is not evaluated by the system function CTIME. Since other system functions (e.g. JMS, DMS) use CTIME internally, the notes on CTIME and SEASON which can be found in the description of the CHDATE operand should be taken into account.
EPOCH = 00 / xx
Specifies the epoch for the TODR (2 hexadecimal characters).
EPOCH=00 specifies the default epoch from 1900-01-01 to 2042-09-17.
A prerequisite for the use of a changed TODR epoch is that time stamps are no longer used which were previously obtained with a different epoch designation and stored by an application and which lie outside the range that can be displayed with the new TODR epoch. Such stored timestamps would be misinterpreted with the changed TODR epoch. This must be checked by system or application support before changing the TODR epoch.
"Old" timestamps can be compared with "new" timestamps after conversion to the TODX format, see section "Conversion of TODR timestamps to TODX timestamps" in "TODR epoch". Timestamps in TODX format can always be compared because TODX values are monotonically ascending in the period from 1900 to 4317. However, such a conversion requires that it is known with which epoch designation the "old" timestamps have been created.
CHDATE = yyyy-mm-dd/hh:mm
Declaration of time reset points (1..125). The first data must begin with 1900 and the following dates must be without gaps and in ascending chronological order (see the example on the next page).
Format and range of the date:
yyyy: year (1900 <= yyyy < 2042)
mm: month (1 <= mm <= 12 )
dd: day of month (1 <= dd <= 31 )
hh: hour (0 <= hh <= 23)
mm: minute (0 <= mm <= 59 )
The date details are used by the system at startup time to determine whether summer or winter time currently applies, and hence to determine the difference between local time and universal time, UTC. In this way the parameter file can be used over a number of time resets.
The clock resetting points are also required for the CTIME function; among other things, this converts time specifications from local time to UTC. In interpreting local time stamps, CTIME always assumes that winter time is in effect from 1900-01-01/00:00 up to the first CHDATE, even if, for example, the first CHDATE is 1994-09-25/03:00 and SEASON=S has been specified. From the point of view of the user, time stamps prior to the first CHDATE would then be wrongly interpreted as winter time stamps.
In order to minimize the impact of this problem, it is advisable to ensure that the list is complete with respect to past reset time points. To ensure the CTIME interface functions correctly, it is best to enter 1900-01-01/00:00 as the earliest date, with SEASON=S. The second CHDATE must then interpret a changeover from winter time to summer time. The system can then determine, for any earlier time which is specified, whether it is to be interpreted as summer or winter time.
The difference between two time reset points must be in the 4 to 8 month range (exception: the difference between CHDATE 1900-01-01/00:00 and the second CHDATE may be any size).
SINGLE
Specifies that there will be no summer/winter time changeover in future. This keyword should be specified immediately after the last and final changeover date (CHDATE) for the region. This feature has been introduced to future-proof BS2000 from a possible single season time adoption in certain regions. Omitting this keyword will lead to warning a message (ETMGT18) in the console when future changeover dates are missing.
Incorrect GTIME parameters will invalidate the relationship between system time and universal time (UTC), and therefore have fatal consequences such as an incorrect setting of the SVP clock!
Time changes can be made without interruption,i.e. the system is operated continuously throughout a change in time now that the TODR no longer has to contain the exact local time. The local time is determined from the contents of the TODR and a correction value (see chapter "System time administration").
The centrally supplied parameter file contains GTIME parameters for several zones. In order to select the parameters for the correct zone, the difference from the UTC for the current time zone should be set on the SVP on the SUs /390. On SUs x86 the time zone is set in the carrier system. On all servers the time zone is determined from the SVP time (STORE REAL CLOCK) (see chapter "System time administration").
If the time zone cannot be determined from the SVP time (error), the entry in the startup disk’s SVL is used to select the correct parameters. If there is no valid entry there either and more than one time zone is contained in the parameter records, the operator is requested to specify a zone with the messages ETMGT30 and ETMGT31. Alternatively the operator can terminate system initialization.
If the time zone cannot be determined using either the SVP time or the startup disk’s SVL but the parameter file contains precisely one time zone, this is taken as the time zone which is to be set.
When a time zone is determined by the SVP time or the SVL but there is no suitable parameter record for it, messages ETMGT35 and ETMGT36 ask the operator about the time zone which is to be set. Alternatively the operator can terminate system initialization.
In all cases in which system initialization is continued, the time zone which is detected or accepted is stored in the startup disk’s SVL.
Extract from the parameter file
/BS2000 PARAMS : /BEGIN GTIME ZONE=+01:00 1. DIFF=1:00 2. SEASON=S 3. EPOCH=00 4. CHDATE=1900-01-01/00:00 5. CHDATE=1980-04-06/02:00 CHDATE=1980-09-28/03:00 CHDATE=1981-03-29/02:00 : CHDATE=2013-03-21/02:00 6. CHDATE=2013-10-27/03:00 CHDATE=2014-03-30/02:00 CHDATE=2014-10-26/03:00 CHDATE=2015-03-29/02:00 CHDATE=2015-10-25/03:00 CHDATE=2016-03-27/02:00 CHDATE=2016-10-30/03:00 : /EOF : /END-PARAMS
Central Europe is specified as the time zone.
The difference of one hour denotes the magnitude of the jump to be made on a reset between summer and winter time.
It is essential to set summer time prior to the pseudo-CHDATE.
- The default epoch from 1900-01-01 to 2042-09-17 applies to the TODR.
- Pseudo CHDATE: as a result, winter time prevails up to the first actual CHDATE. This complies with the CTIME philosophy which assumes that winter time prevailed from 1900 to the first CHDATE entered.
Future reset dates are entered.