SPoD-Specific Limitations and Considerations

When you are working with Natural Single Point of Development, you will encounter a few limitations which are due to the different capabilities of the graphical user interface available on the local site and the character-based user interface that exists on the remote site. In addition, this document includes hints which are important for the efficient use of the remote development facilities.

This document covers the following topics:

Editor Features With SPoD

You can use Natural's Single Point of Development with different versions of Natural on a variety of platforms. Depending on the server environment you are using together with Natural for Windows (client), the editors offer different features. For further information, refer to the section Editor Features With SPoD in the Natural for Windows Editors documentation.


Limitations

The following topics are covered:

System Commands

The following topics are covered:

System Commands Entered Directly on the Development Server

All system commands which are not entered in the user interface of Natural Studio are executed directly by the Development Server without control of Natural Studio. As a result, the character-based representation of the corresponding command appears in the terminal emulation window. This is the case when the STACK TOP COMMAND mechanism is used or when a system command is directly entered inside the terminal emulation window.

During the mapping phase any STACK commands entered in the text box Session Parameters are processed within Natural Studio and the corresponding Natural Studio windows are used.

The commands HELLO and MAINMENU do not cause a screen output on the development server side, since this would not make any sense in the SPoD environment. Instead of the menu-driven user interface, the dialogs provided in Natural Studio are used.

Terminal Commands

Using terminal commands in a SPoD environment is only possible within the terminal emulation window. Entering terminal commands in the command line of Natural Studio is not possible.

Moving/Copying Error Messages

Moving and copying of error messages is different in remote and local environments:

  • When error messages are moved or copied within the remote environment or are moved or copied from the local to the remote environment or vice versa: the error messages involved are merged, that is,

    • error messages which already exist in the target environment are replaced,

    • messages which do not exist in the source library are kept in the target library,

    • messages which do not exist in the target library are added.

  • When error messages are moved or copied within the local environment, the messages involved are handled on file level, that is,

    • all error messages (that is, files) of a language are deleted and

    • the file from the source library is created anew in the target library.

Maps Containing GUI Elements

Maps containing GUI elements can be moved or copied from the local environment to a remote environment. However, the GUI elements are not displayed when the map is being tested or executed on the remote environment.

Field Sensitive Maps

For these maps, the consistency check for a map field is made as soon as the user input has been entered. Field sensitive maps can be moved or copied from the local environment to a remote environment. However, a field sensitive map cannot be tested or executed on a remote mainframe environment.

Dependencies between XRef Evaluation and Predict

If you are using dynamic language assigned when calling other objects such as INPUT USING MAP 'MAP1&', the connection between caller and called object cannot be retrieved by using XRef Evaluation.

Natural on the mainframe supports case-sensitive calls to other objects such as PERFORM SUBROUTINE. With the current version of SPoD, this may lead to strange results when, in XRef Evaluation, trees are expanded and it is not possible to request case-sensitive calls with the filter dialog.

Debugger

It is currently not possible to reliably debug a Natural application using ETID-based statements like GET TRANSACTION DATA.

The reason is that the debugger is started in a separate NDV server background session which cannot use the same ETID as applied in the NDV development session. The debug session always is using a generated ETID which differs from the ETID used by the application.

Performance Considerations

Progress Information

The working situation displayed in the library workspace of Natural Studio is based on the representation of the entire user system files.

The tree view window opens when the user connects to the Natural Development Server. For this, the entire system file has to be analyzed and the corresponding information has to be transferred from the Natural Development Server to the Natural Studio client. In the case of very large system files, the build-up of the tree view window can be very time consuming. Status information displayed in the status bar keeps the user informed about the progress of the screen build-up operation. This is to avoid the impression that the connection to the Natural Development Server might be interrupted.

Tip:
Switch on the status bar using the View > Status Bar function of the menu bar. Make sure that the transfer rate of your network is 100 Mbit/s at minimum.

Filter Definition

Another possibility to reduce the amount of data read while mapping the environment is to supply filter definitions on system file or library level.

Tip:
In the context menu of a system file and library node it is possible to apply filter definitions. Using these definitions on the client side, you can limit the number of libraries/objects displayed in the tree view.

Refresh Options

In the default configuration of Natural Studio, all operations which result in a modification of the system file, for example, moving or copying objects, but also a SAVE or STOW command, will cause the tree view window contents to be refreshed, which can be a very time consuming process in the case of very large system files.

Tip:
By default, the Refresh function is set to Full automatic refresh. Change the automatic refresh function by choosing Optimized automatic refresh or No automatic refresh in the context menu.

Since the tree view of the application workspace displays only the objects that are linked to the application, the build-up of its tree view screen is consequently considerably faster, which is another advantage of using the application workspace.

Object Lists on Mainframes

In mainframe environments, libraries may contain a huge number of objects. Expanding such a library in a tree node in the NaturalONE Server view or in the Natural Studio views can take a long time.

Tip:
Install the hyperdescriptor as described in NaturalONE in a Nutshell > Performance Aspects in the NaturalONE documentation. The hyperdescriptor is also used by Natural Studio. It can significantly improve the database access required for reading object names the Natural system file.

Natural Documentation and Online Help

The following restrictions apply to the Natural documentation and the Windows-based online help when you are using a Natural Development Server (NDV) for remote development:

  • The online help currently available with Natural Studio contains only the Natural for Windows documentation and the SPoD client documentation.

  • Therefore this online help may describe Natural features which are not or not yet supported on the Linux platform.

  • Natural features that are available only on Linux are missing.

  • Particularly in the sections dealing with the Natural programming language, minor but important differences due to hardware platforms, operating systems, etc. may exist.

We ask you to refer to the Natural for Linux documentation set for full details.