General Information Manual
1
www.standardware.com
Email: [email protected]
Office Locations:
Standardware Incorporated
23119 Bryant Avenue
Purcell, OK 73080 USA
Tel: 405-288-2016 Fax:
405-288-1015
Standardware Incorporated
424 Pelham Manor Road
Pelham Manor, NY 10803 USA
Tel: 914-738-6382 Fax:
914-738-7136
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.
2
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.
3
Contents
Introduction .................................................................................................................................................. 8
Overview of the COPE Solution..................................................................................................................... 8
Why use COPE?..................................................................................................................................... 8
What is COPE? ...................................................................................................................................... 9
TheCOPEProducts............................................................................................................................................ 10
Presentations and Additional Information .................................................................................................. 11
The COPE Products .................................................................................................................................. 12
Table 1: COPE Products and Features ................................................................................................ 12
COPE for CICS......................................................................................................................................... 12
COPE for IMS ......................................................................................................................................... 13
COPE for CICS/DBCTL ............................................................................................................................ 14
COPEforCICS ............................................................................................................................................. 15
Introduction to COPE for CICS .................................................................................................................... 15
The Problem: ..................................................................................................................................... 15
The COPE for CICS solution: ................................................................................................................. 15
Benefits of COPE for CICS: ........................................................................................................................ 19
COPE for CICS Facilities............................................................................................................................. 20
Resource Management........................................................................................................................ 20
Resource Definition Offline .................................................................................................................. 20
CICS Table Maintenance ..................................................................................................................... 20
Online CICS Facilities .............................................................................................................................. 20
Lsys Association................................................................................................................................... 21
Online Administration ......................................................................................................................... 21
Implementing COPE for CICS..................................................................................................................... 21
4
Importing Existing CICS Regions ........................................................................................................... 21
DBCTL environment............................................................................................................................ 22
DB2 environment ............................................................................................................................... 23
Implementation tasks ......................................................................................................................... 23
Table 2: System Requirements............................................................................................................ 24
End-User Impact ................................................................................................................................. 24
COPE for IMS.............................................................................................................................................. 25
Introduction to COPE for IMS..................................................................................................................... 25
The Problem: ..................................................................................................................................... 25
The Solution: ...................................................................................................................................... 25
Benefits of COPE for IMS: ..................................................................................................................... 26
The COPE for IMS Development Environment.............................................................................................. 27
COPE for IMS Additional Features .............................................................................................................. 27
Figure 2: IMS/DC environments, before and after COPE ............................................................................ 30
COPE for CICS/DBCTL.................................................................................................................................. 31
Introduction to COPE for CICS/DBCTL......................................................................................................... 31
The Problem: ..................................................................................................................................... 31
The Solution: ...................................................................................................................................... 31
Benefits of COPE for CICS/DBCTL: ........................................................................................................ 31
Summary of Benefits ................................................................................................................................ 32
Table 3: Summary of Benefits.............................................................................................................. 32
Figure 3: CICS environment, before and after COPE .................................................................................. 33
Conversion of Existing IMS or CICS systems .................................................................................................. 34
Table4:ConversionofExistingSystems(IMS) ..................................................................................................... 34
Table5:ConversionofExisting Systems(CICS)................................................................................................... 34
Overview of COPE processing for COPE IMS and COPE CICS/DBCTL................................................................ 36
5
Figure 4: COPE for IMS - building a system ........................................................................................ 37
COPE for IMS and COPE for CICS/DBCTL Facilities ....................................................................................... 38
The Libset .......................................................................................................................................... 38
Support of non-COPE Development Environments .................................................................................... 38
Shared Dataset Capability.................................................................................................................... 39
Import Facility .................................................................................................................................... 39
Edit Facilities ...................................................................................................................................... 39
SQL Call Trace Facility (COPE for IMS only) ........................................................................................... 39
Abend Summary Screen (COPE for IMS only) ........................................................................................ 39
Compile Facilities................................................................................................................................ 39
Promotion Facilities ............................................................................................................................ 40
Export Facilities .................................................................................................................................. 40
System Generation Facilities ................................................................................................................ 40
Table 6: Outputs from System Generation ........................................................................................... 41
Database and Transaction Start/Stop (COPE for IMS only) .................................................................... 41
Batch JCL Facilities............................................................................................................................... 41
External Authorization Interface .......................................................................................................... 42
DB2 Features ..................................................................................................................................... 42
Source/Load Module Compare............................................................................................................. 42
Fast Path............................................................................................................................................ 42
DBD Index Sparsing, Randomizer and Compression Exits....................................................................... 42
DBCTL support for CICS and IMS .......................................................................................................... 43
APPENDIX ................................................................................................................................................. 44
Cost Justification....................................................................................................................................... 44
Initial Costs Summary.......................................................................................................................... 44
Implicit Costs Summary ....................................................................................................................... 44
6
Operating Costs Summary.................................................................................................................... 44
Initial Costs Detail ............................................................................................................................... 44
Summary of Costs ..................................................................................................................................... 47
A copy of an evaluation performed by a major telephone company.............................................................. 47
Evaluation .......................................................................................................................................... 47
Recommendation................................................................................................................................ 48
Summary............................................................................................................................................ 48
Table 7: Summary of Cost Benefits ($US) ........................................................................................... 48
Table of Figures
Figure 2: IMS/DC environments, before and after COPE ............................................................................................... 30
Figure 3: CICS environment, before and after COPE...................................................................................................... 33
Figure 4: COPE for IMS - building a system ............................................................................................................. 37
List of Tables
Table 1: COPE Products and Features...................................................................................................................... 12
Table 2: System Requirements................................................................................................................................... 24
Table 3: Summary of Benefits ..................................................................................................................................... 32
Table4:ConversionofExistingSystems(IMS) ........................................................................................................................... 34
Table5:ConversionofExisting Systems(CICS)......................................................................................................................... 34
Table 6: Outputs from System Generation ................................................................................................................ 41
Table 7: Summary of Cost Benefits ($US) ................................................................................................................ 48
7
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.
8
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
complicated 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.
•
•
9
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.
The COPE Products
Figure 1: COPE Products and Features
(ROAR) DB2 Feature
Region Optimization and
Reduction (ROAR) Feature
CICS Region
Management Feature
COPE for CICS
Compuware
Xpeditor
Feature
BMC DELTA
Feature
ViaSoft
SmartTest
Feature
CICS Feature
COPE for IMS
COPE for DBCTL
10
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 onsite at
your installation, as your needs may require.
11
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
Features
COPE for CICS
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
12
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 stand-alone regions .
•
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.
13
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.
14
COPE for CICS
Introduction to COPE for CICS
The Problem:
Development of CICS applications involves creating test files and databases or DB2 tables, the writing
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.
•
15
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
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 nonCOPE 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.
16
•
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.
17
•
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 accomplished 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 identicallynamed 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.
18
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
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).
19
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 re- source 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 standard 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
20
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 dif- ferent 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 desired 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.
21
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.
22
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. Every
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:
23
Table 2: System Requirements
System Component
Minimum Version/Release
MVS/ESA
4.3
CICS
3
ISPF/PDF
3.5
TSO/E
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.
24
COPE for IMS
Introduction to COPE for IMS
IBM provides the IMS/ESA program product as a means to move into the Database/Data
Communications (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.
25
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
approximately 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 comprehensive, 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.
•
26
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.
Intended 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.
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
supplies 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-
27
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:
28
•
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.
29
Figure 2: IMS/DC environments, before and after COPE
Existing IMS/DC Environment
DB2
DB2
DL/1
IM S
/DC
IM S
/DC
IM S
/DC
DL/1
Batch
Batch
Batch
DL/1
BM P
BMP
BMP
COPE for IMS environment
COPE for IMS
IMS3
DL/1
DB2
IMS1
IMS2
Batch
Batch
Batch
BMP
30
BMP
BMP
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.
31
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
Hardware
Savings
Personal Business
Productivity
Flexibility
Standardization Control
Combined Systems
Very High
Hig h
Very High
Hig h
Replicated Systems
Very High
Hig h
Very High
Hig h
CSA Saving
Very High
Library Structure
Hig h
Very High
Development Environment
Hig h
Very High
DB2 Savings
Very High
DL/1 or SQL Call Trace
Hig h
Transaction/Database
Start/Stop
Medium
Abend Summary
Medium
Hig h
Hig h
COPE provides all of the above advantages and features without any changes to application programs, ISPF, or IMS DB/DC.
32
Figure 3: CICS environment, before and after COPE
Existing DL/1 CICS Environments
DL/1
CICS
1
Batch
DL/1
CICS
2
DL/1
Batch
CICS
3
Batch
COPE for DBCTL environment containing multiple
versions of identically-named databases and programs
CICS
1
DBCTL
CICS
2
Batch
33
Batch
Batch
CICS
3
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
Initial Gen?
Ongoing Gen?
Programs
No
No
MFS
No
Automatic
PSB‟ s/DBD‟ s
Yes
Automatic
System Definition
Yes
Yes
Table 5: Conversion of Existing Systems (CICS)
34
CICS Components
Initial Gen?
Ongoing Gen?
PSB‟ s/DBD‟ s
Yes
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.
35
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
depicted 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
depending on the Lsys being accessed.
The only outputs for COPE for CICS/DBCTL are DBD‟ s and PSB‟ s.
36
Figure 4: COPE for IMS - building a system
System
A
COPE
Parsers
COPE
Generators
COPE for
IMS
System
37
System
B
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
represent 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 integrated 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 loadlibrary 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.
38
Shared Dataset Capability
COPE uses an internal data management facility for storing source and load members. COPE guarantees 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 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
routines 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.
39
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
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
Programmer'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:
40
Table 6: Outputs from System Generation
COPE Generated Object
COPE Product
IMS Stage 1 Source and IMSGEN JCL
COPE for IMS and COPE for DBCTL
Renamed DBD‟ s
COPE for IMS and COPE for DBCTL
PSB‟ s that support multiple Logical Systems
and ACBGEN JCL
COPE for IMS and COPE for DBCTL
Dynamic Allocation Source and JCL Generation
COPE for IMS and COPE for DBCTL
MFS source statements with unique control
block names
COPE for IMS only
Control modules to manage application program loading
COPE for IMS only
JCL and Control Cards to support the Start
Stop Application
COPE for IMS only
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
compatible 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 man41
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.
42
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.
•
•
•
43
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
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 repetitive
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 follows :
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
44
$21,000 per GB is $15,336.
CPU: The CPU used by each region varies according to a number of factors (for example, transaction 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
45
per month. At about $2,000 per week this equates to $104,000 per year per MVS image.
46
Summary of Costs
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
findings.
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
47
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,
Posting Cash Register, CRDL RFI, potential future A2K interfaces, and parallel testing for A2K rollout. The current resources cannot 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:
$2,185,000
$185,000
Annual Cost
$100,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
48
Concurred By:
Information Systems Manager
Concurred By:
Director of Texas Operations
49