Natural Configuration Tables

#### Search Results

Search

# Natural Configuration Tables

This document provides general information on the Natural configuration tables which are contained in the `NATCONFG` module.

This section covers the following topics:

- NATCONFG - Natural Configuration Tables

- General Overview of Macros Used by NATCONFG

- NTDVCE - Terminal-Device Specification Table

- NTMSG - Message Log Table Definitions

- NTSTAT - Definition of Natural Objects Linked to the Natural Nucleus

- NTCPAGE - Code Page Definitions

- Code Page Support

- Output Devices Supported

- Translation Tables

- Upper-/Lower-Case Translation

- CMULT Entry

- Output Translation

- Input Translation

- Code Translation of DBCS Data

- NTTZ - Time Zone Definitions

See also:

- Input/Output Devices Supported

## NATCONFG - Natural Configuration Tables

The `NATCONFG` module contains the Natural configuration tables.

| Warning: In general, the default specifications in `NATCONFG` need not and should not be modified. In particular, do not modify without prior consultation of Software AG support any of the tables marked with an asterisk (*) in the list below.

For most of the tables, there are corresponding macros in the Natural parameter module as well as dynamic profile parameters. If you need to modify a `NATCONFG` table, use the corresponding parameter-module macro, or dynamic profile parameter, to overwrite the table. (If you made the modifications in the `NATCONFG` tables themselves, you would have to modify and reassemble `NATCONFG` again with subsequent Natural releases.)

The `NATCONFG` module uses macros for the definition of the following Natural default configuration tables.

In addition, it uses the following tables:

- The default attention identifier table. It defines the physical terminal keys to Natural (*).

- Various other tables (*).

## General Overview of Macros Used by NATCONFG

The following table provides a general overview of the macros used by the `NATCONFG` module for the definition of the Natural default configuration tables:

Macro | Purpose
--- | ---
`NTDVCE` * | Table of terminal types. Used to specify the terminal driver to be used, see description below, for details. Important Do not modify an existing `NTDVCE` macro, rather create a new one.
`NTMSG` | Message log table. Natural messages which shall be written to the job message log or to the operator console.
`NTSTAT` | Definition of Natural objects linked to the Natural nucleus.
`NTCPAGE` | Code page definitions.
`NTTAB` | Primary output translation table.
`NTTAB1` `NTTAB2` | Secondary output/input translation tables.
`NTUTAB1` `NTUTAB2` | Tables for translation between lower case and uppercase. These tables have to be modified, for example, for the German character set.
`NTTABA1` `NTTABA2` | Tables for translation of EBCDIC characters to ASCII characters and vice versa. These tables are used by the Object Handler.
`NTTABL` | `SYS*` translation table. Translates output from programs contained in Natural `SYS...` libraries.
`NTLANG` * | Language translation table. Contains a list of all available language codes defined to Natural.
`NTSCTAB` | Scanner character type table. Determines which characters are lower-case alphabetical, uppercase alphabetical, numeric and special characters (applies to dynamic profile parameters, `MASK` and `SCAN` options).
`NTTZ` | Time zone definitions. The `NTTZ` macro enables specifications concerning time zones and automatic switching to and from summertime.
`NTBUFID` | The parameters `MIN` and `MAX` of this macro can be used to change the buffer size limits for variable buffers, see Customization of Buffer Characteristics. Important The default values of the other parameters in this macro should not be modified, because the results may be unpredictable.

* Do not modify without prior consultation of Software AG support any of the tables marked with an asterisk (*) in this list.

For further details, see Translation Tables.

## NTDVCE - Terminal-Device Specification Table

For each terminal type supported by Natural, a terminal converter routine is provided. The corresponding terminal drivers are responsible for the actual terminal I/Os. They build the physical data stream from the screen buffer and the screen attribute buffer and place it in the terminal I/O buffer.

In addition, a telex driver is provided for Con-nect in order to provide faster telex, telefax and teletext communication from and to the Topcall messaging server. This driver supports the Topcall full-page protocol.

With the `NTDVCE` macro, it is possible to add new terminal drivers to Natural to specify modifications of the terminal-specific input/output or lower-to-upper case translation tables. Other information which can be specified is the frame character, the position of the message line, whether screen optimization is to be on or off, as well as various flags in the IOCB. In addition, the terminal specification can be routed to an existing driver by using other translate tables or can hook into a driver routine.

