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.
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
This demo uses the project idedemo.mvp that you created and built
in the chapter Using Mainframe Express.
- If you have closed Mainframe Express, open it as before. Close any
project windows and any other windows that are open.
- 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.
In this session you:
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.
- 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.
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.
- Click the "+" alongside Source Libraries.
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.
- Click the "+" alongside COBOL.
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.
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.
- Create folder workdemo within \mfuser\projects\gsdemo.
If you need help on creating folders, see the appendix
Windows Tips.
- Create folder source within workdemo.
You now create the new level, where you will work on the files you want
to update:
- 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.
- 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:
- Specify a different parent folder from that for the Production
level.
- Create several source libraries instead of one.
- 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.
- 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.)
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.
- Click OK.
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.
- 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.
- 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).
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:
- 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.
- Enter the following, and click OK:
| Type |
COBOL |
| Location Type |
Folder |
| Location |
d:
\mfuser\projects\gsdemo\workdemo\source |
| Description |
COBOL source |
- 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.
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.
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.
- 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.
- 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
to
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.
- 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.
- To see the effect of creating the Testing #1 level and adding files
to it, click the Files tab.
- 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.
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.
Sometimes you may want to use the production version of a file even
though you have a development version:
- Click the Workgroup tab.
- Make sure the tree is expanded under Source Libraries in
Testing #1, so you can see
\mfuser\projects\gsdemo\workdemo\source under COBOL.
- Click the check mark by
\mfuser\projects\gsdemo\workdemo\source to turn it off.
- Click the Files tab.
- 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.
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.
- 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.)
- 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.
- Open the folder \mfuser\projects\gsdemo\workdemo\source.
Ensure the Files of Type field is set to Source Files.
- 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.
- In the Workgroup View, click COBOL under Testing #1,
Source libraries.
The new file has been added to the Testing #1 level.
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.