Chapter 8: Using Workgrouping

Use workgrouping to share files on a network and to separate development versions from those already in production use.


You need to have read the chapter Start Here for the Tutorials and worked through the first session, Using Mainframe Express, before you do this session.


8.1 Overview

The term workgrouping refers to a method of working. Your projects can include files on other PCs on your network, and even on a mainframe if your site uses SourceConnect (see the chapter Accessing Mainframe Files). PC networking facilities enable you to assign drive letters (for example, z:) to disk areas on a remote PC. SourceConnect enables you to assign drive letters to PDSs on a mainframe. Using the letters you assign, you can treat these areas exactly like drives on your own PC. In creating, building and using a project, you treat remote files just like local files.

A large application might consist of a great many files maintained on a network server or mainframe by your system administrator, who will probably create a project including all these files. On your own PC, you have a project referencing just such of these files as you are responsible for. You might create this project yourself, or your system administrator might create it for you.

The facilities for workgrouping in Mainframe Express enable you to take local working copies of just those files you are working on. The production versions of those files remain accessible from your project, but when you access a file - for example to edit or build - you get your working copy. For any file that doesn't have a working copy, you get the production version. Thus when you build your development version of the application, for example to test it, all the work of ensuring the unchanged files are available to the build is done for you.

Your working copies (generally called development versions) of the files are contained in the Testing levels of your project, and the production versions are called the Production level. There can be up to 9 testing levels. They can be given any name but, by default, they are given the names Testing #1 to Testing #9.

This session demonstrates the use of levels. For convenience, we have both the production system and the development version on your own PC. You use the same demo application as you used in the chapter Using Mainframe Express

8.2 Preparation

This demo uses the project idedemo.mvp that you created and built in the chapter Using Mainframe Express.

  1. If you have closed Mainframe Express, open it as before. Close any project windows and any other windows that are open.

  2. Open the project idedemo.mvp in any of the ways described in the chapter Start Here for the Tutorials.

    The full path is \mfuser\projects\gsdemo\idedemo\idedemo.mvp. If you use Open on the File menu, you need the Files of Type field on the Open dialog box set to Project files (*.mvp) to see this file.

8.3 Sample Session

In this session you:

8.3.1 Using the Workgroup View

In the chapter Using Mainframe Express we saw how the tabs at the bottom of the project window give you different views on the project. We used the Files View and the Catalog View. We'll now use a third view.

  1. Click the Workgroup tab at the bottom of the project view.

    The Workgroup View has, in the left-hand pane, a tree view showing the different types of libraries that a project can have. The left-hand pane should look like the figure below. If it contains only a single line 'Production', click on the "+" to expand it.

    Production level

    Figure 8-1: Workgroup view left-hand pane

    A library means a set of files of a particular type. These types are indicated by the files' extensions.

    The number in parentheses alongside an entry shows the number of files this project has in libraries of that type. If there is no number, there are no entries.

    Only files that have been added to your project (either explicitly or during parsing) are included. Your project folder and the folders containing the files of your application will generally contain working files and object files created by Mainframe Express during building, and you could even keep there files that have nothing to do with your application, if you wanted to. None of these are included.

    The check box indicates that the files in these folders can be used to build the project.

  2. Click the "+" alongside Source Libraries.

    Source library types

    Figure 8-2: Workgroup source library folder types

    The tree view expands, and you can see that each type is itself divided into types. The possible types of source library are CLIST library, COBOL library, and JCL library. Notice the entry CLIST - unlike in the Files View, every possible type is shown, including those that have no members.

  3. Click the "+" alongside COBOL.

    COBOL folders

    Figure 8-3: Workgroup source library COBOL folders

    The tree view expands to show the final level of entry. These are pointers to folders containing files of that type. Our Idedemo project has only one folder that contains .cbl files. The pointer gives the folder's path, relative to the project folder. The checkbox indicates that the files in this folder can be used in building the project. If you move the cursor over the folder, a tool-tip prompt is displayed showing the full path of the folder, a description and the number of files in the folder.

    The first item in this tree view represents the whole project and is called Production. This default name reflects the fact that this is the original set of files in this project, and is assumed to be the set now in production use.

8.3.2 Creating a Working Folder