The `NTDVCE` macro is invoked by either the terminal command `%T=` from the Natural command line or the `SET CONTROL` `'T=...'` statement from within a Natural program. At the start of a Natural session, the translation tables `NTTAB`, `NTTAB1`, `NTTAB2`, `NTUTAB1` and `NTUTAB2` are copied from the `NATCONFG` module into the user area where they are modified by `NTDVCE`.

Note that the translation tables can be modified by the same macros dynamically or within the Natural parameter module.

## NTMSG - Message Log Table Definitions

The macro `NTMSG` is used to define Natural messages which shall be written to the operator console or to the job message log (if available). A defined message will be written in addition, that is, the usual Natural processing remains unchanged. To find the log message definition table, locate label `NATMSGT` in `NATCONFG`. There you can add your `NTMSG` definitions on a one message per line basis.

#### NTMSG Macro Syntax

The syntax of the `NTMSG` macro is as follows:

             NTMSG  NATnnnn,logid

#### NTMSG Macro Parameters

Parameter | Description
--- | ---
`NATnnnn` | `nnnn` is the Natural message number (mandatory).
`logid` | Indicates the log destination, that is, the operator console or job message log or both. Possible values: `WTO`, `WTL` or `WTO+WTL`

## NTSTAT - Definition of Natural Objects Linked to the Natural Nucleus

Any object to be linked to the Natural nucleus must be specified with an `NTSTAT` macro. When searching for an object, Natural always scans this list first, regardless of the library specified. For information on how to link Natural objects to the Natural nucleus, see the `ULDOBJ` utility in Linking Natural Objects to the Natural Nucleus.

#### NTSTAT Macro Syntax

The syntax of the `NTSTAT` macro is as follows:

             NTSTAT object-name[,TYPE=W]

#### NTSTAT Macro Parameters

Parameter | Description
--- | ---
`object-name` | Specifies the name of the object linked to the Natural nucleus.
`TYPE=W` | Means that the entry point of the linked object is defined as a "weak external" to the Natural nucleus. This avoids a linkage editor error message in case of the object is not linked to the Natural nucleus.

## NTCPAGE - Code Page Definitions

All code pages to be used during a Natural session must be predefined in the source module `NATCONFG`. For each code page to be defined, a specific macro `NTCPAGE` must be entered. During session initialization, the code page specified by the profile parameters `CP`, `CPOBJIN`, `CPSYNIN`, `CPPRINT` and the `CP` keyword subparameter of profile parameter `PRINT` or parameter macro `NTPRINT` are verified. If this code page is not defined in `NATCONFG`, an error message is issued.

### NTCPAGE Macro Syntax

The syntax of the `NTCPAGE` macro is as follows:

             NTCPAGE IANA=value,                                           *
                   CCSID=value,                                            *
                   CCSN=value,                                             *
                   ALIAS=value,                                            *
                   PHC=value,                                              *
                   MULTI=value,                                            *
                   ECS=value

### NTCPAGE Macro Parameters

Parameter | Description
--- | ---
`IANA` | This parameter is required under all operating systems. It specifies the standard name of the code page. Maximum length: 64 characters.
`CCSID` | This is a required parameter. It specifies the coded character set identification; that is, a numeric value with up to 5 digits. Examples: `1141` German EBCDIC code page `62243` Hebrew/Latin (ISO 8859) code page
`ALIAS` | This parameter is optional. It specifies the code page alias name. Maximum length: 32 characters.
`PHC` | This parameter is optional. It specifies the place holder character. Length: 2 bytes hexadecimal.
`ECS` | This parameter is optional. It specifies the key number of the code page in Entire Conversion Service (ADAECS), which is used by Adabas.
`MULTI` | This parameter is optional. It specifies whether the code page is a single-byte code page or a multi-byte or ASCII code page. Possible values:
`ON` | The code page is a single-byte code page; for example, `IBM01140`. The code page can be used as a Natural session code page. The session code page is defined by the Natural profile parameter `CP`.
`OFF` | The code page is a multi-byte code page or ASCII code page. It cannot be used as a Natural session code page. Any attempt to use this code page results in initialization message NAT7019. This is the default setting.
`VALID` | The code page is a multi-byte code page, but can be used as a Natural session code page. For example, `IBM-939` is a Japanese EBCDIC code page that contains DBCS characters.

