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:
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.
The following topics are covered:
If a back-end program has been specified (for
example, by means of the Natural profile parameter
PROGRAM), it is not invoked if the Natural session is
executing on a Natural Development Server.
The Natural Development Server for BS2000 does not support the
REQUEST DOCUMENT statement.
The following topics are covered:
The system command SYSDDM is not available,
since the DDMs are listed in the tree view under the node DDM, and because all
functions of the utility SYSDDM are available by using Natural
Studio's context menu or menu bar.
The following system commands are not available, since their use would make no sense with a graphical user interface:
EDT
HELLO
MAINMENU
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.
It is even possible to invoke the mainframe editors. However, this may lead to inconsistencies (see also Object Locking in the Natural for Windows documentation). Therefore, you are strongly recommended to use only Natural Studio's GUI editors.
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.
The Natural profile parameter setting CP=AUTO is not
supported in a SPoD environment. (AUTO means that the
code page name from the user terminal is taken, if available.)
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 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.
In contrast with a pure Natural mainframe environment, that is, without
remote development from Natural Studio, the command EDIT
DDM is available also from a user library. This means that it is
not necessary to expand the DDM node in the tree view to be able to edit a
specific DDM. However, when Natural Security is used, the use of the commands
LIST DDM and EDIT DDM can
be restricted only via the security profile of the mainframe Natural utility
SYSDDM.
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.
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.
On the mainframe, objects of type resource can be handled (displayed, copied, deleted, etc.). See Using Non-Natural Files - Resources in the Natural Programming Guide.
By default, resouces are not handled by Natural Development Server for performance reasons; that is, resources are normally not displayed.
If you want Natural Development Server to handle resources, use the
user exit NDV-UX03 (source: NDV-SX03), which allows
you to enable/disable the display of resources in Natural Studio for all or
certain users only.
The server behaves in the following way: If the user exit exists and
the flag DISPLAY-RESOURCES contained therein is set
(Y), the server checks in the Library Statistical Record whether
the number of resources is greater than 0. If so, the library is searched also
for resources.
Dialogs can be stored on the mainframe. Therefore it is possible to move or copy dialogs from the local environment to a remote environment. Private resource files of a dialog will not be moved or copied together with the dialog. It is also possible to list dialogs in a remote environment. New dialogs cannot be created and dialogs cannot be edited in a remote environment.
As the object types Natural ISPF Macro and Recording available with Natural for Mainframes cannot be processed by Natural Studio, they will not be displayed in the tree view of the library work space. If a library consists only of such object types, the library will be displayed nevertheless in the tree view, but without any subnodes.
If a library containing such object types is deleted, then the objects of these two specific object types will not be deleted and the library will continue to be displayed in the tree view.
Objects of the types Natural ISPF Macro and Natural ISPF Recording cannot be linked to an application.
The restricted libraries SYSLIB/SYSLIBS of
the server are not shown in Natural Studio's tree view, because a logon to
these libraries is not possible. These libraries can be modified only by using
a Natural utility such as SYSMAIN or the Object Handler.
Natural Studio's program editor is case-sensitive, that is, lower case
input will be included in the program source in lower case. The compiler on the
Natural Development Server, however, expects upper case code in its normal
setting. This issue can be fixed by setting the compiler option
LOWSRCE=ON. But this setting will have specific side
effects which should be noticed. Refer to the CMPO
profile parameter in the Natural Parameter Reference.
The terminal emulation supports 3270 Model 2 screens. The support of 3270 Model 3, 4 and 5 screens is planned for one of the next versions of Natural Single Point of Development.
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.
When the remote debugging facility was implemented, the goal was not to provide any new functions, but to support the existing essential debugging functions under the Natural Development Server. These functions are:
Stepmode
Breakpoints
Watchpoints
Display and modification of variables and their contents during a break.
Generally, it was intended to provide for compatibility between the debug functionality that exists in a Natural on mainframes and a Natural on PC. Hence, the current state of development constitutes the lowest possible common denominator. Especially the debug statistics as supported on mainframes are not yet supported in a remote debug environment.
The following tables provide an overview of differences that exist between Natural debugging in a mainframe environment and debugging in Natural Studio.
Explanation of the table headings:
| MF | Describes debugging functionality available or not available in a mainframe Natural environment. |
|---|---|
| SPoD | Describes debugging functionality available or not available in a Natural Single Point of Development environment using Natural Studio as a development client and a mainframe Natural Development Server. |
| PC | Describes debugging functionality available or not available in Natural Studio (stand alone). |
| MF | The restart function is not supported. |
|---|---|
| SPoD | The restart function is not supported. |
| PC | Debug on PC offers a special restart function which is not available for remote debugging on mainframe. |
| MF | System command RUN: leave the
Natural Debugger. The program execution continues.
|
|---|---|
System command
STOP: both debugging and execution are
terminated.
|
|
| SPoD | Stop command in Debug menu: debug mode terminates, program execution stops. |
| PC | Stop command in Debug menu: debug mode terminates, program execution stops. |
| MF | Syntax of STEP SKIPSUBLEVEL is used instead of
STEP OVER.
|
|---|---|
| SPoD | STEP OVER is applicable for called objects on a
different level (CALLNAT, etc). It is not applicable for internal
subroutines.
|
| PC | STEP OVER is supported for any called objects
and, in addition, for internal subroutines.
|
| MF | Not applicable. |
|---|---|
| SPoD | Not supported. |
| PC | Supported. Allows you to continue the execution at a chosen line. |
| MF | System variables can be displayed, but cannot be modified. |
|---|---|
| SPoD | System variables can be displayed, but cannot be modified. |
| PC | System variables can be displayed and modified. |
| MF | Either alphanumeric or hexadecimal display of binary variables can be selected. In alphanumeric display, binary variables with lengths ranging from 1 to 4 are interpreted and displayed as numerical values. Binary variables with lengths > 4 are displayed in alphanumeric representation. |
|---|---|
| SPoD | Binary variables are always represented as hexadecimal values. |
| PC | Binary variables are always represented as hexadecimal values. |
| MF | During the debug process, the content of a dynamic variable can be modified in the given length. Modification of length of dynamic variable during debug is not supported. |
|---|---|
| SPoD | Content of dynamic variable can be modified in given length. |
| PC | Both content and length of dynamic variable can be modified during the debug process. |
| MF | Displays full content of variable; long variables are displayed in chunks of maximally 256 bytes. If Unicode is used: max. 256 bytes = 128 characters. |
|---|---|
| SPoD | Displays maximally 253 bytes. If Unicode is used: max. 252 bytes = 126 characters. |
| PC | Displays maximally 253 characters. |
| MF | Maximally 253 bytes. If Unicode is used: max. 252 bytes = 126 characters. |
|---|---|
| SPoD | Maximally 253 bytes. If Unicode is used: max. 252 bytes = 126 characters. |
| PC | Maximally 253 characters. |
| MF | After the watchpoint has been registered, the Debugger marks the preceding (already executed) statement. |
|---|---|
| SPoD | After the watchpoint has been registered, the Debugger stops at the current position in the program. This is the statement to be executed next. |
| PC | After the watchpoint has been registered, the Debugger stops at the current position in the program. This is the statement to be executed next. |
| MF | Multiple breaks on the same line may arise for the same watchpoint variable (because of different watchpoint operators). The hit counter is incremented accordingly. |
|---|---|
| SPoD | Multiple breaks on the same line may arise for the same watchpoint variable (because of different watchpoint operators). The hit counter is incremented accordingly. |
| PC | Several watchpoint definitions for the same variable result in a maximum of one break per line, hit counts of all watchpoint definitions are incremented. |
| MF | Breakpoints can only be defined for programs which are found in the current library or in any steplib. |
|---|---|
| SPoD | Breakpoints can only be defined for programs which are found in the current library or in any steplib. |
| PC | Breakpoints for programs can be defined in any library (not necessarily in the current library or steplib). |
| MF | The symbolic breakpoints BEG and
END (first and last executed statement) are supported.
|
|---|---|
| SPoD | Breakpoints BP-BEG and BP-END are
not supported.
|
| PC | Breakpoints BP-BEG and BP-END are
not supported.
|
| MF | Stacked programs can be debugged when any breakpoint or watchpoint has been defined, but they cannot be entered automatically in step mode. |
|---|---|
| SPoD | Programs on stack can be entered in step mode. |
| PC | Programs on stack can be entered in step mode. |
| MF | A NAT0932 (program version) error appears if during the debug process the debugged program was stowed and loaded into the buffer pool. |
|---|---|
| SPoD | A NAT0932 (program version) error appears if during the debug process the debugged program was stowed and loaded into the buffer pool. |
| PC | Change and stow of program during debug is possible. |
| MF | The debug command OBJCHAIN
displays a list of active programs and their levels.
|
|---|---|
| SPoD | The current program and its level are displayed in the call stack window. |
| PC | All active programs and their levels are displayed in the call stack window. |
The following restrictions apply when you are using a Natural Development Server (NDV) in a SMARTS server runtime environment on BS2000.
This add-on product cannot be used.
The Natural remote job entry facility NATRJE is not
currently supported.
3GL programs that are to be called by Natural must have the following characteristics:
They must be fully reentrant since they are loaded as shared code into a common memory pool.
They may not invoke any system function such as request memory or file IO, because they are running in a multitasking environment where every communication with the Natural Studio front-end can cause a task change similar to UTM.
AMODE 24 is not supported. Any attempt to load an AMODE 24 subroutine will end up with a GETMAIN error.
CRTE is not supported.
The Natural profile parameter DELETE is not
evaluated; that is, a 3GL program that has been loaded cannot be unloaded.
The Natural profile and session parameter MT
(Maximum CPU Time) cannot be used to limit the time consumption.
The Natural profile parameter LIBNAM (Name of
External Program Load Library) is not supported.
The Natural system variables
*INIT-PROGRAM,
*HARDWARE and *OSVERS
are not supported.
Only one NDV server can be started per SMARTS server instance.
Currently, only terminal type 3270 is supported.
Support of a Natural shared nucleus is not possible. That is, NDV under SMARTS on BS2000 cannot share one nucleus with Natural under TIAM, UTM, or in batch mode.
The usage of global bufferpools is not possible with NDV under SMARTS on BS2000, because NDV is not able to share bufferpools with Natural under TIAM, UTM, or in batch mode.
Since no editor work file access method is currently available for SMARTS on BS2000, the Software AG editor has to run without a buffer pool.
For this purpose, the profile parameter EDPSIZE
(described in the Natural Parameter Reference) is provided
where you can specify the size of an auxiliary editor buffer pool. All editor
data are kept in the user storage thread. The total editor work space per user
is limited by the EDPSIZE parameter. No editor work file
is required. The recover mechanism of the Software AG Editor is not
supported.
The EntireX Broker Stub BROKER must be used.
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 function of the menu bar. Make sure that the transfer rate of
your network is 100 Mbit/s at minimum.
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.
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
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.
In a Natural Single Point of Development environment, either local Natural libraries are accessed or Natural Studio requests the library statistical data from the remote development server. In the local environment, the data are stored persistently in the FILEDIR structure of the library. In the case of a mainframe development server, Natural objects are stored in system files in the database and the requested statistical data of a library are not stored permanently.
In order to reduce the number of Adabas calls and to improve the performance, a statistical record has been introduced.
The program NDVCSTAR is provided to initialize a complete
system file, a range of libraries or a single library on a system file with the
Library Statistical Records, see
Initialization of Library
Statistical Records.
The following topics are covered below:
In a Natural Single Point of Development environment, a library
statistical record is created and maintained for every library of the
FUSER or FNAT system file. This statistical record
resides on the same system file where the library resides and contains the
following information for every library:
Total number of objects
Total number of all sources
Total number of all cataloged objects
Total number of objects for every object type
Accumulated size of all sources
Accumulated size of all cataloged objects
Accumulated size of sources for every object type
Accumulated size of all cataloged objects for every object type
Supported object types:
Program
Map
GDA
LDA
PDA
Subroutine
Helproutine
Subprogram
Copycode (source only)
Text (source only)
Command Processor
Dialog (source only)
Class
Error Message (source only)
Function
Adapter
Resource
When Natural Studio requests the statistics for a library the first time, the library statistical record is created and saved in the appropriate system file. Once the library statistical record has been built, all requests from Natural Studio will be satisfied by reading and sending the contents of the statistical record instead of rebuilding the complete library statistics.
When the user initiates an explicit refresh for a library, the statistical record is rebuilt completely.
The library statistical record of a mainframe development server is supported only in a Single Point of Development environment. The statistical record is always up to date if all system file modifications are initiated in this environment.
All commands or operations triggered by Natural Studio which will modify the system files (add new object or copy, move, delete, rename object, etc.) will update the library statistical record on the development server.
In addition, the library statistical record is regenerated if an object list for the whole library is requested or the statistical record for a given object type is updated if an object list for this type is requested.
To ensure consistency of the data in the library statistical records
of your FNAT and FUSER system files, you are strongly
recommended to make changes on the same FNAT and
FUSER system file used in a Single Point of Development
environment exclusively in that environment.
 |
