General Information Manual

General Information Manual

DELTA for IMS© is a trademark of the BMC Corporation. Xpeditor© is a trademark of the Compuware corporation. SmartTest© is a trademark of the ViaSoft corporation. HourGlass© is a trademark of Mainware Corporation. TicToc© is a trademark of Isogon Corporation. IBM is a registered trademark of International Business Machines Incorporated.

All other trademarks and service marks are the property of their respective owners.

Copyright © 1989-2009, Standardware Inc. All rights reserved.

This material may not be reproduced in whole or in part by any means, without written permission from Standardware Inc.

Standardware Incorporated

424 Pelham Manor Road

Pelham Manor, NY 10803 USA

Tel: 914-738-6382

Fax: 914-738-7136

Standardware Incorporated

23119 Bryant Avenue

Purcell, OK 73080 USA

Tel: 405-288-2016

Fax: 405-288-1015

Office Locations:

Email: [email protected]

www.standardware.com

http://www.standardware.com/

iii

Contents Introduction ...................................................................................................................................... 5 Overview of the COPE Solution ....................................................................................................................... 5

Why use COPE? ........................................................................................................................................... 5

What is COPE? ............................................................................................................................................. 6

Terminology ................................................................................................................................................ 6

Presentations and Additional Information ...................................................................................................... 8

The COPE Products ......................................................................................................................................... 9

COPE for CICS .............................................................................................................................................. 9

COPE for IMS ............................................................................................................................................. 10

COPE for CICS/DBCTL ................................................................................................................................. 10

COPE for CICS .................................................................................................................................. 11 Introduction to COPE for CICS ....................................................................................................................... 11

The Problem: ............................................................................................................................................. 11

The COPE for CICS solution: ....................................................................................................................... 11

Benefits of COPE for CICS: .......................................................................................................................... 13

COPE for CICS Facilities ................................................................................................................................. 15

Resource Management .............................................................................................................................. 15

Resource Definition Offline ........................................................................................................................ 15

CICS Table Maintenance ............................................................................................................................ 15

Online CICS Facilities .................................................................................................................................. 15

Lsys Association ..................................................................................................................................... 15

Online Administration ............................................................................................................................ 16

Implementing COPE for CICS ......................................................................................................................... 16

Importing Existing CICS Regions ................................................................................................................. 16

DBCTL environment ................................................................................................................................... 16

DB2 environment ...................................................................................................................................... 17

Implementation tasks ................................................................................................................................ 17

System Requirements ................................................................................................................................ 17

End-User Impact ........................................................................................................................................ 18

COPE for IMS................................................................................................................................... 19 Introduction to COPE for IMS ........................................................................................................................ 19

The Problem: ............................................................................................................................................. 19

The Solution: ............................................................................................................................................. 19

Benefits of COPE for IMS:........................................................................................................................... 19

The COPE for IMS Development Environment ............................................................................................... 20

COPE for IMS Additional Features ................................................................................................................. 21

COPE for CICS/DBCTL ...................................................................................................................... 24 Introduction to COPE for CICS/DBCTL ............................................................................................................ 24

The Problem: ............................................................................................................................................. 24

The Solution: ............................................................................................................................................. 24

Benefits of COPE for CICS/DBCTL: .............................................................................................................. 24

Summary of Benefits .................................................................................................................................... 25

Conversion of Existing IMS or CICS systems ................................................................................................... 27

iv

Overview of COPE processing for COPE IMS and COPE CICS/DBCTL ............................................................... 28

COPE for IMS and COPE for CICS/DBCTL Facilities ......................................................................................... 30

The Libset .................................................................................................................................................. 30

Support of non-COPE Development Environments ..................................................................................... 30

Shared Dataset Capability .......................................................................................................................... 30

Import Facility ........................................................................................................................................... 31

Edit Facilities.............................................................................................................................................. 31

SQL Call Trace Facility (COPE for IMS only) ................................................................................................. 31

Abend Summary Screen (COPE for IMS only) ............................................................................................. 31

Compile Facilities ....................................................................................................................................... 31

Promotion Facilities ................................................................................................................................... 32

Export Facilities ......................................................................................................................................... 32

System Generation Facilities ...................................................................................................................... 32

Database and Transaction Start/Stop (COPE for IMS only) ......................................................................... 33

Batch JCL Facilities ..................................................................................................................................... 33

External Authorization Interface ................................................................................................................ 34

DB2 Features ............................................................................................................................................. 34

Source/Load Module Compare .................................................................................................................. 34

Fast Path ................................................................................................................................................... 34

DBD Index Sparsing, Randomizer and Compression Exits ........................................................................... 34

DBCTL support for CICS and IMS ................................................................................................................ 35

APPENDIX ....................................................................................................................................... 36 Cost Justification .......................................................................................................................................... 36

Initial Costs Summary ................................................................................................................................ 36

Implicit Costs Summary ............................................................................................................................. 36

Operating Costs Summary ......................................................................................................................... 36

Initial Costs Detail ...................................................................................................................................... 36

Summary of Costs ........................................................................................................................... 37 A copy of an evaluation performed by a major telephone company .............................................................. 38

Evaluation ................................................................................................................................................. 38

Recommendation ...................................................................................................................................... 39

Summary ................................................................................................................................................... 39

Figure 1: COPE Products and Features .............................................................................................. 7

Figure 2: IMS/DC environments, before and after COPE ................................................................ 23 Figure 3: CICS environment, before and after COPE ....................................................................... 26 Figure 4: COPE for IMS - building a system ..................................................................................... 29 Table 1: COPE Products and Features ............................................................................................... 9

Table 2: System Requirements ....................................................................................................... 18 Table 3: Summary of Benefits ......................................................................................................... 25 Table 4: Conversion of Existing Systems (IMS)................................................................................ 27

Table 5: Conversion of Existing Systems (CICS) ............................................................................... 27 Table 6: Outputs from System Generation ..................................................................................... 33 Table 7: Summary of Cost Benefits ($US) ....................................................................................... 39

5

Introduction

Overview of the COPE Solution

The family of COPE products is designed to enhance productivity, simplify administration and maintenance, and reduce machine resource requirements. Each product in the family addresses a distinct development environment, allowing you to select those products which apply to your particular configuration. When more than one product is installed, the products are architects to cooperate and communicate with one another, eliminating duplicate maintenance efforts across different products.

Why use COPE?

How does a leading financial software services company provide basically the same software to a dozen different clients, but with intricate custom-made features for each client?

