[Main topics] [Navigation]

NLA - Operating system requirements

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

An NLA at first must be implemented in basic tools like

[To top/bottom of page] 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:

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

[Structure of the user environment]

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.

[Head of a person][Structure of the presentation services]

[To top/bottom of page] 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.
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):

System View of Environment

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

[System view of NLA functions: a layered approach]

[To top/bottom of page] 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:

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.

[To top/bottom of page] 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.

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

[To top/bottom of page] 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.

[To top/bottom of page] 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:

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


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.

[To top/bottom of page] 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.


[Main topics] [Navigation]
 URL:  Created: 1996-12-28  Updated:
© Docu+Design Daube, Zürich    
  Business of Docu + Design Daube Documentation issues Sharing information Klaus Daube's personal opinions Guests on this site Home of Docu + Design Daube To main page in this category To first page in series To previous page in series To next page in series To bottom of page To top of page Search this site Site map Mail to webmaster To bottom of page To top of page