Installation Considerations

Accessing Mainframe Files

Chapter 2: Workgrouping

This chapter describes how you administer workgroup projects. You should read the chapter Workgrouping in your User's Guide for background on how workgrouping projects are used, before you read this chapter.

2.1 Overview

Application Workgrouping in Mainframe Express enables you to share resources between a group of programmers. All the source files, load modules and other resources for an application are held centrally on a server, and programmers only download the individual files they need to work on. This is covered in more detail in the section Overview in the chapter Workgrouping in your User's Guide.

As a workgroup administrator you have the following responsibilities:

• Setting up a workgroup at the Production level

• Promoting and managing changes made by members of the workgroup

2.2 Setting up a Workgroup

Setting up a workgroup consists of making all the resources needed to run an application available over the network to programmers, and setting up a Mainframe Express project to use those resources for working on the application. You also need to set up CICS, IMS and SQL resources as required.

At the end of the process, you distribute a copy of the project file to each programmer in the workgroup. Depending on how you have decided to structure the workgroup, you might also distribute a copy of the system catalog and the CICS Resource Definition File.

You set up a workgroup in six stages:

1. Planning

   Deciding which resources are to be shared and which are to be local to each programmer.

2. Setting up a project

   Creating an area on the server for all the sources and a Mainframe Express project.

3. Setting up the data set catalog

   Sharing access to data files.

4. Setting up other shared resources

   Setting paths to configuration files used by Mainframe Express options.

5. Building and testing the project

   Ensuring the project is complete.

6. Distributing the project

   Making the project available to the programmers in the workgroup.

At the end of this process, any programmer in the workgroup can run and debug the application from their PC, using the shared sources and resources set up at the production level of the project.

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

We've also provided some extra information to make setting up a workgroup easier and to help improve performance, under Tips and Tricks.

2.2.1 Planning

Before you start work, you need to consider the following issues:

• Where are the production level application sources going to be stored?

  You would normally download them to the server, but you also have the option of leaving some or all on the mainframe and accessing them using the Mainframe Express SourceConnect option. In the case of a very large application, you might just download a subset of the sources for working on and leave the rest of them on the mainframe.

  For more information on configuring SourceConnect, click Help Topics on the Help menu, then on the Contents tab click Development Environment, Accessing the Mainframe, How to Configure Mainframe Access.

• How are you going to control access to sources?

  Programmers in the workgroup should not have write access to the production level sources on the server or the mainframe; promotion should be managed through use of the Staging library.

  A Staging library is where programmers in the workgroup copy sources that they want to move to another level. Mainframe Express does not impose any rules on how you should use this facility. You need to decide how many folders you want in a Staging library, and how they should be used. For example, you could allocate one folder for each programmer in the workgroup; alternatively, you could allocate different folders for promoting different types of file.

• How are you going to manage data in your workgroup?

  Data can be accessed either on the mainframe, on a network server, or locally on the programmers' PCs. You need to decide which is most appropriate for the volume and type of data you have. You can use any combination of platforms on a project.

• Which types of load library do you want to set up?

  By default, all load modules are generated into a single folder under the category All Load Modules. You can add extra folders to the Load Library to categorize load modules by type (for example, IMS, COBOL and BMS load modules).

• What dependency libraries do you need to set up?

  You can exploit the concatenated search used by Mainframe Express to search a number of locations for copybooks and other dependent files. Mainframe Express automatically adds a Dependency folder for files required by the CICS, SQL and Assembler Options to the Dependency library - you might need to change this folder to a central location for sharing by members of the workgroup.

  You should also consider whether there are large numbers of dependent files that it would be simpler to leave on the mainframe. You can search mainframe locations as Dependency folders using SourceConnect .

You must make sure that you set up the project correctly before you distribute it to the programmers in the workgroup. As programmers copy files from the production level to work on, they make changes to their own individual copies of the project file. There is no automatic way of synchronizing their project files with any subsequent changes needed to build the application correctly. We strongly advise you not to skip the stage of building and testing the application before distributing project files (described in the section Building and Testing the Project).

2.2.2 Setting up a Project

Workgroups are set up using Mainframe Express projects. For detailed instructions on working with Mainframe Express projects click Help Topics on the Mainframe Express Help menu, then on the Contents tab click Development Environment, Working with Projects.

To set up a project for workgrouping:

1. Allocate one or more shared folders on the network to hold all the elements of the project. This is where all the production libraries for the workgroup are to be held. Give the programmers in the workgroup read-only access to these network shares. You don't have to make access read-only, but it prevents workgroup programmers from changing the contents of the production libraries.

   You also have the option of leaving some files on the mainframe. You can set any workgroup folder to point to a mainframe PDS using the SourceConnect utility. If you use this facility, all programmers in the workgroup need to set up SourceConnect on their PCs. See the chapter Accessing Mainframe Files for more details.

