Version 4.2.6 for Mainframes (Update)
 —  Operations  —

Natural Configuration Tables

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

The following topics are covered:

See also:


NATCONFG Module

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 NATPARM 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 system maintenance (SM) releases.)

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

In addition, it uses the following tables:

Top of page

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.

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 and upper case. 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, upper-case alphabetical, numeric and special characters (applies to dynamic profile parameters, MASK and SCAN options).
NTTZ Time zone definitions. The NTTZ macro enables specifications about zonetime 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.

Top of page

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, the telex driver module NATTLX is provided for Con-nect in order to provide faster telex, telefax and teletex communication from and to the TOPCALL system. NATTLX 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 NATPARM parameter module.

Top of page

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

Top of page

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.

Top of page

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

NTCPAGE Macro Parameters

Parameter Description
IANA The standard name of the code page. Maximum length: 64 characters. This parameter is mandatory.
CCSID Coded Character Set IDentification (IBM). A numeric value with up to 5 digits.

Examples:
1141 German EBCDIC code page
62243 Hebrew/Latin (ISO 8859) code page

CCSN Coded Character Set Name (Siemens BS2000/OSD). An alphanumeric string of up to 8 characters.

Examples:
EDF041 Latin code page for Western Europe
EDF045 Latin/Cyrillic code page

ALIAS Alias code page name. Maximum length: 32 characters. This parameter is optional, not unique.
PHC Place Holder Character. Length: 2 byte hexadecimal. This parameter is optional

Note:
The parameters CCSID and CCSN are platform-specific (IBM/SNI) and mutually exclusive.

Example:

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

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

Top of page

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.

Top of page

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 and a multitude of data stream definitions in an SNI environment.

The following output devices are supported:

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.
SNI All 9750 and compatible monochrome devices and all 9763 and compatible color devices.
Wang All models.
PC All models and sizes which support standard data stream and/or extended data stream.

Top of page

Specification of NTDVCE

For information on how the NTDVCE macro is specified and for descriptions of the individual parameters, refer to the NTDVCE macro itself.

Example of NTDVCE macro:

NTDVCE TYP=EBS2,NAME=BS2CHAR,ENTRY=VC3270,WXTRN=OFF,RTAL=5,
       FLAG1=CM3270,TCIO=(X'C0',X'FB',X'6A',X'4F',X'D0',X'FD',       
       X'4A',X'BB',X'E0',X'BC',X'5A',X'BD',X'A1',X'FF',X'4F',
       X'5A')

This sample macro converts internal SNI code pages to external IBM code pages. This enables you to develop applications on IBM terminals, which internally work with SNI code pages to, for example, avoid data collision when migrating from IBM to SNI.

Top of page

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 SCAN/MASK character table which defines the properties of each printable character for the Natural mask definition function.

This table can be used to define upper-case attributes, lower-case attributes, special characters, hexadecimal characters and numeric characters.

It can be modified by the user and the result can be used directly in the Natural MASK clause.

To modify this table, use the macro NTSCTAB in the Natural parameter module or the corresponding dynamic profile parameter SCTAB.

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.

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 into question marks.

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. Then, although Natural is running with a code page, the translation using this table continues in order to avoid invalid, unprintable characters from the resulting output data.

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.

Top of page

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.

Top of page

CMULT Entry

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

Top of page

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.

Top of page

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.

Top of page

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).

Top of page

NTTZ - Time Zone Definitions

The following topics are covered below:

NTTZ Macro

The NTTZ macro enables specifications about zonetime and automatic switching to and from summertime.

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 timezone. 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 shipped with NATCONFG.

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 for automatic switching to and from summertime is currently for years in the range from 2002 to 2041.

Notes:

  1. 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 concurrent use of DD or YD with TD=zonename.
  2. Concurrent use of 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=time-zone-name,TDON=+/-hh:mm:ss,
     [TDOFF=+/-hh:mm:ss,SWTON=hh:mm:ss,
     SWTOFF=hh:mm:ss,
     DSTON=([{FIRST | SECOND | THIRD | FOURTH | LAST}, 
             {MONDAY | ... | SUNDAY},
             {AFTER | BEFORE | IN}],
             {JANUARY | ... | DECEMBER},
             [,day-number]),
      DSTOFF=([{FIRST | SECOND | THIRD | FOURTH | LAST}, 
             {MONDAY | ... | SUNDAY},
             {AFTER | BEFORE | IN}], 
             {JANUARY | ... | DECEMBER} 
             [,day-number])]         

NTTZ Macro Parameters

NTTZ Macro Parameter Description
<time +/- hh:mm:ss> The basic format is <{+/-} hh:mm:ss> ranging from 00:00:00 through 23:59:59; abbreviations are also allowed, like: <hh:mm> or simply <hh>. The plus sign (+) is assumed by default, the minus sign (-) may be necessary with the parameters TDON or TDOFF (see below).
time-zone-name 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. 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

Denotes the difference of local daylight saving time (summertime) to UTC time (formerly GMT). This parameter corresponds to the parameter SWTON.

If only the TDON parameter is defined, the user gets display of local time as his zone time, without automatic switching to and from summertime.

TDOFF Denotes the difference of local zone time to UTC time (formerly GMT). This parameter corresponds to the parameter SWTOFF.
SWTON Denotes the UTC point of time when daylight saving time (summertime) is switched on.
SWTOFF Denotes the UTC point of time when daylight saving time is switched off.
DSTON Denotes the day when daylight saving time (summertime) is switched on.
DSTOFF Denotes the day when daylight saving time (summertime) is switched off.
day-number A valid day number for the respective month; the default for day-number being 1.

Restrictions of NTTZ Macro

Note:
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 specifications in local time.

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.

Top of page