• The cost was too high for the two or three IBM mainframes that would seem to be needed for this! The company installed COPE for IMS, and found that it could support a dozen customized copies of their current system and run them simultaneously on a single IBM mainframe. Their programmers can now compile and test in any of the dozen test environments simultaneously, and without interfering with each other.

How can a large manufacturing software services company effectively demonstrate their system to clients if every time one of the demonstration systems comes up, the others must all be down?

• This company installed COPE for IMS, and now they run seventeen demonstration systems simultaneously, for little more than the price of one system.

How can the world’s most famous credit-card company get ten copies of their DB2 system for the price of one, thereby saving immense hardware, software, and operational costs?

• With the COPE for IMS software product, this company found that only one DB2 system was needed where ten separate DB2s had appeared to be unavoidable.

How can a large financial institution convert a set of CICS based systems that used 84,000 DL/1 Program Specification Blocks (PSB’s) to access a Database Control (DBCTL) subsystem containing different versions of the same named databases without changing any source?

• COPE for DBCTL was installed and the entire set of application definitions converted to use DBCTL in three weeks, without changing a line of source code.

The bottom line: COPE provides multiple copies of existing systems that operate within a single system. The replication of systems is performed in a clean, cohesive and consistent manner.

6

What is COPE?

COPE is a multi-platform application that allows an installation to operate separate and distinct versions of related applications:

•

•

IMS Data Base/Data Communications (DB/DC) applications under one IMS control region or under multiple CICS regions accessing a single DBCTL region

Multiple CICS region images operating within a single CICS region and accessing multiple versions of CICS resources such as VSAM, DL/1 or DB2 databases and remote regions or images of regions

Without COPE, separate DB/DC environments are typically required to support unit testing, system testing, and customized versions of the same application system. Some companies devise compli- cated manual naming conventions to allow multiple versions of programs and databases to coexist.

COPE automates and controls this renaming process, making a practical reality the concurrent operation in a single region of multiple versions of an application system.

Terminology

The following frequent terms are encountered in COPE documentation.

• A logical system (Lsys) is a version of an application system and/or collection of databases that executes in a COPE-controlled physical IMS/DC, DBCTL or CICS region. In CICS, an Lsys can be treated in most ways, by both the user and the application programmer, as if it were a separate CICS region.

A physical system (Psys) is a single IMS control region, DBCTL subsystem, or CICS region. If supporting DBCTL, a Psys can contain up to 255 Lsys‟s (a typical number is 10); otherwise there is no limit. There can be many Psys‟s, each containing multiple Lsys‟s, and all will be managed in a consistent way.

•

7

The COPE Products

(ROAR) DB2 Feature

Region Optimization and

Reduction (ROAR) Feature

CICS Region

Management Feature

COPE for CICS

Compuware

Xpeditor

Feature

ViaSoft

SmartTest

Feature

BMC DELTA

Feature

CICS Feature

COPE for IMS

COPE for DBCTL

Figure 1: COPE Products and Features

8

Presentations and Additional Information

Standardware‟s web site at HTTP:// WWW.STANDARDWARE.COM provides access to additional COPE documentation. It also provides access to a presentation on each individual COPE product.

The people at Standardware Inc. will be happy to answer any questions you may have by telephone, at the number on the cover of this manual, and to arrange for presentations and demonstrations on- site at your installation, as your needs may require.

9

The COPE Products

There are three COPE products and several features with each product, as indicated in the following table:

Table 1: COPE Products and Features

Product

COPE for CICS

Features

CICS Region Management

Region Optimization and Reduction

DB2 Subsystem Sharing

COPE for IMS Compuware Xpeditor Feature

ViaSoft SmartTest Feature

BMC DELTA for IMS Feature

CICS Feature

COPE for CICS/DBCTL

Each product operates independently, and may be combined suitably for your installation. For example, COPE for CICS may be used in conjunction with COPE for IMS or COPE for CICS/DBCTL, whichever is appropriate for the type of IMS subsystem used to manage the DL/1 data for CICS.

COPE for CICS

The product supports coexistence of multiple application versions, with corresponding version-specific resource access, in a single CICS region. It provides an ISPF-based CICS resource definition feature that can manage all CICS resource definitions. COPE for CICS automatically replicates definitions across different Lsys‟s that are defined as synchronized.

The features include:

• Region Optimization and Reduction

This feature allows existing and new CICS systems to be combined into a single CICS region. It implements the „Lsys within a Psys‟ model. A user may subsequently connect to an Lsys and work as if having signed on to a separate CICS region. Lsys relationships may be defined that mirror the region relationships in a CICSplex system, in a conventional Terminal Owning Region/ Application Owning Region/Data Owning Region (TOR/AOR/DOR) environment, or in standalone regions .

10

• CICS Region Management

This feature allows CICS resource definitions to be maintained in an ISPF environment. All CICS regions, whether or not they are managed by COPE, may be maintained through this feature. The region management feature is capable of automatically copying resource definitions from one region to other regions to maintain resource synchronization; this may be done even if the source and target regions do not share the same CSD, and whether or not a particular region is a COPE Psys.

• DB2 Subsystem Sharing

This feature is the application of Region Optimization and Reduction to the DB2 environment, providing the ability to maintain multiple versions of tables and views in a single DB2 subsystem.

COPE for IMS

The product allows multiple IMS/DC systems to be combined into a single IMS Control Region. It supports multiple versions of IMS and DB2 databases and multiple versions of application programs.

The features include:

• The Compuware Xpeditor Feature

This feature supports interactive debugging with the Compuware Xpeditor product. Multiple users may interactively test different versions of the same application in the same or in a different Lsys simultaneously.

• The ViaSoft SmartTest Feature

This feature supports interactive debugging with the SmartTest product under TSO.

• The BMC Delta Feature

This feature allows new databases and transactions to be added to a COPE environment using the BMC Delta product.

• The CICS Feature

This feature allows CICS regions to access databases belonging to an Lsys at the same time they are being accessed by IMS applications.

COPE for CICS/DBCTL

The product manages multiple versions of identically named databases and PSB‟s for CICS/DBCTL installations. The capability is useful for converting a local DL/I CICS system to a DBCTL system. It solves the problem of multiple versions of databases and programs sharing a single environment without any source changes.

11

COPE for CICS

Introduction to COPE for CICS

The Problem:

Development of CICS applications involves creating test files and databases or DB2 tables, the writ- ing of application programs and maps, the creation of CICS resource definitions, and the use of the CICS environment to test and debug the application. If an existing, stable version of the application must remain untouched, or if parallel development is being performed by different groups, each of the application instances requires its own set of resources.