Examples:

             NTCPAGE IANA=IBM819,                                          *
                   CCSID=819,                                              *
                   ALIAS='ISO-8859-1',                                     *
                   PHC=003F

             NTCPAGE IANA='IBM-939',                                       *
                   CCSID=939,                                              *
                   ECS=3035,                                               *
                   ALIAS='ibm-939_P120-1999',                              *
                   PHC=3013,                                               *
                   MULTI=VALID

See also Configuration and Administration of the Unicode/Code Page Environment.

## Code Page Support

By using the `NTDVCE` macro, different code pages can be defined and associated with a specific terminal type and name. If Natural is then started with `PM``=C`, all terminal I/O is translated on input and retranslated on output. Thus, as long as the code pages are compatible, a common data representation can still be maintained.

See also SYSCP Utility - Code Page Administration in the Utilities documentation.

## Output Devices Supported

Attribute control variables and formats define attributes to generate a certain representation on the output device. Natural offers a wide range of possible attributes to allow the end user the best use in designing maps and reports on the terminal.

Unfortunately not all terminals support all features available with Natural. These features are mostly ignored on such devices or are simulated via other techniques. Basically there are two data stream definitions in an IBM environment called standard data stream and extended data stream.

The following output devices are supported:

- Sequential Output Devices for Batch, Additional Reports

- Line-Oriented Online Terminals

- Block-Mode-Oriented Online Terminals

### Sequential Output Devices for Batch, Additional Reports

The output data contain standard ASA control characters controlling the line advance and page-eject facility of the given printer. This printer can be either the central printer in the computer center supported by the online or batch spooling system or the SCS printer used as online terminal printers.

The following devices can be used to print reports generated in this form:

Device | Type
--- | ---
Impact printer | Standard central printer hardware
Laser printer | High-speed printer, terminal printer
Daisy printer | Terminal printer
Inkjet | Terminal printer

### Line-Oriented Online Terminals

Terminal Make | Description
--- | ---
TTY | Data sent to TTY devices are generated using the standard formfeed, linefeed, etc. characters.

### Block-Mode-Oriented Online Terminals

Terminal Make | Description
--- | ---
IBM | All models and sizes which support standard data stream and/or extended data stream.
PC | All models and sizes which support standard data stream and/or extended data stream.

## Translation Tables

All data printed, displayed or written by Natural programs are translated by Natural. This guarantees that no illegal control characters can cause terminal I/O errors or display garbage information on the terminal.

Another feature is the translation to and from character sets different from the Latin definition, especially Arabic, Cyrillic, Greek and Hebrew characters.

This section describes all features and functions concerning field translations when data are written to external devices such as CRT (screen terminals) or online and batch spooling systems.

The statements `INPUT`, `DISPLAY`, `PRINT` and `WRITE` write data to or read data from external devices such as CRT, TTY or sequential files. All these statements use parameters such as constants, variables, edit masks, attribute control variables and formats to control the output image and the input representation. Constants and variables are generated by using their respective values in the output image. The representation of these values is then controlled by the attribute control variables, formats, edit masks and translation tables.

Natural uses several translation tables and also provides the use of alternative translation tables, all included in `NATCONFG`.

The following tables are provided:

