NLA - Operating system requirements

Setting the Environment
System Services
Compiler and Runtime System
Text Representation
Portability
Utilities
Low Level Functions

An NLA at first must be implemented in basic tools like

• System services
• Compilers
• Utilities
• Messages
• Menus

Setting the Environment

There must be only one method to manage the environment (for example: control panel in OS/2 Presentation Manager). This must be provided by the implementation of NLA, so that applications can assume a correct set-up.

It may be very difficult to specify the nature af a particular (default) environment (e.g. French environment). Hence also the set-up of defaults must be flexible:

• French panels, help texts, messages, etc (Machine Readable Information)
• French language of user data
• French code page
• French keyboard layout, character set
• French lexicographic sort order
• French handling of date, time, numeric punctuation

It is desirable that National Language attributes can be clustered or grouped to a «user profile ». This would ease task orientation:

• sort in telephone directory
• sort in dictionary

A different way of specifying the requested flexibility leads to the following rules [UniForum-2]:

1. The system must support an extended set of features (for example large character sets).
2. The system must be able to adjust the behaviour of specific functions or utilities (e.g. sort).
3. A user must have the capability to select an environment that specifies a particular behaviour.
4. The system must be able to support different environments for different users concurrently.
5. Behaviour-controlling information must be external to an executing process (named resources).
6. Each named resource controls a separate aspect of the behaviour (for example attributes of the character set).
7. A process must be able to select a specific behaviour, and change the selection, at execution time, using the name of the resource.
8. When a process selects or changes a specific behaviour, the change must take effect immediately.
9. The architecture must be flexible enough to support future extensions and requirements.

System Services

Functions provided by the NLA must be implemented independently of any programming language or runtime system. In particular it is unacceptable to have these functions available only in Assembler macros. The information and functions must be accessible by any programming language or application via standard interfaces to common services.

The programming language interface must be consistent across the various operating systems and must hide the details of the OS interface (which may differ between operating systems).

In the description of the architecture it is not a concern whether a particular service would result in a «callable system service» or only in the setting of some global variable. However the implementation of the NLA should be consistent across operating systems. That is, if the service is implemented in one OS as a callable routine, it must not be an intrinsic function to a programming language in another OS.

The architecture must also provide a «dynamic environment» for these services, since their behaviour may change during the lifetime of applications. It would be unacceptable to have to «relink» applications after every change of internal function, if a more efficient method of sorting may become available.

System services are the base for the functionality of the higher services. Implementing an NLA under SAA requires subroutines (in contrast to Assembly macros) to provide the basic services. The architecture must specify:

Data types

They must be chosen so they can be processed particularly by higher programming languages. Machine dependent representations (like packed decimal) must be avoided.

Parameters

It may be desirable to specify different parameter lists for different programming languages, or an indicator of the calling environment. Note that in some programming languages the index of the first element is 0, in others it is 1.

Entry Point Names

It may be necessary to have short cryptic entry names due to programming languages and system limitations. However longer names should be possible. A clear naming scheme should be provided like SYS-NLA-SORT for the sorting function.

NLA functions need to be layered into (from highest to lowest):

• message services
• national language basic services
• code point services
• possibly hardware-extensions to serve National Language services

System View of Environment

In the manner of UNIX the system view of the environment can be sketched as follows:

Compiler and Runtime System

Although the character set and code issue is often not specified in the standards for a programming language [Wingen-1] certain criteria must be met by a modern compiler:

• The vocabulary of the programming language (syntactic elements, key words, reserved words) are independent of translations into national languages.
• Source code must be allowed to use all code pages available on that system. Compiler directives must make use of the NLA functions needed to support different code pages.
• A compiler must not use an arbitrary otherwise undefined code page [IBM SC09-1264]).
• Comments must be allowed to use all national characters available in the actual code page.
• String constants must be allowed to use all national characters available in the actual code page. The string constant must be tagged in the same way as requested for files.
• Labels must both allow lengthy names and use of all national alphabet characters available in the actual code page
• Names of subroutines must be the same for all SAA languages.
• Input parameters must be specified in the same order on the call statement.
• Output parameters, where applicable, must be in the same order on the call statement.

Both the compiler and the runtime system must make use of the same base functions.

It must be possible to use the NLA to write a program with French comments and Turkish string constants.

Text Representation

All text files or storage areas must have the attributes from the following list. Text fields in data bases require these attributes, because different fields may use different languages, or fields may use different code pages (for example for correct representation of personal names). These attributes should also apply to other topics, such as hyphenation, switching between Arabic and western text in word processing.

• Length of data
• Coding scheme (code page, interpretation of characters)
• Language (including country specifics), for example
  • country
  • sequencing scheme (alphasorting)

For further explanation see sections Data Encoding and Data Type Key.

Portability

It must be possible to interchange textual data across different operating systems without losing any information. Hence text data needs attributes to support translation and transformations.

Exchange of data between different systems may assume «knowledge» about the meaning of tags. Only in rare circumstances should it be necessary to accompany the data by a prolog explaining the contents or meaning of tags. This description could be generated on the sending system with the services of «query National Language attributes» The information must be complete to allow set-up of a matching environment on the target system.

Utilities

IBM supplied utilities must use the NLA as soon as possible. In particular the sort utility must use the same basic functions. Duplication of code must be avoided to guarantee consistent results with different approaches.

What was said for compilers must also be applied to utilities:

• Source code must be allowed to use all code pages available on that system. Directives must make use of the NLA functions needed to support different code pages
• Comments must be allowed to use all national characters available in the actual code page
• String constants must be allowed to use all national characters available in the actual code page
• Labels must both allow lengthy names and use of all national alphabet characters available in the actual code page

New utilities like conversion of text data to new coding scheme, must be developed.

Directives

Especially for sort-utilities a directive must be available to avoid any form of translation for fields, even if they are declared to be text (for example in a data dictionary). This is to protect existing data with weak specification.

As an example for this problem, consider fields containing data and time stamps, with the latter in «packed decimal». These can only be interpreted by special applications which expect this format and so must be preserved intact.

Low Level Functions

In an application there must be a clear separation between functions which depend on the processing environment (language, code page and so on) and functions which do not. The techniques used in these different areas may differ significantly in performance.

It is outside the scope of an NLA to specify where NLA functions (like compare) must be used and where standard functions (for example «compare logical character» in Assembler) are sufficient.