The complexity of this process increases if the application requires DL/1 or DB2 databases. Both DBCTL and local DL/1 subsystems may be present. In a DBCTL environment, the maintenance of different versions of identically named databases can result in naming conflicts. Both local DL/1 and DBCTL require Data Base Description Blocks (DBD‟s) and Program Specification Blocks (PSB‟s) to be maintained. In addition, DBCTL requires maintenance of Stage 1 and Dynalloc and (optionally) Data Base Recovery Control (DBRC) RECON definitions. If DB2 is being used, multiple versions of DB2 databases are required to coexist in a single DB2 subsystem, or multiple DB2 subsystems may be required.

Currently, the usual solution to testing multiple versions of application systems in CICS is to define and execute different CICS systems simultaneously. As a result, the number of CICS regions can and does proliferate. It is not uncommon for installations to host dozens or even hundreds of CICS regions, and many installations do not even know how many CICS regions are running at their site. Even at a carefully managed site, the sizable resource definition task, complex change management procedures, number of files and conflicting database definitions, together with the considerable system resources required, produce a management problem and a CPU resource load.

The COPE for CICS solution:

COPE for CICS addresses the above difficulties by means of the following features:

• COPE for CICS provides a global view of all CICS regions

The global view automatically documents the relationships the systems have to each other, and is available for all regions, both COPE and non-COPE.

• Multiple CICS regions may be combined into a single CICS region via an automated process known as import

Each former region runs as an Lsys within the single physical region. Program, file, transaction and queue resources accessed by that Lsys are separate from resources accessed by any other Lsys in the same region.

• Resource definition maintenance may be performed for all CICS regions from a single session

12

From the ISPF platform, the CICS Region Management feature allows maintenance of all CICS resource definitions in all regions. This feature is available for both COPE and non-COPE regions. It interfaces transparently with COPE facilities to provide automatic resolution of resource name conflicts.

• Selected resources, such as debugging, performance and monitoring tools, may be easily shared between Lsys’s

Applications may be designated as being Psys specific. The resources that the applications use are not translated and the application may operate in any Lsys using the same set of files and databases.

• Support of different resource mappings

The particular resources to be shared may be different for different Lsys‟s, allowing development of shared applications to proceed on one Lsys while fully implemented on other Lsys‟s.

• No program change is required for an imported program

When a program is running within an Lsys, resource references made by the program always access resources for that Lsys.

• No change to programmer development procedures is required

Programmers continue to link-edit programs into the load libraries assigned for their application version, and use the same module names and link-edit control statements and parameters.

• Accessing an Lsys in a Psys is exactly analogous to accessing a CICS region

When a user connects to a CICS region and associates the terminal with an Lsys, all transactions entered at that terminal run under that Lsys. For such transactions, resources of other Lsys‟s, even if identically named, are not accessed unless defined within the Lsys as remote.

• Groups of Lsys’s may be configured to interrelate as if they were groups of connected CICS regions

From the standpoint of any Lsys in such a group, a resource within another Lsys in the group is a remote resource, and is defined and accessed just as if it were defined in another CICS region.

• Many copies of a single CICS region may run independently as Lsys’s in the same Psys

A copy of an existing Lsys may easily be created, allowing a new version of an application to be quickly set up for customization or development.

• Automatic synchronization of resources in different Lsys’s may be enabled

An installation frequently requires coordination of definitions between different Lsys‟s. For example, the addition of a new program to one Lsys might always require the addition of that program to one or more other Lsys‟s. By a simple menu-driven process, the administrator may cause CSD and CICS table resource definitions entered for one Lsys to be propagated to other Lsys‟s automatically, a feature known as Lsys Synchronization. The automatic propagation may be customized separately for particular types of resources.

13

• Simultaneous access to different identically-named versions of DL/1 databases in a DBCTL environment is possible for different Lsys’s and non-COPE CICS regions

Conflicting database names in a DBCTL subsystem are resolved automatically. This allows multiple regions that have been imported into different Lsys‟s in the same Psys, or a single region that has been imported into multiple Lsys‟s, to each access a distinct set of databases, with no renaming requirements on the part of the administrator.

• An export facility allows easy creation of a standalone non-COPE CICS system

This facility allows easy migration of an Lsys into production when development is completed.

•

•

Migration of local DL/1 applications to an existing or new DBCTL environment can be ac- complished without changing any DBD names or modifying any application code

COPE for CICS provides facilities to convert existing DB2 plans and to maintain the new DBRMs generated from program maintenance activity

This support is provided via a batch process which generates BIND statements for a modified DBRM associated with an application executing within a specific Lsys.

• CICS JCL to support Lsys-specific files is generated automatically

CICS region JCL must contain definitions for files for all Lsys‟s executing in the Psys. This JCL may be generated for any COPE CICS region (Psys) by means of an option under the Region Management feature.

• The Batch Message Processing (BMP) JCL conversion feature allows BMP Processing or Batch DL/1 jobs to access a set of databases related to a specific Lsys

By specifying the Lsys on the job card, the JCL is then converted to operate against Lsys-specific databases when the job is executed.

• Support is provided for Lsys-independent access to different versions of identically- named DB2 tables in a single DB2 subsystem

This feature allows both COPE and non-COPE systems to access the same DB2 subsystem simultaneously.

• A source and listing maintenance system for CICS tables is provided

This allows access to source and assembly listings of CICS tables for all CICS systems in an installation.

Benefits of COPE for CICS:

These are some of the benefits that can be realized from the implementation of COPE for CICS:

• A single-platform, single-point-of-control, single-session capability for CICS resource maintenance is available

14

Formerly, table maintenance needed to be performed under TSO, while CSD maintenance was performed under CICS. In addition, switching between CICS regions was often necessary when performing resource definition for different regions.

• Administrative Security

COPE provides ACF2 and RACF controlled access protection to the administrative dialogues.

• Administrative effort in entering resource definitions is reduced

Synchronization of resource definitions allows entry of a single definition to replace entry of the same definition for multiple systems. It is not necessary to remember all the systems requiring a synchronized change.

• The number of CICS regions required for application development is reduced

This does not impact developers, but reduces backup and recovery requirements, auxiliary storage requirements, LSQA main storage requirements, and the use of unwieldy subsystem name tables.

• The effort required to set up an additional test environment is substantially reduced

Creating an additional Lsys does not involve the allocation of CICS system datasets, registering an additional sysid or table suffix, preparing a separate set of CICS tables, requesting new VTAM definitions, or adding system entries to existing Terminal Control Tables (TCTs).