Macro | Table
--- | ---
`NATSCTU` | Required scanner table for Unicode characters. It maps the properties of Unicode characters of the Unicode Specification (as supported by the delivered ICU version) to be used by the Natural nucleus. Important This table must never be changed.
`NATCPTAB` | Optional single-byte code page conversion accelerator tables. If the table is present, conversion from one code page to another code page will be faster since it is performed via this table rather than by calling ICU functions. The following code pages are supported by the delivered `NATCPTAB`: `IBM01140` `IBM01141` `IBM01145` `IBM01146` `IBM01147` `ASCII` It is possible to add new entries by using the `NTCPCNV` macro. For each conversion direction, an entry is needed that contains the IANA name of the source code page, the IANA name of the target code page and optionally a blank character, a substitution character and a place holder character, followed by a complete list of character mappings.
`NTSCTAB` | The table which defines the properties of characters used in mask definitions for the `MASK` option, recognized as delimiters in the `EXAMINE` and `SEPARATE` statements. This table can be used to define upper-case attributes, lower-case attributes, special characters, hexadecimal characters and numeric characters. To modify this table, use the macro `NTSCTAB` in the Natural parameter module or the corresponding dynamic profile parameter `SCTAB`. If the `CP` profile parameter is set to a value other than `OFF`, the modification is ignored and the table is adjusted according to the code page used for the Natural session. See also Translation Tables in the Unicode and Code Page Support documentation.
`NTTAB` | The standard (primary) output translation table used for screen or printer output. Basically this table is used to translate all characters below `X'40'`, that is from the space character to the question mark (`X'00'` is not translated). This guarantees that all terminal-control characters are translated before output and no control escape sequences can influence the screen output. Special characters (`X'FE'` and `X'FF'`) which could influence the screen output are translated to the question mark (`?`). If nothing else is specified, all Natural output data are translated with `NTTAB`. To modify this table, use the macro `NTTAB` in the Natural parameter module or the corresponding dynamic profile parameter `TAB`. The modification is ignored if a code page is specified using profile parameter `CP` (`CP=ON`, `CP=AUTO` or `CP=code-page`), and the table is adjusted by ICU according to the code page used at session start. Furthermore, all characters below `X'40'` are translated to the question mark (`?`) as described above. A character is excluded from this translation if either of the following conditions is true: The character is explicitly translated to the same character. The character is one of the logical shift-out/shift-in characters specified with the `SOSI` profile parameter (see the Parameter Reference documentation), and the specified code page is not an MBCS code page.
`NTTAB1` | The alternative (secondary) output translation table for the secondary character set used when the Natural parameter `PM` is set to `C`. The important aspect is the translation of all possible terminal-control characters. If `PM=C` is specified, all Natural output data are translated with `NTTAB1`. A possible application of `NTTAB1` is to avoid the translation of escape sequences for printer control. To modify this table, use the macro `NTTAB1` in the Natural parameter module or the corresponding dynamic profile parameter `TAB1`. The modification is ignored if a code page is specified using profile parameter `CP` (`CP=ON`, `CP=AUTO` or `CP=code-page`), and the table is not used.
`NTTAB2` | The secondary input translation table used when the Natural parameter `PM` is set to "C". If `PM``=C` is specified, all Natural input data are translated with `NTTAB2`. Conversion between different languages or code pages can be performed with this table together with `NTTAB1`. To modify this table, use the macro `NTTAB2` in the Natural parameter module or the corresponding dynamic profile parameter `TAB2`. The modification is ignored if a code page is specified using profile parameter `CP` (`CP=ON`, `CP=AUTO` or `CP=code-page`), and the table is not used.
`NTTABS` | This table defines all valid characters that can be used in Natural variable names; it is used for the Natural syntax processor. It also defines all valid characters that can be used in the first position of a Natural variable name. In addition, it defines whether the variable is a global variable, a non-database variable or a source-code variable. If a code page is specified using profile parameter `CP` (`CP=ON`, `CP=AUTO` or `CP=code-page`), the table is adjusted by ICU according to the code page used at session start.
`NTUTAB1` | The sample user-specific translation table for input translation from lower to upper case. In addition, this table performs the translation specified with the statement `EXAMINE TRANSLATE` `INTO UPPER CASE`. To modify this table, use the macro `NTUTAB1` in the Natural parameter module or the corresponding dynamic profile parameter `UTAB1`. The modification is ignored if a code page is specified using profile parameter `CP` (`CP=ON`, `CP=AUTO` or `CP=code-page`), and the table is not used.
`NTUTAB2` | The sample user-specific translation table which performs the translation specified with the statement `EXAMINE TRANSLATE` `INTO LOWER CASE`. To modify this table, you can use the macro `NTUTAB2` in the Natural parameter module or the corresponding profile parameter `UTAB2`. The modification is ignored if a code page is specified using profile parameter `CP` (`CP=ON`, `CP=AUTO` or `CP=code-page`), and the table is not used.
`NTLANG` | The language-code table, which defines which language number is assigned to which language code in the system variable `*LANGUAGE`.
`NTTABL` | The `SYS*` output translation table, which is controlled by the Natural profile parameter `TS`. With `TS=ON`, this table is used to translate output produced by programs located in Natural `SYS*` libraries (except modifiable fields) from Latin lower case to upper case. This table allows the use of all upper- and lower-case characters in Latin oriented countries, but still allows the use of these applications in countries where the lower-case characters have been replaced with a native alphabet. To modify this table, use the macro `NTTABL` in the Natural parameter module or the corresponding dynamic profile parameter `TABL`. If Natural is running with an MBCS code page (for example, `CP='IBM-939'`), the table is not used, but translation is performed via ICU according to the current locale settings.
`WRDFCUC1` `WRDFCUC2` `WRDFCSP2` | The DBCS translation tables used to translate double-byte characters into Latin characters and vice versa. Important These tables have to be activated explicitly, for example, for Far East countries.

