Working in a Team

This document covers the following topics:


Key Requirement: A Versioning Tool

The major advantage of NaturalONE is that it supports out-of-the-box development in a team. Using the local mode, several developers may work on the same application at the same time. They do not interfere each other because each developer has his own workspace. But how do you synchronize the work of each developer? A versioning tool is required for this purpose. The versioning tool allows you to check out a project into the workspace, work on the project, and merge the changes back into the versioning repository. Team support is based on such versioning tools. It is key. Without a versioning tool, it is almost impossible to work with many developers synchronously on one and the same application at the same time.

Examples of versioning tools that are easy to use in Eclipse are CVS, Subversion (SVN) and GIT. Eclipse supports versioning tools via the Team menu and support for CVS is already built in. See also Using a Version Control System in the Introduction.

You must also set up a team repository server which stores the versioned items. For more information, see the documentation of your preferred versioning system.

Private-mode Libraries

The versioning tool solves the problem of synchronizing several developers when working on the Natural source. But what about the cataloged objects (also called "generated programs" or "GPs")?

Just to remind you: The application was downloaded from specific libraries in the Natural environment into the workspace (either into a new project or an existing project, depending on the command that was used in the Natural Server view). The same libraries as in the Natural environment are also used in the workspace. When an application in the workspace is built, the sources are cataloged in the Natural environment, in the same libraries as in the workspace. If many developers are working on the same library, it is possible that one developer overwrites (recatalogs) the changes made by another developer. You avoid this problem by switching on "private mode" in the properties of the Natural project. What does this mean?

Let us assume the following:

Two developers are working on the same application which is mapped to a Natural server environment (very similar to the local Natural runtime of NaturalONE). Each developer is changing the application in his own workspace. For testing purposes, each developer builds the project on the server. The Natural builder always checks whether a so-called "private-mode library" for a developer exists on the server (that is, whether there is a separate library for each developer). The naming convention for such a private-mode library can be defined in the Natural preferences. When private mode has been switched on, the source is cataloged in the private-mode library. When a developer invokes the Execute command for a source in the workspace, the builder ensures that the appropriate cataloged object is executed on the Natural server. Thus, both developers may test their changes without interfering each other. In a Natural Security environment, the private-mode library inherits the same credentials as the original library by default. There is no need for a system administrator to define this private-mode library in Natural Security. However, the administrator can set so-called "development mode options" in Natural Security. These options determine how Natural Security controls the use of Natural server actions triggered by Project Explorer view actions. For detailed information, see Protecting the Natural Development Environment in Eclipse in the Natural Security documentation, which is part of the Natural documentation.

Note:
The private-mode libraries are created automatically when building projects in private mode. It is not possible to change a private-mode library in the Natural Server view, and it is not possible to change any object in a private-mode library (for example, it is not possible to edit such an object). The corresponding commands in the context menu are unavailable (gray). For further information, see the description for Private Mode in Changing the Project Properties.

When all tests have been completed, each developer has to merge his changes into the versioning repository. Based on the final repository contents, the application has to be deployed to the Natural server. NaturalONE provides a deployment tool for this purpose. As a result of merging the changes, each developer has the same revision of the application in his own workspace (after an update from the repository). And, via deployment, the related cataloged objects are now available on the Natural server. By default, the objects are deployed to the application libraries, not to the private-mode libraries.

Experience shows that about 60 to 70 percent of changes on an existing application can be merged to some extent automatically, without user interaction. The remaining portion of merging the sources has to be done by the developer manually, but the versioning tools provide functionality which supports manual merging of sources.

Using Private-mode Libraries in Batch

When you execute a Natural batch application in private mode, the batch Natural must be aware of the library search order (LSO) used for the private mode application execution. This information is kept in a specifically designed Natural member, the so-called LSO member. The LSO member is saved in a special private mode library, referred to as LSO container library.