2. Use the project wizard to create a project for the application.

   The second screen of the wizard offers you the choice of:

   • Continuing with the wizard to create a completely new project.
   • Basing your new project on an existing project.
   • Basing your new project on a project template. All project templates are located in a template folder which in most Mainframe Express installations will be x:\mfuser\templates. This folder may also contain subfolders for project files to be supplied with each template project. (See the section Project Templates.)

   When creating a new project from an existing project or a template project, you can opt to have all the project files copied, complete with their folder structure, to your new project location. This has no effect if a project template has no associated project files.

   If your project uses CICS, you can use the CICS Resources page of the New Project wizard to copy the Resource Definition File to a shared location on the network (see the section Considerations for CICS Support).

3. Click the Workgroup tab on the Project View and add the following folders as needed:
   • Dependency library folders for copybooks, proclibs, control cards, dclgen includes, Assembler macros and Assembler copybooks.

     You need to include folders for any copybooks which are part of your organization's standards. For example, you might have a set of copybooks to define employee records, which are shared between several different applications. You can leave these copybooks on the mainframe and set up the folders to use SourceConnect to reach them.

   • Load library folders

     By default, all loadable modules are generated in a single folder called All load modules. You can add folders to the Load library for specific types of module, differentiating for example between COBOL, IMS and Assembler load modules.

4. Add all the source files needed to build and run the application to the project. You can add source files from the mainframe by clicking Add Files on the Project menu and then by dropping down the list in the Add from field on the Add files dialog box, and clicking on My mainframe.

   You should try building the project at this stage to see whether it is complete or not. If you get any build errors because of missing files, you need to do one of the following:

   • Add the missing files explicitly to the project

   • Add Dependency library folders set up to point to the locations where missing copybooks are stored.

5. Allocate a share on the network for use as a Staging Library.

   The Staging Library is where programmers copy files they want promoted to the Production level. Give programmers in the workgroup read/write access to this area.

   Then add one or more folders to the Staging Library, as subfolders of the share you have set up in the previous step. You need to set an absolute path, qualified with the network share or drive letter. Organize the folders in the Staging Library in the way that best suits the working practices for the workgroup. For example, you could classify folders for storage of different types of file, or alternatively you could provide a separate folder for each programmer.

2.2.2.1 Project Templates

The project creation wizard allows you to create an entirely new project. You can also make a copy of an existing project with the option to copy all the project files to the new project folder. This facility has been adapted to provide a project template capability so that administrators can provide a range of 'ready-made' projects.

Projects consist of a project definition file <project name>.mvp plus subfolders containing all the project files. The only difference between a project template and any other project is its location. Project template .mvp files are located in a special templates folder which is created when Mainframe Express is installed. This folder may also contain subfolders for project files. This gives you a range of options. Your templates can consist of just the project definition .mvp files, or you can include some of the associated project files, or you can include complete projects.

Project templates are used by the project creation wizard which reads the contents of the project templates folder and lists the file names without their .mvp extensions on page 2 of the wizard. You may find it useful to use meaningful project file names, if possible.

You can create and modify templates in exactly the way you create and edit any other project. The only difference is that you must specify the project templates folder as the project location. You may find it useful to restrict write access to the project templates folder, otherwise any user can edit your templates.

2.2.3 Setting up the Data Set Catalog

The data catalog determines the location of all the data files for a project. There are two possibilities for setting up the data catalog for a workgroup:

• Share a single catalog centrally

• Distribute a copy of the catalog to each member of the workgroup

These options are discussed separately in the subsections below. For background information on how you use the data catalog, see the chapter Files and Data Sets in the User's Guide. For detailed step-by-step instructions on using the data catalog, see the Mainframe Express online help. Click Help Topics on the Help menu, then on the Contents tab click Development Environment, Emulating the Mainframe Environment, Using Data Set Catalogs.

2.2.3.1 Shared Catalog

The instructions below set up a shared catalog based on the following assumption:

• All data sets are held centrally (both read and read/write)

If you decide to use a shared catalog, you must be aware of the dangers of file conflicts between different members of the workgroups.

To set up the catalog:

2.2.3.2 Local Catalogs

Local catalogs are maintained by individual programmers in the workgroup. They can reference local data sets, or data sets shared over the network or from the mainframe via DataConnect.

The advantages of local catalogs include:

• Local catalogs lead to better performance.
• Local catalogs have no file collisions.

The disadvantages of local catalogs include:

• Local catalogs have an additional cost of data redundancy.
• Local catalogs make it harder to share catalogued data among workgroups.

To set up the catalog:

1. Add the shared data sets to the catalog. Ensure that these files are available on one or more network shares available to members of the workgroup, or available on the mainframe via DataConnect. You can put data sets which are not updateable on read-only shares.

2. Set the System catalog field on the Catalog tab of the Project settings dialog box to point to a relative path for the catalog. For example, to keep it in the same folder as the project file:

   .\

3. Set up the allocation folder.

   This is for data sets which are created by the application at run-time or when allocating a data set manually. Mainframe Express automatically allocates files in the folder specified by the Allocation folder field on the Catalog tab of the Project settings dialog box.

   Set the Allocation folder field to a relative path. Programmers in the workgroup can change this path to one local to their PC if necessary.