15

COPE for CICS Facilities

Resource Management

Resource management under COPE for CICS is implemented by means of the Resource Definition Offline (RDOF) and CICS Table Management functions.

Resource Definition Offline

Resource Definition Offline allows the manipulation of CSD resource definitions from the ISPF platform for both COPE and non-COPE systems.

RDOF provides an ISPF dialog which allows scrolling display and selection of CSD lists, groups and resource definitions. Full CSD import capabilities are provided, as well as the Install and Check functions (under CICS/ESA Version 4.1). The data entry screens are similar to the CICS CEDA transaction screens, differing only in those aspects where ISPF conventions are followed. RDOF is designed to be easy to use for anyone familiar with CEDA and ISPF.

For non-COPE regions, RDOF provides roughly the same capabilities as CICS RDO and includes the COPE for CICS synchronization facility. For COPE regions, RDOF additionally handles the resource assignments required by COPE for CICS to support multiple Lsys‟s within a single Psys.

CICS Table Maintenance

CICS tables are maintained within ISPF using the COPE for CICS table maintenance facility, which allows existing table source to be imported to an Lsys, edited, and compiled. Editing uses the stan- dard ISPF editor. If Lsys synchronization applies to the Lsys and table type being edited, any changes made to the table are propagated to tables of the same type associated with Lsys‟s in the same synchronization group. Compile listings for all tables are maintained automatically.

Online CICS Facilities

Lsys Association

COPE for CICS requires each user to be signed on to an Lsys while connected to CICS. This Lsys is said to be associated with the user‟s terminal. When a transaction is subsequently executed which uses that terminal as its principal facility (or was started by such a transaction), resource name translations are performed based on the associated Lsys. Subsequently, the user may select a different Lsys by means of a COPE-supplied transaction.

The administrator may retain full control of Lsys association, or may delegate this control to any or all users. By means of control statements, the administrator may specify a default Lsys with which each user is associated automatically at connect time or may specify that each user be prompted to select an Lsys when signing on to CICS. To provide a finer degree of selectivity, the administrator may supply a COPE for CICS security exit which can refine control of Lsys association to any de-

16

sired degree. The exit allows access to RACF or ACF2 authorization facilities, or any security product using the SAF interface.

Online Administration

The CICS transaction COPE allows authorized COPE for CICS administrators to perform online administrative tasks such as controlling the status of COPE for CICS or of individual Lsys‟s within a CICS. Using this transaction, the administrator may:

•

•

•

•

Cause COPE for CICS to be withdrawn from a region

Modify the status of an individual Lsys

Cause COPE for CICS tables to be refreshed for the entire Psys, for a particular Lsys, for a particular Lsys and resource type, or for a particular Lsys, resource type and resource name

Control COPE for CICS tracing for debugging applications and COPE for CICS operation

Implementing COPE for CICS

Importing Existing CICS Regions

Importing is the process whereby an Lsys is built from an existing CICS regions resource definitions. Importing a CICS region is performed entirely from the ISPF platform, and occurs in two stages, Specification and Generation.

An administrator must first specify Lsys names and attributes using the administration dialogs, and then identify the source CSD and CSD list entry to be used for the import. COPE for CICS then builds specifications for the Lsys generation. This completes the specification step. The specification may be performed for as many Lsys‟s as desired prior to the generate step, which performs the actual CSD updates for the target COPED CICS region.

Though the process is largely automatic, prompting occurs at several points to allow the administrator to provide additional customization information. Following completion of the generate step, CICS tables must be imported for each Lsys and then compiled.

DBCTL environment

If the DBCTL feature is installed, the DBD‟s and PSB‟s, together with the Stage 1 and Dynalloc source for all existing systems must be identified and copied into COPE. COPE renames all DBD‟s and PSB‟s and will regenerate the Stage 1, DBD, PSB and Dynalloc modules to allow all COPE and non-COPE systems to access the DBCTL system concurrently.

17

DB2 environment

If the DB2 feature is installed, the plans and packages used for every system that is to be imported into an Lsys are first identified with an ISPF application which extracts the BIND definitions from the DB2 catalog. BIND statements which support plans and packages are generated automatically. Ev- ery Lsys uses a different QUALIFER parameter in the BIND specification. This approach implements a capability to maintain different versions of unqualified tables and views in a single DB2 subsystem accessed by multiple COPE and non-COPE systems.

Implementation tasks

To implement COPE for CICS, the following tasks must be undertaken:

•

•

•

•

•

Installation of the COPE for CICS base product(s) you have selected

Optional customization as described in the installation manual

Provision for regular COPE for CICS dataset backups (loss of these datasets will severely impact CICS operations in most cases)

Analysis of current IMS, DB2, and CICS environments to determine which existing systems will be controlled by COPE

If DL/1 is used, availability of IMS stage 1, DBD, PSB and the IMS database dynalloc allocation (DFSMDA) macro definitions for all systems to be controlled by COPE for parsing and generation of the COPE definition

Specification of the Lsys configuration according to the COPE for CICS model

Brief instruction about the COPE for CICS LSYS transaction operation to the application development staff

Import of the CSD and DL/1 and DB2 definitions for each Lsys followed by a regeneration of the CICS tables and Common System Definitions (CSD) for the Psys

COPE for CICS administration duties assignments

•

•

•

•

System Requirements

The following products must be at the indicated release levels to support COPE for CICS:

18

Table 2: System Requirements

System Component

MVS/ESA

CICS

ISPF/PDF

TSO/E

Minimum Version/Release

4.3

3

3.5

2

COPE for CICS requires at least a 4 megabyte TSO region for successful operation of ISPF-platform functions.

DASD space is required for COPE product libraries and for Lsys-related and Psys-related datasets. Requirements are contained in the COPE for CICS Installation Guide.

The system requirements for a COPE for CICS Psys depend upon the number and size of the CICS tables and CSD definitions and any other optional implemented features. These sizes will be larger than a single conventional non-COPE system, but will be less than the sum of all the non-COPE systems that are being combined into one. Resource requirements for a COPE for CICS system can be determined in the usual way by consulting the appropriate IBM manuals.

End-User Impact

Other than entering one transaction to connect a terminal to a particular Lsys (in the case of IMS/ DC and optionally in CICS), or the addition of a token identifying the Lsys in the JOB card of a batch program, COPE is invisible to the end user or developer. No retraining of application users is required in the COPE environment.

19

COPE for IMS

Introduction to COPE for IMS

