PreviousUsing Projects Editing ProgramsNext"

Chapter 5: Workgrouping

This chapter describes how you can share resources with other programmers using Mainframe Express workgrouping facilities.

5.1 Overview

Application Workgrouping in Mainframe Express enables a team of programmers to share resources. A network server holds all the source files, load modules and other resources for an application. You only copy to your PC the individual files you need to work on. You can still run and debug the whole application using the shared files, with Mainframe Express automatically substituting any files stored on the local PC. This brings the following benefits:

Workgrouping enables you to share application files by storing them in libraries held on different levels. We recommend that you use the Production level for storing your production level sources and at least one Testing level for sources under development. When you build or run the application, Mainframe Express looks in the Testing levels first for source and executable files. If they are not in that library, it then searches the Production library. This has two advantages:

The diagram below illustrates the workgrouping model. It shows a workgroup with two PCs accessing application files from a server over the network. The server holds the Production level with all the source files for the application (accpay.cbl, accrec.cbl and custlist.cbl). PC A has a copy of accrec.cbl in its Testing 1 level. When PC A rebuilds or debugs the project, it sees its own local copy of accrec.cbl and the Production level sources for accpay.cbl and custlist.cbl. PC B sees its own local copy of accpay.cbl and Production level versions of accrec.cbl and custlist.cbl. The way Mainframe Express searches for files is explained in more detail in the section Concatenation and Searching.

workgroup example

Figure 5-1: Example of Workgroup Sharing Files

This chapter shows how you use a workgrouped project that has already been set up by your system administrator:

Detailed step-by-step instructions for individual tasks are in the online help, rather than in this chapter. Click Help Topics on the Mainframe Express Help menu then on the Contents tab click Development Environment, Using Workgroups, How to.

5.2 The Workgroup View

The Workgroup View of a project (selected by clicking the Workgroup tab on the Project View), displays the components of a project as a set of libraries, as shown below.

workgroup view

Figure 5-2: Workgroup View of a Project

The left-hand pane uses a tree view to display the elements of the workgroup. These elements are:

The numbers in brackets after each element show the total number of files it contains. An element can be selected by left clicking. A selected element is highlighted in inverse video. In Figure 5-2, folder <Project Folders>\SOURCE\ has been selected.

The right-hand pane lists the files contained within the currently-selected element. Although the columns displayed in this pane are the same as those displayed in the Files View, the kinds of files that are listed are different. The Workgroup View lists all versions (not just the active versions) of source files, data files, load modules such as intermediate (.int) and optimized (.gnt) code files, listing files, and so on, but it does not show copybook files that cannot be found on the search path. (For more information on the kinds of files shown in the Files View, see the section Files Details View in the chapter on The Mainframe Express Interface.)