Warning: When working with Natural Studio, care must be taken to start all commands or utilities from within Natural Studio. It is not admissible to issue system commands in the terminal emulation window, for example, at a MORE prompt or in a command line. In such a case, the library
statistical data might become inconsistent. The same is true if you start a
server application that directly changes the FNAT or
FUSER system file. |
Such inconsistencies may be resolved after the next regeneration (implicit rebuild via get object list or explicit refresh) of the library statistical record is forced.
Statistical records cannot be used for read-only system files. In this case, the old behavior is used.
In order to initialize the Library Statistical Records of a a complete
system file, a range of libraries or a single library on a system file you can
invoke the program NDVCSTAR.
The following options are provided:
| Option | Meaning | Default value | |
|---|---|---|---|
Library name
range |
Possible values: | * |
|
blank or * (asterisk)
|
All libraries. | ||
value>
|
All libraries with names greater than or equal
to value.
|
||
value<
|
All libraries with names less than or equal to value. | ||
DBID, FNR |
The database ID (DBID) and file
number (FNR) of the system file where the Natural libraries are stored. If no
values (or 0) are specified, the current FUSER or
FNAT system file is used.
|
0,0 |
|
Password, Cipher |
The password and cipher code of the Adabas file where the Natural libraries are stored. | None | |
Update existing
records |
Specifies whether existing Library Statistical Records are to be processed. Possible values: | N |
|
Y (yes)
|
Regenerate existing Library Statistical Records. | ||
N (no)
|
Skip existing Library Statistical Records. | ||
Display library
names |
Specifies whether a processing message of the library currently processed is to be displayed. Possible values: | 1 |
|
Y (yes)
|
Display processing messages. | ||
N (no)
|
Display only error messages. | ||
To invoke the program NDVCSTAR
At a NEXT/MORE prompt or in a Natural
command line, enter NDVCSTAR and press ENTER.
To execute the program NDVCSTAR in batch mode
Enter NDVCSTAR followed by the desired options.
Examples:
NDVCSTAR *,1,47,,,N,Y
On the system file with DB=D=1, FNR=47,
this command creates, for all libraries that do not yet have a Library
Statistical Record, a new one. Any existing library statistical records are
skipped. For every library found, a processing message is
displayed.
NDVCSTAR ABC*,,,,,Y,Y
This command creates or regenerates the library statistical record
on the current FUSER system file for all libraries that start with
ABC. For every library found, a processing message is displayed.
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 mainframe platform.
Natural features that are available only on mainframes are missing.
Particularly in the sections dealing with the Natural programming language, minor but important differences due to hardware platforms, operating systems, TP monitors, etc. may exist.
We ask you to refer to the Natural for Mainframes documentation set for full details.