IBM provides the IMS/ESA program product as a means to move into the Database/Data Commu- nications (DB/DC) environment. IMS offers the following broad functional capabilities:

• • • • • • • • •

Transaction management Data independence Database integrity Database management System controlled recovery of transactions, databases and DB2 tables Online and batch processing High-level language support Fast Path Feature Connections to DB2

The Problem: One of the problems with using a single IMS/DC region for development involves accessing different versions of databases, DB2 tables, Message Format Service (MFS) definitions, and programs all having the same name. This frequently arises when a development department makes changes and requires new versions of identically named objects to test against.

As the number of IMS application systems grows, so does the need to run multiple copies of IMS and DL/1.

The Solution: COPE for IMS provides an alternative to running multiple IMS/DC systems by allowing them to be combined into a single region. Within such a region, Lsys‟s are maintained by COPE. Programs execute within an Lsys and access only libraries, databases and DB2 tables associated with the Lsys. A batch or BMP program may also execute within an Lsys and access like-named databases which are different from those of other Lsys‟s. Any PSB, DBD, MFS, or transaction name conflicts are resolved by COPE.

Benefits of COPE for IMS:

The following are some of the benefits that can be realized from the implementation of COPE for IMS:

• Reduction in the number of separate IMS subsystems you need to run

This can decrease overall system paging rates by freeing virtual storage normally consumed by IMS. For each separate IMS environment under COPE beyond the first, a CSA savings of ap-

20

proximately 800K is realized. Fewer IMS system logs are produced because fewer DL/1 regions are running and there is a reduction in the number of IMS master terminal screens that need to be managed.

• More effective IMS/DC management

The elimination of multiple environments afforded by COPE for IMS increases IMS administrative productivity. This allows for additional environment definitions for more flexible development.

• Major hardware cost savings

This can be realized through efficient utilization of existing capacity.

• Increased systems programmer and operations productivity

This can be achieved, particularly for systems programmers and operations personnel, because fewer IMS subsystems are needed.

• Increased application programmer productivity

This can be achieved from increased availability of test environments. Refer to The COPE for IMS Development Environment section for some other benefits.

• Increased business flexibility

This can be realized because customized systems can be created, for example, for individual departments, company divisions, sales campaigns, and large clients, that would otherwise not be economically feasible.

• The basic COPE function of combining and replicating systems is augmented by a com- prehensive, optional, COPE for IMS Development Environment

This allows maintenance of programs, DBD‟s, PSB‟s and MFS definitions through a series of panels.

• The External Interface allows existing maintenance procedures to be adapted to COPE

This is done by the introduction of a single step within the existing JCL procedures.

• The Year 2000 Feature allows central definition of absolute or relative dates and times by logical system

This feature also controls the execution of online, BMP and batch jobs without JCL changes. In- tended to provide a solution for simultaneous testing of multiple sets of applications which are in the process of modification for operating across the millennium change.

The COPE for IMS Development Environment

The COPE Development Environment allows the definition of library hierarchies and provides facilities for controlling the movement of modules through the hierarchy via “promotion” commands.

21

Each level in the hierarchy can have a separate IMS system defined for it. Unit test and integration test environments can be defined, run in the same control region, operate independently of each other, and have tightly controlled “promotion” rules defined for modules going from one testing level to another.

The COPE library structure supports concatenation, thereby avoiding duplication of common modules between modified versions of application systems. COPE‟s unique internal data management facilities can reduce the amount of DASD space required to store applications by allowing multiple versions of a given module to reside in the same physical dataset.

The Development Environment will be familiar to your programmers, because it is based on the ISPF program product. COPE acts as a centralized control point for application libraries and sup- plies standardized compile procedures for your developers. A mass compilation feature based on generic object names is include.

If your current development/maintenance environment already substantially fulfills your needs, you do not have to use the COPE development environment.

COPE will increase the productivity of your application development staff by allowing greater access to online testing facilities. More online environments can be active simultaneously. Programmers who previously had to test with the Batch Terminal Simulator (BTS) now have access to a genuine online environment. If the Compuware Xpeditor product is used, COPE allows multiple versions of the same transaction to be tested in the same or different Lsys without affecting non Xpeditor users of the transaction.

COPE for IMS Additional Features

COPE for IMS includes the following additional features as part of the base package:

• Extended DB2 access

Applications in different logical systems in one IMS system can access different sets of like- named DB2 tables, which can be all in one DB2 system. You do not need separate DB2s to support separate environments.

• A DL/1 and SQL Call Trace facility

This is for applications operating in IMS message regions.

• Online start/stop application transactions

This is for the starting and stopping of user-defined groups of transactions and databases.

• Enhanced abend messages

This aids developers in solving common programming errors.

• Automatic registration of databases to DBRC

The following extended support of IMS-related software products is available at additional charge:

22

• Full DBRC support

This allows dynamic timestamp extraction for timestamp recovery. All DBRC commands are supported

• Compuware XPEDITOR© support

The support allows individual developers to test a transaction in a logical system without affecting other users of the transaction. Without COPE, it is not possible for users to share a transaction that is being tested.

• VIASoft© support

Developers may use the ViaSoft interactive debugger in a COPE environment.

•

•

BMC DELTA/IMS© support

Year 2000 feature

This feature interfaces with the MainWare HourGlass© and Isogon TicToc© products, and allows Logical Systems which co-exist in a single IMS control region to have different system dates and times. The feature is intended to ease the modification and testing of applications that have to operate across the millennium change. This feature allows each Logical System to have an individual date and time centrally specified, and controls the enforcement of the date/time specification without any special online operator action or batch JCL changes.

23

Existing IMS/DC Environment

DB2

DB2

DL/1 IM S

/DC DL/1

IM S

/DC

IM S

/DC DL/1

Batch

BM P

Batch

BMP BMP

Batch

COPE for IMS environment

COPE for IMS

DL/1 IMS3

IMS1 IMS2

DB2

Batch Batch Batch

BMP BMP BMP

Figure 2: IMS/DC environments, before and after COPE

24

COPE for CICS/DBCTL

Introduction to COPE for CICS/DBCTL

The Problem: The IMS Database Control (DBCTL) environment allows full-function and Data Entry Data Base (DEDB) databases to be accessed from one or more transaction management subsystems. It also allows databases to be accessed by multiple batch systems simultaneously.

Some advantages of using DBCTL include:

• • • •

Multitasking for maximum throughput and application growth Failure isolation for high subsystem availability Reduction of log tapes Reduction of system resource requirements.