## Upper-/Lower-Case Translation

For modifiable and input fields, upper- and lower-case translation can be specified. In general, lower-case translation means that data are taken as they come in; no translation is performed. This even makes it possible in batch mode, for instance, to read in hexadecimal data without translation.

There are several ways of specifying upper-/lower-case translation:

`LC``=OFF` | Lower-case translation is switched off, which means that global upper-case translation is in effect. This profile parameter can be specified in the Natural parameter module or as dynamic parameter. (Note that the session parameter `LC` has a completely different function.)
`%U` | Upper-case translation is globally on. On the field level, the attribute `AD=T` or `AD=W` can be specified. These attributes only take effect when the global upper-case translation is deactivated (`LC``=ON`, `%L`). Then it is possible to control the translation on a field level from within a Natural program.
`EXAMINE TRANSLATE` | Upper-/lower-case translation can also be performed with the `EXAMINE TRANSLATE` statement. By default, `EXAMINE TRANSLATE` translates to upper case by using the translation table `NTUTAB1`, and to lower case by using the translation table `NTUTAB2`.

## CMULT Entry

It is no longer recommended to use the `CMULT` entry; use the `EXAMINE TRANSLATE` statement instead (see above).

## Output Translation

All fields, after having been formatted by possible edit masks, `AL` or `NL` parameter values, filling characters, etc. are translated using a translation table. This ensures that no data can be sent to the front-end printing device with embedded control information which is not explicitly generated by Natural. This means that fields can be sent to a display device even if they contain hexadecimal information which is identical to internal attributes. These attributes are translated before an output operation and so Natural guarantees the screen layout as defined by the output statement.

There are several translation tables available. If nothing explicit is defined, the primary translate table `NTTAB` is used.

If `PM``=C` is specified, the secondary translation table `NTTAB1` is used. For modifiable fields, `PM=C` also means that the incoming data are translated again; that is, translated for output and retranslated for input.

With this translation table logic it is possible, for example, to convert Arabic numerals to Latin numerals. Arabic numerals have a different hexadecimal representation from the normal Latin numerals on the terminal hardware. So on output, the Latin numerals can be translated into the Arabic equivalent and on input, the Arabic numerals can be retranslated into Latin.

Special considerations have to be made for the Natural system applications which use Latin lower-case and upper-case characters. Especially on terminals supporting Arabic, Greek, Cyrillic, etc., the hardware can be switched to not display lower-case Latin characters, but rather the native characters.

Unfortunately, Latin lower-case characters are crabbed when displayed in, for instance, Cyrillic. So Natural can be used with the parameter `TS``=ON` (translate system output). `TS=ON` translates "SYS*" libraries (not including library `SYSTEM`) and all Natural system commands by using a third translation table called `NTTABL`. By default, this translation table performs upper-case translation for all lower-case Latin characters. Of course, only output data are treated this way. So this allows data entry in the native character set even in Natural editors or system applications.

However, if Natural utilities are used to display data typed in the native character set, this results in an upper-case translation even for data in, for example, Cyrillic representation. The result would again be unreadable. So all Natural system utilities can use the format `PM``=C` for fields containing data entered in the native character set. In this case, neither the `NTTABL` translation table nor the secondary translation table `NTTAB1` is used. The data are simply translated by the primary translation table `NTTAB`.

For further information, see the profile parameters `PM`, and `TS` in the Parameter Reference documentation.