The following steps need to be performed:

  • Generate the LSO (library search order) container library (optional)
    If any private-mode library has been created for the project, the Natural node of the project properties offers a button to generate the LSO container library. After the LSO container library has been created, its name is displayed. This name is required for the private-mode batch execution. For further information, see Natural in Changing the Project Properties.

  • Save the private-mode library search order
    In the context menu of the project select NaturalONE > Save Private-mode Library Search Order. This saves the current private-mode library search order into the LSO member. If the LSO container library has not yet been generated, it is automatically created and its name can be found in the project properties as described above.

  • Modify the batch command input
    Enter the following system command as first input into the primary command input data set CMSYNIN of your Natural batch application:

    SYSLSO LSO-container-library

    Where LSO-container-library is the name of the LSO container library generated before.

Notes:

  1. Whenever the private-mode library search order has changed, the private-mode library search order has to be saved again so that the batch Natural finds the correct content. The private-mode library search order changes for example when a new private-mode library is added or if you change the steplibs. In general, you are recommended to save the private-mode library search order right before you execute the batch application.
  2. The LSO member is a Natural text member named 0LSO in the LSO container library. You may list its content to see how the library search order is currently set. But you should not modify it because in this case it will no longer be usable.
  3. NaturalONE offers a function to delete an LSO container library. For further information, see Natural in Changing the Project Properties.
  4. As a system administrator, you do not have to define the LSO container library in Natural Security. For detailed information, see Protecting the Natural Development Environment in Eclipse in the Natural Security documentation, which is part of the Natural documentation.
  5. When the SYSLSO command is executed in an NSC environment, the steplib settings in the logon library must match the entries in the 0LSO member. Otherwise, the SYSLSO command will fail.

Separating Natural Projects into Logical Parts

Referencing of projects is a good way to separate logical parts of an application. For example, you can define a project which contains just the DDM and data area sources. Assuming that these sources are not changed very often in an existing application, the separation gives the development team a better overview of the different parts of the application. Each developer can just use his own parts in a project and does not need to store these common parts in his own project.

Referencing of projects requires that the steplib chain is set accordingly.

Keeping the Development Environments Separate

There is always a 1:1 relationship between an Eclipse instance and a workspace. It is not possible to share one workspace among different Eclipse instances. This concept ensures that one developer is not disturbed by the work of any other developer. NaturalONE also follows this concept. If you look at your workspace on disc, you will see a directory named .naturalone. Within this directory, you will find the fuser directory which contains all Natural objects of the local runtime.

In the NaturalONE context, fuser is the root directory entry for the Natural environment. "FUSER" is a Natural term which stands for "Natural system file for user programs". On UNIX, Linux, Windows and OpenVMS platforms, the FUSER is located on disc. On mainframes, the FUSER is located in a database called Adabas. This is the reason why it is called a system file.

Having the FUSER located in your own workspace supports the idea of separating the development environments (that is, the workspaces in the Eclipse world). If you make use of a Natural server, you should work in private mode (see above). This also ensures that the development works of different developers are kept in separate places.

Storing the Project Settings

As mentioned earlier, NaturalONE keeps the Natural parameters that are used in the Natural environment also locally in the workspace. This ensures that the Eclipse environment and the Natural environment are configured identically. When the project on which you are working has been checked out from a versioning repository, you will also get the parameter settings for this application from the repository (provided that the corresponding files have been checked in). You can imagine that it would be dangerous to commit your own parameter changes to the repository (for example, if you change the DC parameter for some testing reasons) and then make them available for the entire development group, where no one knows (and does not expect) that, for example, DC has been changed.

To circumvent this issue, NaturalONE makes use of the temporary store of Eclipse. You may change any Natural parameter settings locally in your workspace. By default, they are not committed to the versioning repository with the changed Natural sources. After you have tested the changed parameter settings and they work fine, you have to make your parameter settings globally available. To do so, invoke the project properties, select Natural in the tree of the resulting dialog box, and then choose the Store new Defaults button. The next time you commit source changes to the repository, the changed parameter settings are also stored in the repository.

If you are working with a Natural environment, the locally stored parameters are used to configure the Natural environment (see also Application Parameters in the Project Properties).