However, a difficulty with using a single DBCTL region for all subsystems in a CPU is the need to access different versions of databases with the same name. This situation might arise when a development department makes changes and requires new versions of identically-named databases to test against.

The Solution:

COPE for CICS/DBCTL allows multiple CICS systems to access a single DBCTL subsystem. Each batch program or CICS region can share databases with any other batch program or CICS region, or have a unique set of databases devoted to it. Any PSB or DBD name conflicts are resolved by COPE.

Benefits of COPE for CICS/DBCTL:

COPE for CICS/DBCTL allows conversion of local DL/1 CICS systems to use a single DBCTL environment without changing any DBD‟s, PSB‟s or application programs. In addition, it manages the generation of Stage 1 definitions and DFSMDA modules and supports DBRC.

25

Summary of Benefits

The table below shows the COPE features down the left side, the benefits across the top, and the degree of each benefit given by each feature:

Table 3: Summary of Benefits

Features

Combined Systems

Replicated Systems

CSA Saving

Library Structure

Development Environ- ment

DB2 Savings

DL/1 or SQL Call Trace

Transaction/Database Start/Stop

Abend Summary

Hardware Savings

Very High

Very High

Very High

High

High

Very High

High

Medium

Medium

High

High

Very High

Very High

Personal Business

Productivity

High

High

Very High

Very High

Standardiza- tion Control

High

High

COPE provides all of the above advantages and features without any changes to application programs, ISPF, or IMS DB/DC.

Flexibility

26

Existing DL/1 CICS Environments

DL/1

CICS

1 DL/1

CICS

2 DL/1 CICS

3

Batch Batch Batch

COPE for DBCTL environment containing multiple

versions of identically-named databases and programs

CICS

1

DBCTL

CICS

2

CICS

3 Batch Batch Batch

Figure 3: CICS environment, before and after COPE

27

Conversion of Existing IMS or CICS systems

• The conversion process combines or replicates existing systems without recompiling or relinking application programs or MFS. The source for all PSB‟s, DBD‟s, IMS system definition macros, and IMS database dynamic allocation macros is imported (copied) into COPE to generate a functional COPE system. For CICS, only DBD‟s and PSB‟s need to be imported. COPE uses the imported source to create the combined environment that supports multiple Lsys‟s.

Existing MFS format libraries can initially be used, and changed MFS can be copied automatically into COPE, during ongoing operations.

Existing program load libraries can be used both initially and during ongoing operations, without ever needing any copying, re-compiling or re-linking of programs.

Initial conversion uses simple explanatory menus. Ongoing generations inside COPE are easily set up to be automatic within your current system for doing generations.

•

•

•

In summary:

Table 4: Conversion of Existing Systems (IMS)

IMS Components

Programs

MFS

PSB‟s/DBD‟s

System Definition

Initial Gen?

No

No

Yes

Yes

Ongoing Gen?

No

Automatic

Automatic

Yes

Table 5: Conversion of Existing Systems (CICS)

CICS Components

PSB‟s/DBD‟s

Initial Gen?

Yes

Ongoing Gen?

Automatic

For components marked Yes, you use Cope facilities to generate them, and for those marked No or Automatic, you do not require any visible change to your current procedures.

28

Overview of COPE processing for COPE IMS and COPE CICS/DBCTL

COPE makes control of multiple versions of applications possible by employing a sophisticated parsing technique that analyzes all relevant source objects, builds ISPF-based control tables, and assigns each object a unique internal name. One output of the parsing and generation process de- picted in the next diagram is an IMS Stage 1 System Definition ready for assembly. It contains the required definition macros to support all the programs, transactions, and databases that were previously defined in the separate IMS environments represented by Systems “A” and “B”.

The other outputs of the system generation process are renamed DBD‟s, PSB‟s, and MFS control blocks, a set of dynamic allocation macros corresponding to each DBD in the combined environment, and a “STUBX” module for each online program. A “STUBX” module is a small control table that allows the proper version of an application program to be loaded into the message region de- pending on the Lsys being accessed.

The only outputs for COPE for CICS/DBCTL are DBD‟s and PSB‟s.

29

System

A

COPE

Parsers

System

B

COPE

Generators

COPE for

IMS

System

Figure 4: COPE for IMS - building a system

30

COPE for IMS and COPE for CICS/DBCTL Facilities

The Libset Libsets are groups of datasets that contain objects, such as PSB‟s, DBD‟s, and programs, that define an application system.

A Libset contains a related set of source modules and their associated load modules. Libsets are uniquely identified by the first two qualifiers of the dataset name. For example:

•

•

•

CSD.DEVL.PSBSOURC

CSD.DEVL.DBDSOURC

CSD.DEVL.COBOL

would all belong to the Libset called “CSD.DEVL”.

COPE‟s Libset concept is designed to provide a generalized and flexible facility with which users can model any conceivable existing library arrangement. Hierarchies of Libsets can be defined to rep- resent different environments. A promote facility controls the movement of modules through various user-defined levels of testing. When a module completes unit testing, it can be promoted to an in- tegrated testing environment with COPE‟s promotion commands. Both the unit and integration testing systems can have separate and distinct online systems defined for them, both running in the same IMS or CICS region.

For a complete description of COPE‟s Libset functions, refer to the sections “Libset Terminology” in the COPE for IMS Programmer’s Guide, and “Defining Libsets” in the COPE for IMS Administration Guide.

Support of non-COPE Development Environments

An installation may choose not to use the full COPE development facilities. For example, programs may be generated by a program generator, or they may reside in libraries that are not accessible from the COPE development facilities. COPE supports such environments at the program load-library level. In the COPE message region, a special mechanism dynamically switches the STEPLIB between concatenations of program load libraries. This means that programs (source or load) do not have to be imported into COPE. For compiling PSB‟s, DBD‟s and MFS modules, COPE provides a JCL interface that can be inserted in existing PSBGEN, DBDGEN, and MFSGEN procedures which will automatically copy them into COPE when they are compiled. No other changes to existing development environments are necessary.

Shared Dataset Capability

COPE uses an internal data management facility for storing source and load members. COPE guar- antees the uniqueness of member names for all objects under its control, by internally generating artificial names that are assigned to objects. This approach lets COPE store two or more objects with identical external names in the same dataset. COPE manages and locates objects by means

31

of indexes implemented as ISPF tables. Refer to the section “Shared Dataset Capability” in the COPE for IMS Administration Guide for complete details on this feature.

Import Facility

The COPE Import facility is used to bring objects into previously defined Libsets under COPE control. In addition, the facility can build additional logical environments from existing Libsets. Complete details on the Import facility are provided in the COPE for IMS Programmer’s Guide.

