Version 4.2.6	SEARCH   INDEX   CONTENTS   |   PDF PAGE   PDF BOOKS   |   HOME   UP   PREV   NEXT

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

The following topics are covered:

• NATCONFG Module

• 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

• Specification of NTDVCE

• 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 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:

• 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:

* 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, 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.

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

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

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 Macro Parameters

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.

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

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:

Line-Oriented Online Terminals

Block-Mode-Oriented Online Terminals

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.

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

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:

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:

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 following topics are covered below:

• NTTZ Macro

• NTTZ Macro Syntax

• NTTZ Macro Parameters

• Restrictions of NTTZ Macro

• Example of NTTZ Macro

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

Restrictions of NTTZ Macro

• LAST requires BEFORE or IN.

• If IN is specified, no day number must be specified.

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.

www.softwareag.com

Copyright © 1979-2010 Software AG, Darmstadt, Germany.

SEARCH   INDEX   CONTENTS   |   PDF PAGE   PDF BOOKS   |   HOME   UP   PREV   NEXT