Overview of the COPE for IMS/DC Programmer’s Guide

The COPE System allows an installation to operate separate and distinct versions of related IMS DB/DC applications under one IMS control region.

Without COPE, separate DB/DC environments are typically required to support unit testing, system testing, or customized versions of the same application system. Some installations devise complicated, manual naming conventions to allow multiple versions of programs and databases to co-exist in one IMS system. COPE automates and controls the renaming process and allows the operation of multiple versions of an application system in one IMS Control Region.

Throughout the COPE documentation, you will encounter the terms: Physical system (or Psys) and Logical system (or Lsys). A Psys refers to a real executing IMS control region. A Lsys refers to a version of an application system that executes in the COPE-generated physical IMS control region.

COPE Lsys's are built and maintained with either:

  1. The COPE ISPF Development Facility, or,
  2. An External COPE Interface that may be added to the PSB, DBD, and MFS compile procedures.

The Development Facility operates under ISPF and uses the ISPF Editor, and will not be difficult to learn for programmers already familiar with ISPF. The External COPE interface allows your existing development environment to be used with no change to the current development practices. Programs will run in COPE using your current load libraries, without any copying.

A powerful feature of COPE is its ability to capture and browse DL/1 calls for programs running in an IMS message region. The DL/1 call trace is turned on and off by commands issued when connected to an IMS/DC session. The trace is then viewed from an ISPF session.

In addition to the full function COPE ISPF system there is a COPEUSER application which allows a developer or user to access all COPE information in READ mode as well as providing an interface to the trace facilities.

How COPE Works

COPE contains two parts: one that operates under ISPF, and one that executes in IMS message regions.

The ISPF part of COPE produces an environment that lets IMS operate several Lsys's within a single Psys, by parsing information from source modules into ISPF tables, and then regenerating DBDs, Dynamic Allocation Macro specifications, IMS/VS Stage 1 source specifications and PSBs for the combined system.

The IMS part of COPE controls the operation of Lsys's within the single physical IMS system that COPE generates. A Control database is used to record the state (started or stopped) of databases and transactions under COPE control, and tracks the name of the Lsys that a user is connected to. COPE provides transactions to start and stop databases and transactions one at a time or in user-defined groups.

All naming is automatically controlled by the COPE system. The COPE interfaces must be used for all development work associated with a COPE environment.

Application Programmer Responsibilities

If the COPE External Interface is used, the application programmer needs to:

  • Understand that when a PSB, DBD, or MFS source module is recompiled, a job will be generated to import it into COPE.
  • Another job will be generated to recompile a modified version of the module for use by COPE.
  • Be familiar with the Logon, Start/Stop, Call Trace and Abend Summary features of the COPE for IMS/DC online system (see IMS Facilities).

If the full COPE Development Environment is used, the application programmer needs to:

  • Be familiar with the COPE Edit, Browse, and Import facilities.
  • Understand the LIBSET hierarchy that has been defined by the installation, and understand LIBSET terminology (see "Libset Terminology").
  • Be able to import, compile, and test programs using the COPE facilities (see "Accessing ISPFfacilities”).
  • Be familiar with the Logon, Start/Stop, Call Trace and Abend Summary features of the COPE for IMS/DC online system (see "IMS Online Facilities").
  • Interface with the person administering the COPE environment to generate PSBs, DBDs, and ACBs.

The COPE Parsers

The IMS/DC system controls its environment with information supplied in DBDs, PSBs, MFS, Stage 1 and Dynamic Allocation source members. Since COPE for IMS/DC does not modify IMS code at execution time, a technique is required to obtain the same type of information for the manipulation of the objects that COPE controls.

A convenient method of extracting the information is by parsing the same source that drives IMS.

This allows COPE to adapt to existing environments and requires no re-entry of information by system or application programmers.

COPE parses DBDs, PSBs, and MFS control blocks to allow the renaming of objects required to run multiple logical environments in one IMS/DC system. The parsed tokens are maintained in ISPF tables in a form that allows the information to be manipulated without errors. The COPE compile processes for DBDs, PSBs, and MFS control blocks, generate a new module from the ISPF tables and compile the generated module rather than the original source. If developers look at the compiler output, they will notice statements in a different order, and the suppression of all comments.

The original source is maintained in PDS members. It may be accessed by the ISPF editor provided in the 'full development' COPE environment. When a change is made with the editor, the source is automatically re-parsed without any specific user actions. If an error is detected, the EDIT session is re-entered with the cursor positioned at the error. If the user wishes to exit without correcting an error, a CANCEL command may be issued. When a module with an error is compiled, no source will be generated, and the compile will fail.

If the COPE External Interface is used, a source module will be imported, and will replace any existing source module associated with the Lsys.

A check that all source modules have been parsed may be made with Option B;2.6. This will generate a batch job that detects unparsed modules and invokes the parser for each. Any errors encountered are noted in the listing (they are surrounded by "********" indicators), and it is the application programmer’s responsibility to correct any problems by using the COPE editor.

Optionally, using the full COPE development environment, application programs may be parsed if they are COBOL or Assembler. The parse process extracts COPYLIB member names and static calls. In Assembler source, macros are extracted and treated as COPYLIB members. If the application source is not COBOL or Assembler, the COPYLIB and call information may be entered via the i/o specification facility described later.

It should be noted that specification of the COPYLIB and macros used by applications is only required if they are maintained in a COPE "shared" library dataset. Sharing of a dataset is accomplished by renaming all members within it. Referenced members have to be extracted and renamed before a compile.

In the case of a non-shared library, the information is for documentation only.

How to use this guide

If the full COPE development environment is to be used, the following topics should be read:

If the External Interface is to be used, the following sections should be read:

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*