Edit Facilities

The COPE Edit facilities use the ISPF editor. No retraining of application developers is required. COPE keeps track of datasets that contain source code for application programs, DBD‟s, PSB‟s, and MFS control blocks. When an object of one of these types is modified, the COPE parsing rou- tines are automatically invoked to update the required internal control tables. If syntax errors are encountered, the edit panel is re-entered with the cursor positioned at the point of error. The COPE Edit facilities are described in the COPE for IMS Administration Guide.

SQL Call Trace Facility (COPE for IMS only)

The DL/1 and SQL Call Trace Facility is a powerful tool for application developers. It writes information from all DL/1 and SQL calls issued by the program to the IMS online log. The trace for each terminal is turned on and off via commands. The trace output is viewed from an ISPF session that extracts the desired trace data from the IMS log. The features and capabilities of the DL/1 and SQL Call Trace are described in the COPE for IMS Programmer’s Guide.

Abend Summary Screen (COPE for IMS only)

When an application program abends, COPE captures the state of important fields at the time of the abend, and outputs an abend summary screen to the terminal. It shows the meaning of the abend code, the last DL/1 call, the meaning of that call‟s status code, all Program Control Blocks (PCBs), I/O area, and Segment Search Argument (SSA) fields, the module call chain, the date the failing module was linked, and the library dataset name from which it was loaded. Hexadecimal offsets are given which will match compiler listing offsets, obviating the need to look at linkage editor maps or the dump. For further details on the Abend Summary Facility, see the section “Debugging Online Programs” in the COPE for IMS Programmer’s Guide.

Compile Facilities

COPE includes default JCL for compiling and linking COBOL source code, PSB‟s, DBD‟s, and MFS source members. You can modify the supplied procedures and tailor parameters to your standards. COPE automatically manages the compiling and storing of objects in the proper Libsets to ensure reliable operation of all defined logical environments. The COPE compile facilities are described in

32

the COPE for IMS Programmer’s Guide.

Promotion Facilities

The COPE Promotion facilities provide a mechanism that controls the movement of modules between user-defined levels of testing. For example, promotion commands can move a module from a “unit” testing environment to an “integration” testing environment. COPE internally determines the appropriate destination libraries for the objects being moved. Promotion based on “last changed date” are also supported. The promotion facilities are fully described in the COPE for IMS Program- mer’s Guide.

Export Facilities

The Export facility uses the COPE indexes to find modules and their aliases, and copy them to an external dataset or tape using their external name.

Libset groups may be exported, or all datasets within a single Libset may be exported. The latter capability is particularly useful for migrating a complete system to another geographical location.

System Generation Facilities

COPE generates an environment that supports multiple versions of application systems by parsing the required source modules and assigning unique internal names to the objects to be controlled. The parsing process produces the following outputs to support the combining of IMS systems that previously ran in separate IMS environments:

33

Table 6: Outputs from System Generation

COPE Generated Object

IMS Stage 1 Source and IMSGEN JCL

Renamed DBD‟s

COPE Product

COPE for IMS and COPE for DBCTL

COPE for IMS and COPE for DBCTL

PSB‟s that support multiple Logical Systems COPE for IMS and COPE for DBCTL and ACBGEN JCL

Dynamic Allocation Source and JCL Genera- COPE for IMS and COPE for DBCTL tion

MFS source statements with unique control COPE for IMS only block names

Control modules to manage application pro- COPE for IMS only gram loading

JCL and Control Cards to support the Start COPE for IMS only Stop Application

The COPE for IMS Administration Guide describes the system generation process.

Database and Transaction Start/Stop (COPE for IMS only)

The COPE System provides a set of online commands that allow databases and transactions to be started and stopped either singly, or in user-defined groups. These commands allow databases and transactions in a logical system to be controlled independently of other like-named databases or transactions in other logical systems.

The person stopping a database or transaction can enter a reason as a text string, which is then automatically sent to anyone who tries to use the stopped database or transaction. This helps developers communicate with each other. The Database and Transaction Start/Stop facility is described in the COPE for IMS Programmer’s Guide.

Batch JCL Facilities

Most online application systems have a batch cycle that typically, after the online shutdown, runs against a system‟s databases. COPE provides a facility to automatically converts JCL that is com- patible with any logical online system that has been defined. The conversion may be performed in batch, or when the JCL is executed. The JCL produced contains the COPE-generated names for the objects that are under COPE‟s control. If the execution-time conversion facility is used, no man-

34

ual intervention is required by the user to produce executable batch (and BMP) JCL for COPE logical systems, except for the identification of the Lsys in the JOB card.

External Authorization Interface

COPE contains exit points to allow an installation to interface any existing change control mechanism with the COPE environment. Using an exit routine, external system utilities can get external member names from the COPE control tables.

DB2 Features

Every Lsys requires a complete set of DL/1 databases and DB2 tables so that complete data independence may be enforced. The DB2 Feature allows a single DB2 system to support multiple versions of tables and views accessed by a single IMS environments. This is generally not possible without COPE.

Application programs must use unqualified table/view names. Every COPE Lsys has a unique OWNERID (Authorization Identifier) that is used to prefix all unqualified tables and views for the logical system. Whenever programs are compiled, COPE will generate an OWNERID parameter to give the user access to the uniquely qualified tables/views for the logical system. The process is transparent to application developers.

COPE will automatically extract plan and package names from DB2 catalogs and generate BIND JCL. The COPE message region has a mechanism that dynamically switches the plan name for different logical systems, so no relinking of DB2 programs is necessary.

Source/Load Module Compare

A source and load compare facility is available. It compares ISPF statistics dates, link-edit dates, and the contents of members using hash values. This allows COPE DBD, PSB, and MFS members to be compared with members in external libraries to check for discrepancies.

Fast Path

Support for the IMS Fast Path feature is included.

DBD Index Sparsing, Randomizer and Compression Exits

Different versions of DBD exits are supported for databases in separate COPE Lsys. The exit load modules must be imported into COPE. The DBD generated by COPE will then refer to the correct version of the exit in each Lsys.

35

DBCTL support for CICS and IMS

This feature may be added to the COPE for IMS product to allow CICS and IMS systems to use a single DBCTL region. The CICS systems can access the same databases as COPE Lsys‟s under IMS or may access separate sets of databases on their own.

The COPE for CICS DBCTL product implements the same DBCTL interface capabilities without the support of IMS/DC.

COPE for CICS consists of a base package and two separately priced features.

•

•