We will suppose the application you created and built in \mfuser\projects\gsdemo\idedemo in the chapter Using Mainframe Express is now the production version. You now want to work on an update to this application.

You need to create a new folder where you can work on your development version.

  1. Create folder workdemo within \mfuser\projects\gsdemo.

    If you need help on creating folders, see the appendix Windows Tips.

  2. Create folder source within workdemo.

8.3.3 Creating a Working Level

You now create the new level, where you will work on the files you want to update:

  1. Right-click Production, then click Add Level on the popup menu.

    A message appears telling you that relative paths in the Production level must be converted to absolute paths, and asking if you want it done now. This message only appears the first time you create a testing level.

    Notice that all the paths shown in the Workgroup View begin with <ProjectFolder> - for example <ProjectFolder>\source means the folder source within the project folder. This is a relative path. Converting it to an absolute path inserts the name of the project folder, so in this example the path becomes d:\mfuser\projects\gsdemo\idedemo\source, where d: is the drive containing \mfuser.

    The reason for this message is that often the production application is on a network server, and your project (.mvp) file was created for that server by an administrator. When you take on the task of updating the application, you copy the project file to your own machine. To ensure that the paths still point to the correct place on the server from your machine, the administrator needs to change the relative paths to absolute before you take your copy. (The administrator may also impose some standards about network drive assignments.)

    You must change the paths to absolute before you can add a new level.

  2. Click Yes.

    The Add Level dialog box appears. This is where you specify where you will keep your development versions of the files in the project. The paths of all the libraries have been initialized to those of your Production libraries - you need to change these paths to the paths of your development, or "Testing #n" libraries. We want to make two changes to these defaults:

  3. Leave the default name Testing #1 unchanged, and delete the words <ProjectFolder>\source\ from the Source Library field, leaving it blank.

    The words <ProjectFolder> also disappear from the other fields.

  4. In all the fields except Source Library, insert d:\mfuser\projects\gsdemo\workdemo\ before what is already there.

    where d: is the drive containing \mfuser. (You can type in one field and then cut-and-paste - see the appendix Windows Tips if you need help.)

    Add level dialog

    Figure 8-4: Add level dialog

    After you have completed these entries, the dialog box should look similar to Figure 8-4. For example, Dependency Library now contains d: \mfuser\projects\gsdemo\workdemo\copylib. Since the fields are not long enough to show the complete paths, the positioning of a path within its field may not be exactly as shown here.

    In the following, we'll generally omit d: from these paths unless necessary for clarity.

  5. Click OK.

    Level 1 added

    Figure 8-5: Workgroup view with Testing #1 level added

    The tree view contracts, and a set of entries is added for the libraries you just specified. The left-hand pane should look like Figure 8-8.5. The name Testing #1 reflects the fact that this is where you will put your development versions of the files. There are no numbers in parentheses because no libraries contain any files yet.

    Note that this does not create these folders or copy any files there. It just creates this set of pointers showing that these libraries will be in these folders.

    Before going on, let's see how the paths look now.

  6. In the Production level, click the "+" by Production, then the "+" by Source Libraries, then the "+" by COBOL.

    You see that the relative path has changed to an absolute one, as you requested a few steps back.

  7. Click the "-" signs by COBOL, Source Libraries and Production to collapse the tree again (this is not strictly necessary, but keeps the left hand pane uncluttered).

8.3.4 Adding Libraries

We decided not to create the source library offered by the Add Level dialog box. It would create a library called All Source within Source Libraries, where you could put the development versions of all your source files. However, it's often more convenient to have an exact copy of the structure under the Production level, and that's what we'll create:

  1. Right-click Source Libraries within Testing #1, and click Add Source Folder on the popup menu.

    The Add Folder dialog box appears. You now add details of the folder where you will keep your development versions of your COBOL source files.

  2. Enter the following, and click OK:
    Type COBOL
    Location Type Folder
    Location d: \mfuser\projects\gsdemo\workdemo\source
    Description COBOL source

  3. Again, right-click Source Libraries within Testing #1, and use Add Source Folder to add the following:
    Type JCL
    Location Type Folder
    Location d: \mfuser\projects\gsdemo\workdemo\source
    Description JCL source

    We've decided to keep both our COBOL and JCL sources in folder source within workdemo, just as they were in source within idedemo. They will still constitute different libraries, because a library is a set of files of the same type in the same folder.

