General Information Manual

605
-1

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
605
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

General Information Manual

  1. 1. General Information Manual
  2. 2. www.standardware.com Email: info@standardware.com 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. 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. 3. 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 iii
  4. 4. 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 iv
  5. 5. Introduction Overview of the COPE Solution The family of COPE products is designed to enhance productivity, simplify administration and main- tenance, and reduce machine resource requirements. Each product in the family addresses a dis- tinct 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 prod- ucts. 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 si- multaneously, 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 contain- ing 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. 5
  6. 6. What is COPE? COPE is a multi-platform application that allows an installation to operate separate and distinct ver- sions of related applications: • IMS Data Base/Data Communications (DB/DC) applications under one IMS control region or un- der multiple CICS regions accessing a single DBCTL region • Multiple CICS region images operating within a single CICS region and accessing multiple ver- sions 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 op- eration 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 sepa- rate 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. 6
  7. 7. 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 BMC DELTA Feature Feature ViaSoft CICS Feature SmartTest Feature COPE for IMS COPE for DBCTL 7
  8. 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. 8
  9. 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 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 ex- ample, 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-spe- cific 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 def- initions 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 stand- alone regions . 9
  10. 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 pro- grams. The features include: • The Compuware Xpeditor Feature This feature supports interactive debugging with the Compuware Xpeditor product. Multiple us- ers 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. 10
  11. 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 sys- tem 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 pro- cess 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 11
  12. 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 re- gions. 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 exam- ple, 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 auto- matically, a feature known as Lsys Synchronization. The automatic propagation may be custom- ized separately for particular types of resources. 12
  13. 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 mul- tiple 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 13
  14. 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 stor- age 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). 14
  15. 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 plat- form 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 func- tions (under CICS/ESA Version 4.1). The data entry screens are similar to the CICS CEDA trans- action 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 stan- dard ISPF editor. If Lsys synchronization applies to the Lsys and table type being edited, any chang- es 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 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 de- 15
  16. 16. sired degree. The exit allows access to RACF or ACF2 authorization facilities, or any security prod- uct using the SAF interface. Online Administration The CICS transaction COPE allows authorized COPE for CICS administrators to perform online ad- ministrative 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 par- ticular 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 specifica- tion 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 administra- tor 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. 16
  17. 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 devel- opment 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: 17
  18. 18. 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 sys- tems 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 re- quired in the COPE environment. 18
  19. 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- 19
  20. 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 facil- ities for controlling the movement of modules through the hierarchy via “promotion” commands. 20
  21. 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 oth- er, 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 mod- ules 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 sup- port 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: 21
  22. 22. • Full DBRC support This allows dynamic timestamp extraction for timestamp recovery. All DBRC commands are sup- ported • 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 in- dividual date and time centrally specified, and controls the enforcement of the date/time specifi- cation without any special online operator action or batch JCL changes. 22
  23. 23. Figure 2: IMS/DC environments, before and after COPE Existing IMS/DC Environment DB2 DB2 IM S IM S IM S DL/1 DL/1 DL/1 /DC /DC /DC Batch Batch Batch BM P BMP BMP COPE for IMS environment COPE for IMS DB2 IMS3 DL/1 IMS1 IMS2 Batch Batch Batch BMP BMP BMP 23
  24. 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 de- velopment 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 envi- ronment 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. 24
  25. 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 Hardware Personal Business Flexibility Standardiza- Productivity Savings tion Control Combined Systems Very High High Very High High Replicated Systems Very High High Very High High CSA Saving Very High Library Structure High Very High Development Environ- High Very High ment DB2 Savings Very High High DL/1 or SQL Call Trace High Transaction/Database Medium High Start/Stop Abend Summary Medium COPE provides all of the above advantages and features without any changes to application pro- grams, ISPF, or IMS DB/DC. 25
  26. 26. Figure 3: CICS environment, before and after COPE Existing DL/1 CICS Environments CICS CICS CICS DL/1 1 DL/1 2 DL/1 3 Batch Batch Batch COPE for DBCTL environment containing multiple versions of identically-named databases and programs CICS 1 DBCTL CICS 2 CICS Batch Batch Batch 3 26
  27. 27. Conversion of Existing IMS or CICS systems • The conversion process combines or replicates existing systems without recompiling or re- linking 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 gener- ate 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 automati- cally 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) 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. 27
  28. 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 pre- viously 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 environ- ment, 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. 28
  29. 29. Figure 4: COPE for IMS - building a system System COPE System A Parsers B COPE Generators COPE for IMS System 29
  30. 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 de- fine 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 test- ing 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-li- brary 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 30
  31. 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 con- trol. 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 en- countered, 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 infor- mation 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 31
  32. 32. the COPE for IMS Programmer’s Guide. Promotion Facilities The COPE Promotion facilities provide a mechanism that controls the movement of modules be- tween 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: 32
  33. 33. 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 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 de- velopers communicate with each other. The Database and Transaction Start/Stop facility is de- scribed 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- 33
  34. 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 mecha- nism 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 inde- pendence may be enforced. The DB2 Feature allows a single DB2 system to support multiple ver- sions 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 log- ical 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. 34
  35. 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 35
  36. 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- 36
  37. 37. tion rate, complexity of transactions etc.). However there is overhead in running regions with a vir- tually 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 re- gion 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 cen- tral 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 37
  38. 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 op- erate 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 min- imum changes that needed to be made to the batch testing JCL. These JCL changes would be nec- essary anyway when new testing regions are added. Currently there exists a need for new IMS testing regions to support Point of Sale (POS), Battleship, 38
  39. 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: $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 Concurred By: Information Systems Manager Concurred By: Director of Texas Operations 39

×