•

The base package supports CICS and allows combined CICS systems to be created

The DL/1 feature supports any number of DBCTL subsystems and manages naming conflicts within a DBCTL environment

The DB2 feature supports any number of DB2 subsystems and allows COPE systems to access DB2 tables

36

APPENDIX

Cost Justification The justification approach is similar for all products. It consists of a quantifiable „machine savings‟ justification portion coupled with a more un-quantifiable portion for reducing errors and easing repet- itive data entry operations. The following example shows a specimen calculation for reducing IMS regions; however the approach may be used for the other products.

The major costs in providing IMS regions to development users can be broadly categorized as fol- lows :

Initial Costs Summary

Direct costs (associated with IMS setup and usage):

• • • •

DASD CPU MEMORY Setup costs

Implicit Costs Summary

(for additional MVS JES local systems required to support the IMS regions):

• • • • •

System pool DASD MVS CPU overheads Memory Channels Setup costs

Operating Costs Summary (Costs associated with the daily use of the system):

• • •

MVS support (where additional MVS systems are required) IMS support CPU usage

Initial Costs Detail The following costs are directly attributable to the establishment of IMS regions.

DASD: Each IMS region requires approximately 0.73 Gigabyte(GB) of disk storage, which at about $21,000 per GB is $15,336.

CPU: The CPU used by each region varies according to a number of factors (for example, transac-

37

tion rate, complexity of transactions etc.). However there is overhead in running regions with a virtually zero transaction rate of approximately 0.1 Million Instructions Per Second (MIPS) per IMS. Assuming the capital cost of providing CPU is about $120,000 per 1 MIPS, each additional IMS region costs about $12,000.

Memory: The minimum memory requirement per IMS region is about 0.6 Megabyte (MB) which at $4,240 per MB represents about $2,544 per IMS region.

IMS Setup Costs: One week , approximately. $2,000.

Implicit Costs Detail

CSA limitations currently prevent installations from running more than 7 or 8 IMS regions in a single MVS image. Once this threshold is crossed the considerable cost of providing an additional MVS image must be taken into consideration.

DASD: Assuming the new MVS shares DASD with other development systems, an additional 11 GB is required for system datasets. The approximate cost of DASD for each additional MVS image would be $213,600.

CPU: The overheads in running additional MVS images (includes MVS, JES3, JES2, VTAM, CA7/ 11, CA-ACF2, Monitors, PR/SM etc.) amount to at least 3 MIPS. Based on the current estimated cost of $120,000 per MIP for providing additional CPU capacity, the cost of providing an additional MVS image would be approximately $360,000.

Memory: The absolute minimum requirement to run MVS/ESA would be approximately 25 MB central storage. At a cost of about $4,240 per MB, an additional MVS image (running virtually zero work) would cost $106,000.

Channels: Assuming that the new MVS image shared DASD with the original development system, an extra 25 channels would be required. At about $19,000 per channel, this amounts to $475,000 per additional MVS.

MVS Setup Costs: It would take at least 10 man weeks to plan and set up a new MVS image. A cost of around $20,000.

Operating Costs Detail

Support: Estimated 6 man days per month on support per IMS region. This represents a cost of about $2,000 per month per IMS. or $24,000 per year.

CPU: IMS Generations etc. are about 20 CPU minutes per month per IMS. This equates to about $960 per month or $11,520 per year at normal chargeout rates.

MVS Support (if additional MVS images are required): The estimated time required from Host Systems and Storage Management departments to support an MVS image is about 2.5 man weeks per month. At about $2,000 per week this equates to $104,000 per year per MVS image.

Summary of Costs

38

The major initial costs have been summarized in the accompanying graph. It illustrates that, by far, the greatest costs occur when an extra development MVS image is required to support additional IMS regions.

This situation occurs because of virtual storage constraints inherent in the IMS.ESA and MVS/ESA design. CSA becomes the major limiting factor in determining how many IMS regions can be squeezed into an MVS system.

COPE may be cost justified on the basis of combining as few as two systems even when there is excess CPU capacity available.

A copy of an evaluation performed by a major telephone company

• To: Senior Vice President Operations

Vice President Technical Services

Vice President Product Management

•

Subject: COPE Evaluation and Recommendation

COPE is a product developed by Standardware that will allow multiple images of IMS regions to operate in a single physical IMS Control region. A trial of COPE has been conducted by the Common Support Group with the aid of a Standardware representative. The following is a report of our find- ings.

Evaluation

COPE is a viable option for any future need of additional IMS control regions that may be required for the Texas division. With minimal training, we used COPE to automate several of the Data Base Administration (DBA) functions that we currently do manually. The logical systems within COPE can be set up in a manner that will eliminate the duplication of DBA work across specific testing levels. There have been some concerns about the handling of other third party vendor products but I have been assured by the Standardware representative that these can be worked out.

The integration testers report that COPE has been transparent to their online testing. There are minimum changes that needed to be made to the batch testing JCL. These JCL changes would be necessary anyway when new testing regions are added.

Currently there exists a need for new IMS testing regions to support Point of Sale (POS), Battleship,

39

Posting Cash Register, CRDL RFI, potential future A2K interfaces, and parallel testing for A2K roll- out. The current resources can not support the activities without severe impact to the maintenance of the Swift product line.

Recommendation

My recommendation is that -------- purchase COPE.

Without COPE, to establish an additional separate DB/DC environment, an additional MVS partition would need to be required. In order to accommodate this additional MVS partition, the memory on the IBM 3090-600S in the Texas data center would have to be augmented at a cost of $2,000,000 according to a memo from Fred Slim, Data Center Services, dated September 15, 1995. Additional channels must be added to the IBM 3090-600S processor for the establishment of the required LPAR at a cost of $185,000. Additional hardware cost would be approximately $100,000 per year.

With COPE, Swift could combine the multiple versions into one IMS control region, thus eliminating the need for additional IMS control regions. The upgrade required to the Texas data center would be eliminated The cost for COPE is approximately $185,000 for our configuration.

Summary

Table 7: Summary of Cost Benefits ($US)

Cost to add regions with MVS Cost to add regions upgrade using COPE

One Time Cost:

Annual Cost

$2,185,000

$100,000

$185,000

$19,500

The need to provide additional IMS regions is critical to support the non - Swift activities as described above. Consequently the decision to purchase COPE must be made in a timely manner, particularly to support the CRDL RFI application.

Prepared By: Data Base Administrator

Concurred By:

Information Systems Manager

Concurred By:

Director of Texas Operations

Documents

General Information Manual