Library folders added

Figure 8-6: Workgroup view showing the JCL folder type in Testing #1

If you expand the Source libraries and JCL library folder type and move the cursor on to the folder, the workgroup view should look like Figure 8-8.6. Note that there are still no files contained in the Testing #1 level, as shown by the zeroes after each library. You will add the files next.

8.3.5 Adding Files to the Working Level

You've now created two libraries in the Testing #1 level - a COBOL library and a JCL library. Next you put working copies of your COBOL and JCL files into these libraries.

  1. Click the "-" before JCL, Source libraries and Testing #1 so that all three levels are minimized. This is not strictly necessary, but you do this so that you can see a feature of drag-and-drop file copying in the workgroup view.

  2. Select Production, then click Vsamdemo.cbl in the right-hand pane, and holding the button down drag it onto the "+" before Testing #1. The Testing #1 level will expand automatically. Continue dragging, expanding Source libraries and the COBOL library folder type by dragging on to their "+" signs, until you can release the mouse button with the cursor on the folder subordinate to COBOL (folder \mfuser\projects\gsdemo\workdemo\source, but you may not be able to see the whole path). Note that the cursor changes from Drop not OK cursor to Drop OK cursor when you are able to drop the file.

    This copies the file to this library. The number in parentheses after the \mfuser\projects\gsdemo\workdemo\source entry changes to 1, as do those after the entries above it in the tree, showing that this library now contains one file. The file and its details are shown in the right-hand pane.

    You can now copy the production .jcl file in the same way, as follows.

  3. Select Production, then click Vsamdemo.jcl in the right-hand pane, and holding the button down drag it onto \mfuser\projects\gsdemo\workdemo\source under JCL in Testing #1.

  4. To see the effect of creating the Testing #1 level and adding files to it, click the Files tab.

  5. Click Source in the left-hand pane and look in the right-hand pane to see the locations of the files. (You may have to resize the project window and/or the Location column to see the full path - see the appendix Windows Tips if you need help.)

    This column shows where the files will be taken from during building, running and debugging of your project. The two source files will be taken from your working folder workdemo, not from idedemo. Your project folder is still idedemo, because that's where your project file is.

Files view

Figure 8-7: Files view after working files are added to Testing #1

If you scroll the right hand pane and resize the columns, the Files view should now look like Figure 8-8.7.

8.3.6 Ignoring a Development Version

Sometimes you may want to use the production version of a file even though you have a development version:

  1. Click the Workgroup tab.

  2. Make sure the tree is expanded under Source Libraries in Testing #1, so you can see \mfuser\projects\gsdemo\workdemo\source under COBOL.

  3. Click the check mark by \mfuser\projects\gsdemo\workdemo\source to turn it off.

  4. Click the Files tab.

  5. Click Source in the left-hand pane and look in the right-hand pane

    Only vsamdemo.jcl is now taken from workdemo. Vsamdemo.cbl is taken from idedemo, which is in the Production level.

8.3.7 Adding a New File

Sometimes during development you need to add a completely new file to the application. You normally add this to a Testing level of your project.

We'll create a new source file for use in this section by simply copying vsamdemo.cbl.

  1. In folder \mfuser\projects\gsdemo\workdemo\source, copy vsamdemo.cbl to vsamnew.cbl. (If you need help on copying files, see the appendix Windows Tips.)

  2. Click Add Files on the Project menu.

    Now that the project has two levels, the Add Files to Project dialog box has an extra field at the bottom, where you specify which level the file should be added to. It has defaulted to Testing #1. We will accept this default.

  3. Open the folder \mfuser\projects\gsdemo\workdemo\source. Ensure the Files of Type field is set to Source Files.

  4. Select vsamnew.cbl, then click Add, then click Done.

    vsamnew.cbl is added to the project. In the File View it has been added under COBOL.

  5. In the Workgroup View, click COBOL under Testing #1, Source libraries.

    The new file has been added to the Testing #1 level.

8.4 Before Continuing

Close the project. If you want to take a break before going on to the next session, you can close Mainframe Express.

Return to the Tutorials Map in the chapter Start Here for the Tutorials and choose which session to go on to next, depending on your interests.


Comments on the books? Click Send Us Comments.


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