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/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.
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
The parameters CCSID and
CCSN are platform-specific (IBM/SNI) and mutually
exclusive.
| 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/OSD. 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 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.
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 and a multitude of data stream definitions in an SNI environment.
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. |
| 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. |
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.
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 parameters
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.