## Input Translation

The translation table `NTUTAB1` is available to control translation from lower to upper case. This might cause problems in countries where special characters are used which are not set up with the simple logic that just one bit controls the status of this letter. This especially concerns German umlauts or Danish special characters. In such cases, translation can only be achieved by customizing the `NTUTAB1` table, where for each character the corresponding lower-/upper-case character can be specified.

If upper-case translation (`%U`) and `PM``=C` is specified, first upper-case translation (using `NTUTAB1`) and then the secondary input translation (using `NTTAB2`) is performed.

## Code Translation of DBCS Data

So that double-byte character set (DBCS) data can be processed the user application programming interface `USR4213N` is provided to translate double-byte characters into Latin characters, see Double-Byte Character Sets (DBCS).

## NTTZ - Time Zone Definitions

The `NTTZ` macro is used to specify a time zone and an automatic switch to and from summertime.

Note
Time definitions are determined by the system administrator, and the user can reference these definitions by using the Natural profile parameter `TD``=zonename`. With this parameter, users from different countries and time zones are able to select their own local time.

The `NTTZ` macro can be used on a minimal basis to define a time difference for a time zone. In addition, an automatic switch to and from summertime can be specified, either as a fixed date or in a more flexible definition like "first Sunday in April". The automatic switch to and from summertime is processed during a running Natural session, without requiring any user interactions. Predefined samples of `NTTZ` macro definitions are available in the Software AG-delivered `NATCONFG` module.

Reference point for automatic switching to and from summertime is the current machine time, which is UTC (GMT) time. Depending on the time period the current machine time is in, the current local time is determined. The support of automatic switching to and from summertime is currently for years in the range from 2002 to 2041.

The following topics are covered below:

- NTTZ Macro Considerations and Restrictions

- NTTZ Macro Syntax

- NTTZ Macro Parameters

- Example of NTTZ Macro

### NTTZ Macro Considerations and Restrictions

The following considerations and restrictions apply:

1. #### Time Format

   The basic time format is:

       +hh:mm:ss

   or:

       -hh:mm:ss

   ranging from `00:00:00` through `23:59:59`; abbreviations are also allowed, for example: hh:mm or simply hh. The plus sign (+) is assumed by default, the minus sign (-) may be necessary with the parameters `TDON` or `TDOFF`.

2. #### UTC versus Local Time

   In order to have a unique point of reference for the time switch, the `NTTZ` macro parameters `SWTON` and `SWTOFF` are given in UTC time, whereas the weekday names and day numbers in the `NTTZ` macro parameters `DSTON` and `DSTOFF` are specified in local time.

3. #### Concurrent Use of Natural Profile Parameters DD, YD, and TD

   The Natural profile parameters `DD` and `YD` do not have any effect on the automatic switching to and from summertime, since the switch is done on the basis of the current machine time.

   It is recommended to avoid the concurrent use of `DD` or `YD` and profile parameter `TD=zonename`.

4. #### Concurrent Use of Natural Profile Parameter TD and User Exit CMCOTIME

   Concurrent use of profile parameter `TD=zonename` and user exit `CMCOTIME` (override machine time) is not recommended, because a change of machine time (TOD clock) may cause unpredictable results for automatic switching invoked with `TD=zonename`.

### NTTZ Macro Syntax

The syntax of the `NTTZ` macro is as follows:

             NTTZ ZONE=value;                                              *
                   TDON=value,                                             *
                   TDOFF=value,                                            *
                   SWTON=value,                                            *
                   SWTOFF=value,                                           *
                   DSTONvalue,                                             *
                   DSTOFF=value

### NTTZ Macro Parameters

`ZONE` | `TDON` | `TDOFF` | `SWTON` | `SWTOFF` | `DSTON` | `DSTOFF`

> ZONE - Time Zone Name

>   `ZONE=value` specifies the Software AG or user-defined time zone name which can be referenced with the `TD` parameter. The first occurrence of a name will be selected.

>   Value | Explanation
>   --- | ---
>   32 characters. | The maximum length of a time zone name is 32 characters to allow for descriptive user defined zone names, for example, the name of the capital city of a country.

> TDON - Difference of Local Daylight Saving Time to UTC Time

