This document provides general information on the Natural configuration tables which are
contained in the NATCONFG module.
This section covers the following topics:
See also:
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 (*).
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: |
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: |
* 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.
For each terminal type supported by Natural, a terminal converter routine is provided. The corresponding terminal drivers are responsible for the actual terminal I/O operations. 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.
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.
The syntax of the NTMSG macro is as follows:
NTMSG NATnnnn,logid
| 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: |
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.
The syntax of the NTSTAT macro is as follows:
NTSTAT object-name[,TYPE=W]
| 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. |
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.
The syntax of the NTCPAGE macro is as follows:
NTCPAGE IANA=value, *
CCSID=value, *
CCSN=value, *
ALIAS=value, *
PHC=value, *
MULTI=value, *
ECS=value
| 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 parameter is required under z/OS,
z/VSE. It specifies the coded
character set identification; that is, a numeric value with up to 5 digits.
Examples: |
|
CCSN |
This parameter is required under BS2000. It
specifies the coded character set name; that is, an alphanumeric string of up to
8 characters.
Examples: |
|
ALIAS |
This parameter is optional. It specifies the code page alias name. Maximum length: 32 characters. | |
PHC |
This parameter is optional. It specifies the placeholder 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.
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.
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:
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 |
| Terminal Make | Description |
|---|---|
| TTY | Data sent to TTY devices are generated using the standard formfeed, linefeed, etc. characters. |
| 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. |
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: |
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
It is possible to add new entries by using the |
NTSCTAB |
The table which defines the properties of characters
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 If the |
NTTAB |
The standard (primary) output translation table used for screen or printer
output.
Basically this table is used to translate all characters below
If nothing else is specified, all Natural output data are translated with
To modify this table, use the macro The modification is ignored if a code page is specified using profile parameter
Furthermore, all characters below
|
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 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 |
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 The modification is ignored if a code page is specified using profile parameter
|
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 |
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 To modify this table, use the macro The modification is ignored if a code page is specified using profile parameter
|
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
The modification is ignored if a code page is specified using profile parameter
|
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 macroNTTABL in the Natural parameter module or the
corresponding dynamic profile parameter TABL.
If Natural is running with an MBCS
code page (for example, |
|
|
The DBCS translation tables used to translate double-byte characters into
Latin characters and vice versa.
Important: |
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 |
%U
|
Upper-case translation is globally on.
On the field level, the attribute
|
EXAMINE
TRANSLATE
|
Upper-/lower-case translation can also be performed with the EXAMINE
TRANSLATE statement.
By default, |
It is no longer recommended to use the CMULT entry; use the EXAMINE
TRANSLATE statement instead (see above).
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.
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.
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).
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:
The following considerations and restrictions apply:
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 parameter TDON or TDOFF.
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.
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.
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.
The syntax of the NTTZ macro is as follows:
NTTZ ZONE=value; *
TDON=value, *
TDOFF=value, *
SWTON=value, *
SWTOFF=value, *
DSTONvalue, *
DSTOFF=value
ZONE | TDON | TDOFF | SWTON | SWTOFF | DSTON | DSTOFF
- ZONE - Time Zone Name
ZONE=valuespecifies the Software AG or user-defined time zone name which can be referenced with theTDparameter. 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=valuedenotes the difference of local daylight saving time (summertime) to UTC time (formerly GMT).
Value Explanation
+hh:mm:ss
or
-hh:mm:ssSee Time Format. Notes:
- If only the parameter
TDONis defined, the user gets display of local time as his zone time, without automatic switching to and from summertime.- The parameter
TDONcorresponds to the parameterSWTON.- TDOFF - Difference of Local Zone Time to UTC Time
TDOFF=valuedenotes the difference of local zone time to UTC time (formerly GMT).
Value Explanation
+hh:mm:ss
or
-hh:mm:ssSee also Time Format. Note:
This parameter corresponds to the parameterSWTOFF.- SWTON - Time when Daylight Saving Time Starts
SWTON=valuedenotes the UTC point of time when daylight saving time (summertime) is switched on.
Value Explanation hh:mm:ssSee also Time Format. - SWTOFF - Time when Daylight Saving Time Ends
SWTOFF=valuedenotes the UTC point of time when daylight saving time (summertime) is switched off.
Value Explanation hh:mm:ssSee 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 value1FIRST,SECOND,THIRD,FOURTHorLAST.value2MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY,SATURDAYorSUNDAY.value3AFTER,BEFOREorIN.value4JANUARY...DECEMBER.day-numberA valid day number for the respective month. The default value is
1.Notes:
- The keyword
LASTrequires the keywordBEFOREorIN.- No
day numbermust be specified if the keywordINis 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 value1FIRST,SECOND,THIRD,FOURTHorLAST.value2MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY,SATURDAYorSUNDAY.value3AFTER,BEFOREorIN.value4JANUARY...DECEMBER.day-numberA valid day number for the respective month. The default value is
1.Notes:
- The keyword
LASTrequires the keywordBEFOREorIN.- No
day numbermust be specified if the keywordINis specified.
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.