As in the Project view, you can double-click on a source file to edit it. The title bar of the edit window contains the file path and, in the Workgroup view, the workgroup level is also shown, for example, d:\mfuser\projects\myproject\source\myfile.cbl [Testing #1].

5.2.1 Workgroup Levels

You can have up to ten levels in a project. When a new project is created, it contains a single level with the default name Production which you can use for storing production level sources. You can then create up to nine testing levels containing files under development. Testing levels are assigned default names Testing #1, Testing #2, and so on. You can rename any level.

When you build or run the application, Mainframe Express searches through the tree for source and executable files starting with the level at the top of the tree. If it does not find the files that it needs in any of the testing levels, it uses the files in the Production level.

Your system administrator sets up and maintains the Production level which stores files centrally so that they are accessible to everyone in the workgroup. You only need to copy the files you are working on to a testing level.

5.2.2 Libraries

Each level contains a number of libraries. They are for storing different categories of file. The different library types are described below:

Library Type
Description
Source Holds all the source files for the project
Dependency Holds other files referenced from the source files. These can include: Assembler copybooks, Assembler macros, control cards, COBOL copybooks, SQL include files, PROCLIBs.
Output Holds output of listings and log files
Load Holds executable files for the application. Mainframe Express creates these files when you compile programs or build the application.
External Holds files of types not explicitly used or recognized by Mainframe Express
Data Holds data files required by your application and not allocated through the system catalog. This includes IMS data files. You should only use the Data library for files not allocated through the system catalog.
Staging A Staging library is used as a staging area for files which have undergone development at one Testing level and are waiting to be moved to another Testing level or to Production level.

5.2.3 Library Folder Types

Each library contains one or more different types of folder. For example, the Source Library folder types can include All sources, COBOL, CLIST and JCL. Whenever you add a new library folder, you are prompted with a list of all the valid types for that particular library. For a full list of the different types of folder in each library, see the online help. Click Help Topics on the Mainframe Express Help menu. Then on the Contents page click Reference, Development Environment, Workgroup Libraries and Workgroup Library and Folder Types.

5.2.4 Library Folders

Each Library folder type contains one or more folders. A folder is either a directory on a PC or network server or a directory on a mainframe PDS accessed via SourceConnect. Load library folders are the only folders that cannot be located on the mainframe.

5.3 Using the Workgroup

Your system administrator is responsible for setting up a workgroup project and all the resources needed to work on the project. See the chapter Workgrouping in your Administrator's Guide for more information. You are given a copy of the project file for use on your PC and possibly other catalog and resource files, depending on how the administrator has set up the project.

It is also possible for an administrator to distribute projects by creating template projects which you can use to create your own copy of a project. You then select the required template from a list in the New Project Wizard. See the section Setting Up a Project in the chapter Workgrouping of your Administrator's Guide for more information.

Note that Mainframe Express allows any member of the workgroup to add, modify or delete files in any level or folder, including the files in the Production level. Therefore, the system administrator should assign network access rights so that members of the team only have write permission for their own working files and Staging folders at the Production level or at testing levels belonging to other members of the workgroup.

The Production level in the project you are given is populated with the files for the application you are going to work on. Copy the files that you want to edit to the Testing level. The Testing level is populated with a set of default folders, as well as any folders created by the system administrator to reflect the development model used by your organization. You can also add your own folders to any Testing level as needed - see the section Working with Folders for more information.

To use a workgrouped project:

  1. Open the copy of the project created by the system administrator and click the Workgroup tab to view the project

  2. When you want to work on a file, copy it from the Production level to the test level (Production and Testing #n are the default level names).

    You can copy a file by dragging it from the right-hand pane of the Project View and dropping it in the left-hand pane onto the folder where you want the copy located. To make this easier, if you drag a file over the + symbol next to an unexpanded part of the tree, it will automatically open. Also, if the tree occupies more than the full height of the pane, it will scroll if you drag to the top or bottom edges of the pane. You can only copy a file to the same type of library and folder. For example, a Production file in the JCL folder of the Source Library can only be copied to the JCL folder of the Source Library on the test level. Note, however that this has no effect for proclibs and control cards because they are catalogued PDSs, not PC files.

    Alternatively, you can right-click the folder where you want the files to be located, click Add Files and then use the Add Files To Project dialog box. The lower part of this dialog consists of a group of controls called Options. If you enable Copy into folder, then the file(s) specified in the top part of the dialog box are not just added to the project but are also copied to the specified folder.

    You can also remove files from any library folder at any level. Right-click the file or selected files in the right-hand pane and the Remove Files From Project dialog box appears. Click OK to confirm. This dialog box also offers you three options:

  3. The system catalog (catalog.dat) is distributed by the system administrator along with the project file or it can be shared between projects. It maps PC filenames to the mainframe data set names used by the application. If you need write access to shared data sets referenced in the catalog, you might need to copy these data sets to your own PC and to update the system catalog accordingly. Your system administrator should tell you whether this is a requirement or not.

    For detailed instructions on using the system catalog, see the online help. Click Help Topics on the Help menu then on the Contents tab click Development Environment, Emulating the Mainframe, Dataset Catalog, Catalog Functions, How to.

  4. Once you have copied source files down to the test level you can edit, compile, debug and test them. If you double click on a source filename, an edit window opens with a title bar that contains the pathname of the file followed by the name of the level in square brackets, for example, d:\mfuser\projects\gsdemo\source\cicsdl6.cbl [Testing #1].

  5. When you want to promote a file to the production library, copy it from your machine to the Staging library on the Production level. You can drag and drop a file from any test library to a folder in the Staging library. The system administrator can then copy the file back to the Production level. The Staging library gives the system administrator a way of controlling and coordinating changes. The system administrator determines which folders are in the Staging library and how they should be used.

    Your system administrator can also use Staging folders to coordinate and control the movement of files between the members of a workgroup. This can be done by assigning each member a Testing level. The folders within this level have access permission set so that other members of the workgroup can only write to the Staging folder. It is then the responsibility of the owner of each level, or the system administrator, to copy files from the Staging folder to the appropriate Testing folder.

5.4 Working with Folders

You can modify the workgroup tree at any time by right-clicking an element of the tree. A pop-up menu appears. Right-clicking levels gives a different pop-up menu to right-clicking types or folders.

5.4.1 Modifying Workgroup Levels

If you right-click the name of a level, you can:

You can change the order of the levels by dragging and dropping.

5.4.2 Modifying Workgroup Libraries

If you right-click the name of a library or a type, you can:

If you right-click the name of a folder, you can add files and folders (as described above for libraries and types). Also you can:

When you add a folder, its place in the tree depends on the currently selected item:

You can change the order of the folders within a library by dragging and dropping.

5.4.3 Workgroup Library Paths

Folders can have either an absolute path, specifying the exact location on a PC or the network, or a path relative to the project file. Relative paths are always displayed as starting <ProjectFolder>.

For example <ProjectFolder>\source\ is a subfolder of the project file folder, called source. When you set up a folder, you can specify relative paths by typing either <ProjectFolder> or .\.

The IDE classifies folders into different types according to what is stored in them. For example, Source Library folder classifications include CLIST, COBOL and JCL. When you add a new folder, you are presented with a list of all the appropriate types for the library to which you are adding the folder. For a full list of the different types of library, see the online help. Click Help Topics on the Help menu then on the Contents page click Reference, Development Environment, Workgroup Libraries, Workgroup Library and Folder Types.

5.4.4 Concatenation and Searching

When you add new levels and folders to a project, you are setting up a concatenated path down which Mainframe Express searches whenever it needs to locate files in the project. As soon as a file is found, the search stops. You can add multiple folders of the same type to a library, each with a different location, if you want to work with different versions of the same file. You can exclude a folder from the search path by unchecking the check box to the left of the folder name. The folder that is currently in use for output by the project (because it is enabled and because it is the highest folder of its type in the tree) has a blue check box.

You can include or remove any level or folder in the project from the concatenated search path. Levels and folders have a check box before their names. The check box status has the following meanings:

There is one exception to the above: control cards. Mainframe Express does not maintain a concatenated search path for them.

Folders are always searched starting from the top of the list to the bottom. If a file is not found in the first test level, Mainframe Express searches for it in the next test level and finally in the Production level. Disabled levels and folders are skipped. The example folder structure below is simplified to show only the COBOL folders for the Source libraries in a Testing #1 level and the Production level:

Example of workgroup concatenated search

Figure 5-5: Concatenated Source Folders

Whenever you build the project shown in Figure 5-5, Mainframe Express searches for source files starting with <ProjectFolder>\version1\, as this is the first folder in the Testing #1 Source library. It then looks in <ProjectFolder>\. Finally it looks in the Production Source library g:\payroll\source\. In this example, Mainframe Express skips <ProjectFolder>\version2\ as it has been deselected (there is no checkmark in the check box).

Under each type of library, you can also have a folder type of All, for example All Sources and All Load Modules. These are special folder types and are searched only after any specific folder types. This enables you to use the All folder type as a general purpose library. The next example is a simplified view of a set of Load libraries at the Testing #1 and Production levels.

Mainframe Express searches folders for COBOL loadable modules in this order:



Figure 5-6: Concatenated COBOL Load Library Folders

In the case of IMS loadable modules, Mainframe Express searches in this order:

IMS load sequence

Figure 5-7: Concatenated IMS Load Library Folders

You can change the order of the folders by dragging and dropping.

5.4.5 Load Libraries

When you compile any programs in your application, the loadable modules are always written to the first available load library folder of the appropriate type. This happens regardless of the location of the source file. If you recompile a source file stored at the Production level, the loadable module generated by the compiler is written into a load library at the highest checked level (where the check is blue).

For example, in the Workgroup View example shown in Figure 5-6 above, when you compile the COBOL program, the loadable module would be written to <ProjectFolder>\coblib1\ regardless of the location of the source file, provided that the folder is checked Checked black image. But if <ProjectFolder>\coblib1\ were unchecked Unchecked image, Mainframe Express would be forced to write the loadable module to <ProjectFolder>\coblib2\.

When you rebuild a project, Mainframe Express follows a set of rules to determine which files need rebuilding and where to build them. For each file in the project:

  1. Mainframe Express searches the Source library folders until it finds the first occurrence of the file

  2. It searches the Load library folders until it finds the first occurrence of a loadable module corresponding to the source file

  3. It carries out the following checks to decide whether to rebuild the file:

    1. Is the timestamp of the source file the same as the timestamp it had when it was last compiled?

    2. Is the timestamp of each of the dependencies the same as the timestamp had when it the source file was last compiled?

    3. Are all of the dependencies present?

    4. Is the most recent timestamp of the timestamps of all the outputs of a compile of the file the same as the timestamp of the file when it was last compiled?

      The timestamp is the date and time of the file on disk.

    If any of these checks fail, Mainframe Express rebuilds the loadable module. Mainframe Express writes the newly created loadable module to the first available Load library folder of the appropriate type.

    When Mainframe Express checks the source file dependencies it also follows a similar search path down all the appropriate Dependency library folders.

A blue check box indicates that this folder at this level is where the loadable modules are written if you build the project. If you see a black check box where you expect to see a blue one, look in load libraries at higher levels for blue check boxes and uncheck them.

A gray check box indicates that this folder is where the loadable modules would be written if the level were enabled. If you see a gray check box where you expect to see a blue one, change the level check boxes.


Copyright © 1999 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.

PreviousUsing Projects Editing ProgramsNext"