>   `TDON=value` denotes the difference of local daylight saving time (summertime) to UTC time (formerly GMT).

>   Value | Explanation
>   --- | ---
>   `+hh:mm:ss` or `-hh:mm:ss` | See Time Format.

>   Notes:

>   1. If only the parameter `TDON` is defined, the user gets display of local time as his zone time, without automatic switching to and from summertime.
>   2. The parameter `TDON` corresponds to the parameter `SWTON`.
> TDOFF - Difference of Local Zone Time to UTC Time

>   `TDOFF=value` denotes the difference of local zone time to UTC time (formerly GMT).

>   Value | Explanation
>   --- | ---
>   `+hh:mm:ss` or `-hh:mm:ss` | See also Time Format.

>   Note
>   This parameter corresponds to the parameter `SWTOFF`.

> SWTON - Time when Daylight Saving Time Starts

>   `SWTON=value` denotes the UTC point of time when daylight saving time (summertime) is switched on.

>   Value | Explanation
>   --- | ---
>   `hh:mm:ss` | See also Time Format.

> SWTOFF - Time when Daylight Saving Time Ends

>   `SWTOFF=value` denotes the UTC point of time when daylight saving time (summertime) is switched off.

>   Value | Explanation
>   --- | ---
>   `hh:mm:ss` | See also Time Format.

> DSTON - Date when Daylight Saving Time Starts

>   `DSTON=(value1,value2,value3,value4,day-number)` denotes the day when daylight saving time (summertime) is switched on.

>   Value | Possible Settings
>   --- | ---
>   `value1` | `FIRST`, `SECOND`, `THIRD`, `FOURTH` or `LAST`.
>   `value2` | `MONDAY`, `TUESDAY`, `WEDNESDAY`, `THURSDAY`, `FRIDAY`, `SATURDAY` or `SUNDAY`.
>   `value3` | `AFTER`, `BEFORE` or `IN`.
>   `value4` | `JANUARY` ... `DECEMBER`.
>   `day-number` | A valid day number for the respective month. The default value is `1`.

>   Notes:

>   1. The keyword `LAST` requires the keyword `BEFORE` or `IN`.
>   2. No `day number` must be specified if the keyword `IN` is specified.
> DSTOFF - Date when Daylight Saving Time Ends

>   `DSTOFF=(value1,value2,value3,value4,day-number)` denotes the day when daylight saving time (summertime) is switched off.

>   Value | Possible Settings
>   --- | ---
>   `value1` | `FIRST`, `SECOND`, `THIRD`, `FOURTH` or `LAST`.
>   `value2` | `MONDAY`, `TUESDAY`, `WEDNESDAY`, `THURSDAY`, `FRIDAY`, `SATURDAY` or `SUNDAY`.
>   `value3` | `AFTER`, `BEFORE` or `IN`.
>   `value4` | `JANUARY` ... `DECEMBER`.
>   `day-number` | A valid day number for the respective month. The default value is `1`.

>   Notes:

>   1. The keyword `LAST` requires the keyword `BEFORE` or `IN`.
>   2. No `day number` must be specified if the keyword `IN` is specified.

### Example of NTTZ Macro

For daylight saving time switching in Western Europe:

             NTTZ ZONE=MEZ,                                                *
                   TDON=2,                                                 *
                   TDOFF=+01:00:00,                                        *
                   SWTON=01:00:00,                                         *
                   SWTOFF=01:00:00,                                        *
                   DSTON=(LAST,SUNDAY,IN,MARCH),                           *
                   DSTOFF=(LAST,SUNDAY,IN,OCTOBER)

Additional examples of different time zones (North and South America, Asia, etc.) can be found in the Software AG-delivered `NATCONFG` module.

### On this page

- NATCONFG - Natural Configuration Tables
- General Overview of Macros Used by NATCONFG
- NTDVCE - Terminal-Device Specification Table
- NTMSG - Message Log Table Definitions
- NTSTAT - Definition of Natural Objects Linked to the Natural Nucleus
- NTCPAGE - Code Page Definitions
- Code Page Support
- Output Devices Supported
- Translation Tables
- Upper-/Lower-Case Translation
- CMULT Entry
- Output Translation
- Input Translation
- Code Translation of DBCS Data
- NTTZ - Time Zone Definitions