2.2.4 Setting up Other Shared Resources

If your application uses any of the following resources, you need to make configuration files and/or databases available to all the members of the workgroup:

• CICS

• IMS

• DB2®

2.2.4.1 Considerations for CICS Support

There are two resources issues to consider.

2.2.4.1.1 Resource Definitions

You can either share the resource definition file (RDF) centrally between all members of the workgroup, or provide each workgroup member with their own separate copy. In either case you should set up all the resource definitions required to run the application.

See the chapter Configuring CICS Regions in the CICS Option Technical Guide for detailed advice on shared and stand-alone use of resource definition files.

For step-by-step instructions on how to set up CICS resources, see the online help: click Help Topics on the Mainframe Express Help menu, then on the Contents tab click CICS Option, Defining Resources.

You may want to download resources from a CICS System Definition (CSD) file on a mainframe. See the chapter CICS Resource Definitions for more information.

2.2.4.1.2 FCT Considerations

The CICS System searches the workgroup Data library folders for the data files referenced in the FCT, unless overridden by an explicit path. This enables you to have concatenated search paths for your CICS data files.

If you do use the Overrides tab on the FCT properties dialog box to set an explicit path for a file, you should ensure that the path is accessible to all users in the workgroup.

2.2.4.2 Considerations for IMS Support

There are two separate types of resource to consider for IMS:

• PSB, DBD, MFS, IMS transaction codes and the database catalog

  These resources are found by searching through the concatenated list of folders for IMS Load libraries and All Load Modules. You can set up your shared IMS resources under the Load library folder at the production level, and programmers in the workgroup can override these by creating local IMS resources.

• IMS databases

  There are four ways of accessing IMS databases:

  • Exclusive use
  • Shared read-only
  • Fileshare
  • Remote

  The location of these databases (apart from remote databases) is determined by the information set on the IMS tab of the Project settings dialog box. For further information on types of access, and setting up, see the chapter The IMS Option Interface in your User's Guide.

2.2.4.3 Considerations for DB2

Relational databases for the SQL option can be accessed by programmers in the workgroup in any of the following ways:

• Local data accessed through a local XDB server

• Data stored on a network share, accessed through a remote XDB server

• Data stored on the mainframe, and accessed through XDBLink.

Refer to the chapter SQL Option for DB2 in your User's Guidefor more information.

2.2.5 Building and Testing the Project

At this stage the project should now be complete, together with all the resources needed to run it. You should test that you can build and run the application correctly, before you distribute it to the members of the workgroup. This is because once you have distributed the project, there is no automatic way of synchronizing subsequent changes needed to build the production level of the application. Either you redistribute an updated copy of the project, in which case programmers lose any changes made to their individual projects, or each programmer must apply the updates to their individual projects.

To build and test the project:

1. Build the project.

   This compiles all the sources in the project to the Production level Load Libraries.

2. Run the application, by clicking Start Debugging on the Debug menu.

   This opens the Start debugging dialog box. For more information on how to debug, click Help Topics on the Mainframe Express Help menu, then on the Contents tab click Development Environment, Debugging COBOL Programs.

2.2.6 Distributing the Project

When the project has been tested and is complete, you can distribute it to the programmers in the workgroup. To distribute the project:

1. Add a Testing level to the project. You will need at least one Testing level and you can have up to nine. See the section The Workgroup View in the chapter Workgrouping in your User's Guide for more information about Workgrouping levels.

   When you do this, you are prompted to convert all the relative paths for the production level libraries to absolute paths. This ensures that the Production libraries point to areas on the server.

2. Copy the .mvp file together with any other resource files that are to be accessed locally (system catalog and CICS resource files) to a network share available to the programmers in the workgroup.

   Which resource files you need to copy locally depends on which decisions you have made while setting up the project.

Once a programmer in the workgroup has copied these files, they should be able to run and debug the application using the sources stored at the production level of the project.

2.3 Promoting and Managing Changes

The Staging Library is used to promote changes made by programmers back into the Production library. Periodically, you should copy the files in the Staging Library back into the Production Source Library, and rebuild the project to update the Production Load Library. How often you do this depends on the standards and criteria operating at your site.

2.4 Tips and Tricks

These tips can make it easier to set up a project for workgrouping. You don't have to follow this advice if it conflicts with the standards or systems operating in your organization.

We recommend:

• That your site uses standard drive letters when assigning network drives for workgrouping.

  This provides better performance than using UNC names.

• That you set up the project using a machine other than the server actually containing the production source and data files.

  This enables you to use the same mappings and paths for projects and resources as the workgroup members.

You can add folders to the Source, Dependency and Load libraries which contain modules which you have not explicitly added to the project. These folders are on the concatenated search path. This enables you to have Dependency and Load libraries with routines common to many projects, without the overhead of adding all the files contained in these libraries to every single project.

Installation Considerations

Accessing Mainframe Files