| JCL Jobstreams | Uploading and Downloading Files | |
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.
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.
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.
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.
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.
If you need help on creating folders, see the appendix Windows Tips.
You now create the new level, where you will work on the files you want to update:
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 that you create a testing level.
Notice that all the paths shown in the Workgroup View begin with <Project Folder> - for example <Project Folder>\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.)
In our present case it doesn't matter whether you change the paths to absolute or not. We'll do it, so that you can see the effect, though you won't see it for a few steps.
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.
In this dialog box you are specifying the whereabouts of the libraries that will contain your working copies. The fields on this dialog box are for the standard set of libraries. We want to do something more than simply put all the source in one library, so we will create the source libraries separately in a moment.
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.)
For example, change <Project Folder>\copylib to d: \mfuser\projects\gsdemo\workdemo\copylib.
Figure 8-4: Add level dialog
After you have completed these entries, the dialog should look similar to Figure 8.4.
In the following, we'll generally omit d: from these paths unless necessary for clarity.
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.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.
You see that the relative path has changed to an absolute one, as you requested a few steps back.
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:
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.
| Type | COBOL |
|---|---|
| Location Type | Folder |
| Location | d: \mfuser\projects\gsdemo\workdemo\source |
| Description | COBOL source |
| 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.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.
to 
when you are able to drop the file.
This copies the file to this library. The numbers in parentheses after the \mfuser\projects\gsdemo\workdemo entry change 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.
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.7.
Sometimes you may want to use the production version of a file even though you have a development version:
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.
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.
vsamnew.cbl is added to the project, appearing in both the File View and the Workgroup View.
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.
Copyright © 1999 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.
| JCL Jobstreams | Uploading and Downloading Files | |