DATA PROPAGATOR MVS/ESA VERSION 1 RELEASE 2
Contents


Announcement Letter Number 293-133 dated March 16, 1993
US - Last Revised on March 16, 1993



Brief Description of Announcement, Charges, and Availability

       The IBM Data Propagator (TM) MVS/ESA (TM) (DProp (TM) MVS/ESA)
is a licensed program that is designed to help manage the coexistence
of the IBM hierarchical technology of the IMS/ESA (R) Database
Manager with the relational technology of DATABASE 2 (TM) (DB2 (R)).
For new applications, it provides flexibility in choosing the
database manager (IMS/ESA Database Manager or DB2 on MVS) that best
matches the application requirements.
       DProp is designed to maintain the consistency between an
IMS/ESA Database Manager copy and a DB2 copy of the same data.
       DProp allows the coexistence of IMS/ESA Database Manager and
DB2 applications accessing the original and a copy of the same data.
o   IMS/ESA Database Manager applications can access the IMS/ESA data
    copy through the IMS DL/I call interface.
o   DB2 applications can access the DB2 copy of the same data through
    the DB2 SQL interface.
       DProp assists customers implementing the Information Warehouse
(TM) framework to deliver data to informational users.
       DProp Version 1 Release 1 provided the ability to
automatically and selectively take the changes made by applications
to IMS/ESA databases and apply those changes to DB2 tables.  DProp
Version 1 Release 2 is designed to provide the additional ability to
automatically and selectively take changes made by applications to
DB2 tables and apply those changes to IMS/ESA databases, without
having to convert existing applications (for programs using DB2's IMS
attach facility).  In both releases, integrity is provided via
standard IMS recovery techniques.  Also added to Release 2 are
enhanced mapping capabilities and language support, which enables
exit routines to be written in COBOL/370 (TM), PL/I 370, and C/370
under the IBM Systems Application Architecture (R) (SAA (TM))
AD/Cycle (R) Language Environment (TM)/370 (LE/370).
       The first customer shipment of DProp will be by June 25, 1993,
to an already selected set of customers participating in a validation
program.  This shipment will indicate that IBM quality objectives for
DProp have been achieved.
       Once product availability readiness is confirmed by those
customers within each of their environments, IBM will provide
availability and ordering information.
       Planned Availability Date:  General availability will be
announced at a later date.
 (TM) Trademark of International Business Machines Corporation.
 (R) Registered trademark of International Business Machines
   Corporation.
IN BRIEF . . .
       DProp Version 1 Release 2 provides:
o   One-way propagation from IMS/ESA Database Manager to DB2.
o   One-way propagation from DB2 to IMS/ESA Database Manager.
o   Two-way propagation from IMS/ESA Database Manager to DB2, and
    from DB2 to IMS/ESA Database Manager.
o   In addition to the two generalized mapping cases of Release 1, a
    third mapping case for the support of IMS/ESA segments that
    contain repeating groups.
o   Two mapping options
    -   A WHERE clause which can be used to specify conditions (based
        on field values) under which an updated IMS/ESA Database
        Manager segment is to be propagated to DB2.  The WHERE clause
        allows IMS segment types containing redefined data to map to
        different DB2 tables.
    -   A PATH DATA option which can map non-key fields of ancestor
        segments.
o   LE/370 language support, which enables customers to write exit
    routines in COBOL, PL/I, and C.
o   A DL/I load utility.
o   Usability enhancements on panel applications.
o   Enhancements in existing utilities.


Customer Letter Section

DESCRIPTION
       Propagation of Changed Data from IMS/ESA to DB2 and/or from
DB2 to IMS/ESA
       The purpose of propagation is to maintain consistency between
two copies of the same data, where one copy of the data is stored in
IMS/ESA databases and the other copy is stored in DB2 tables.  DProp
thus allows the coexistence of IMS/ESA and DB2 applications accessing
the same data.  With DProp:
o   IMS/ESA applications can access the IMS/ESA data copy through the
    IMS/ESA DL/I call interface.
o   DB2 applications can access the DB2 copy of the same data through
    the DB2 SQL interface.
GROWTH ENABLEMENT -- ACCESS TO ENTERPRISE DATA:  DB2 provides an
ideal base on which to build distributed applications.  Many
customers are following the Information Warehouse framework and are
maintaining read-only copies in DB2 of their heterogeneous
operational data stores and are introducing enterprise-wide access to
those copies.  As a consequence of DProp's use, knowledge workers
have more extensive, more flexible and more timely access to their
operational enterprise data, which is updated in IMS databases
because they can now access it using DB2 distributed relational
technology.
BUSINESS SOLUTIONS -- ENABLING NEW APPLICATIONS:  DProp allows
customers who are developing new applications more flexibility in
choosing database managers to meet the various data access
requirements of the applications.
       For example, for a given online teleprocessing application, a
customer may use IMS/ESA DEDBs to ensure high data availability and
low cost per transaction.  In addition, the customer may choose to
use DB2 for that part of the application that demands set-oriented
analysis or update.  Some part of the IMS/ESA Data Entry DataBases
(DEDBs) and the DB2 tables may be implemented as fully consistent
copies of the same data, with updates applied to one by an
application program being synchronously applied to the other by
DProp.
       DProp can help speed application development by allowing
customers whose operational data is in IMS/ESA databases to implement
new decision support applications using DB2 tables, and possibly
taking advantage of existing end user tools like Query Management
Facility (QMF (TM)).  By enabling non-DP-oriented users to
participate in providing solutions to their own backlog of
applications, a customer can increase the potential for growth.  In
some estimates, about half of the total customer application backlog
can today be satisfied via end user tools, and most end user decision
support tools are developed based on relational technology.
INVESTMENT PROTECTION -- ASSET PROTECTION:  Present IMS/ESA customers
have a significant investment in their operational applications.
These applications are the backbone of their business, are performing
well, and do not necessarily have a business need for redesign.
DProp should significantly help customers who wish to extend their
IMS/ESA Database Manager applications with new components based on
DB2 technology, without affecting any existing IMS/ESA applications.
       Also, DProp is designed to allow migration in an orderly
fashion.  For customers who wish to migrate some of their
applications from IMS/ESA databases to DB2, DProp provides a
structured, low risk way to do this over time.  Once having
implemented DProp, customers can migrate application components or
programs one at a time.  The migrated programs will access the DB2
copy of the data through the SQL interface, while the programs not
yet migrated continue to access the IMS/ESA copy of the data through
the DL/I call interface.
PRODUCT POSITIONING
       DProp is designed to help manage the coexistence of the IBM
hierarchical technology of IMS/ESA Database Manager with the
relational technology of DB2.  For new applications, it provides
flexibility in choosing the database manager (IMS/ESA Database
Manager or DB2) that best matches the application requirements.
       DProp is part of the Information Warehouse framework,
providing access and transport mechanisms that automate the transfer
and movement of data so that the right business data is delivered to
the people who need it.
       DProp is designed to allow customers to replicate selected
IMS/ESA data in DB2 tables and to keep both copies of the data
consistent.  DProp can be used to automatically update DB2 tables
when the corresponding information in the IMS/ESA data base is
updated.  By this means, DB2 applications can see up-to-date IMS/ESA
changes without the user having to convert production IMS/ESA
applications or periodically copy IMS/ESA data bases to DB2 tables.
DProp also automatically updates the IMS/ESA data bases when the
corresponding information in the DB2 tables is updated.
       DProp is supported by Data Extract (DXT (TM)) which can be
used:
o   To define the mapping, needed by DProp, between the IMS/ESA
    database and DB2 table definitions of the DProp-maintained
    copies.
o   To perform the selection and extract of data from one copy and
    assist its initial load into the other.

TECHNICAL INFORMATION
SPECIFIED OPERATING ENVIRONMENT
MACHINE REQUIREMENTS:  DProp is designed to operate on any processor
supported by MVS/ESA SP Version 3 Release 1.1 or later releases.
There are no special machine configurations required for DProp.
       Most DProp modules are loaded above the 16 megabyte (16MB)
line and can be stored, if desired, in the Link Pack Area.
PROGRAMMING REQUIREMENTS:
OPERATING SYSTEM AND SUPPORT PROGRAMS:  DProp requires the following
programs or their equivalents both during and after installation:
o   MVS/SP (TM) JES2 Version 3 Release 1.1 (5685-001) or MVS/SP JES3
    Version 3 Release 1.1 (5685-002), JES Version 4 Release 1
    (5695-047), or MVS/SP JES3 Version 4 Release 1 (5695-048)
o   MVS/DFP (TM) Version 3 Release 1.1 (5665-XA3), if using IMS/ESA
    Version 3
o   MVS/DFP Version 3 Release 2 (5665-XA3), if using IMS/ESA
    Version 4
o   TSO/E Version 2 Release 1 (5685-025)
o   SMP/E Version 1 Release 5 (5668-949)
o   ISPF Version 3 Release 3 (5685-054)
o   ISPF/PDF Version 3 Release 3 (5665-402)
o   Assembler H Version 2 Release 1 (5668-962)
o   DFSORT/MVS Version 1 Release 11 (5740-SM1) or equivalent product
o   For IMS/ESA to DB2 propagation:
    -   IMS/ESA Database Manager Version 3 (5665-408), with Data
        Capture SPE or IMS/ESA Database Manager Version 4 (5685-012).
    -   IMS/ESA Transaction Manager Version 3 (5665-409), with Data
        Capture SPE or IMS/ESA Transaction Manager Version 4
        (5685-013).
    -   IMS/ESA Transaction Manager is only needed for online
        processing if propagating where Message Processing Program
        (MPP), IMS Fast Path (IFP), and non-DataBase Control-Batch
        Message Processing (non-DBCTL BMP) regions are used.
    -   DB2 Version 2 Release 2 (5665-DB2), DB2 Version 2 Release 3,
        or DB2 Version 3 (5685-DB2).
o   For DB2 to IMS/ESA synchronous propagation:
    -   IMS/ESA Database Manager Version 4 (5685-012) to support DB2
        data capture.
    -   IMS/ESA Transaction Manager Version 4 (5685-013).
    -   IMS/ESA Transaction Manager is only needed for online
        processing if propagating where MPP, IFP, and non-DBCTL BMP
        regions are used.
    -   DB2 Version 3 (5665-DB2).
OPTIONAL AND RELATED PROGRAMS:
o   Data Extract (DXT) Version 2 Release 5 (5668-788).
o   QMF/MVS Version 3 Release 1.1 (5706-254).
o   IMS Batch Terminal Simulator (BTS) Version 1 Release 2 (5668-948)
    or BTS Version 1 Release 2 (5668-948) with batch/online SPE, if
    propagating DB2 on MVS to IMS/ESA.
o   RACF (TM) Version 1 Release 9 (5740-XXH) or equivalent product.
o   LE/370 Version 1 Release 2 (5688-198).
    -   IBM SAA AD/Cycle COBOL/370 Version 1 Release 1 (5688-197)
    -   IBM SAA AD/Cycle C/370 Version 1 Release 1 (5688-216)
    -   IBM SAA AD/Cycle PL/I 370 Version 1 Release 1 (5688-235)
COMPATIBILITY:  DProp Version 1 Release 2 is upwardly compatible with
DProp Version 1 Release 1.
LIMITATIONS:  DB2-to-IMS/ESA propagation is only supported for SQL
updates issued through the IMS/DB2 attach.
       DB2-to-IMS/ESA propagation is also not supported for updates
to remote DB2 tables -- DB2 tables in a DB2 system other than the
local DB2 system connected to the updating application program.
       If customers need to propagate DB2 updates issued by programs
using TSO attach or Call Attachment Facility (CAF) attach, they
should investigate running these programs with IMS/ESA attach.  They
should protect propagated tables against DB2 updates performed in
TSO, CICS (TM), or CAF; these environments are not supported for
synchronous propagation.
       Propagation is not supported for hierarchic sequential access
method (HSAM), simple HSAM (SHSAM), main storage data base (MSDB), or
generalized sequential access method (GSAM).
       Propagation is supported for secondary indexes.  However, it
is not supported for user data in secondary indexes when the
secondary index is being treated as a separate database.
       Data propagation is not supported during execution of:
o   IMS/ESA data base recovery utilities
o   IMS/ESA hierarchic direct (HD) and hierarchic indexed sequential
    method (HISAM) reload utilities
o   DB2 utilities
       Not all logical relationship delete rules are supported for
data propagation.
o   Logical child segments must have a delete rule of VIRTUAL.
o   Logical parent segments involved in IMS/ESA bidirectional
    relationships must have a delete rule of LOGICAL or PHYSICAL.
o   Logical parent segments involved in IMS/ESA unidirectional
    relationships must have:
    -   A delete rule of PHYSICAL (if propagated by TYPE=E PRs, which
        support one- and two-way propagation).
    -   A delete rule of PHYSICAL or LOGICAL (if propagated by TYPE=L
        or TYPE=F PRs, which support only one-way IMS/ESA-to-DB2
        propagation).
SYNCHRONOUS PROPAGATION:  The following considerations and
restrictions apply to synchronous propagation only:
o   Synchronous IMS/ESA-to-DB2 propagation does not run in the CICS
    environment.  However, CICS applications should access propagated
    DB2 tables and IMS/ESA databases in read-only mode through their
    respective attach services.
o   In case of an XRF takeover, DB2 must be started manually on the
    alternate XRF processor.  (A DProp license is also required for
    the alternate processor.)
o   Updating IMS/ESA systems and the DB2 system must run on the same
    MVS/ESA image.  (Therefore, if customers are performing
    intersystem data sharing, all IMS/ESA systems updating a
    propagated database must run on the same MVS/ESA image.)
o   DProp does not support synchronous propagation of the same data
    to more than one DB2 system.
o   IMS/ESA application programs must not issue ROLS calls with a
    token or SETS calls.  IMS/ESA batch programs must not issue any
    kind of ROLS calls.  These restrictions also exist for IMS/DB2
    mixed-mode programs.
ASYNCHRONOUS PROPAGATION:  The following considerations and
restrictions apply to asynchronous propagation only:
o   Implementation of asynchronous data propagation can be somewhat
    complex because of the programs customers must write.
o   Asynchronous propagation supports only one-way IMS/ESA-to-DB2
    propagation.
o   A receiver program, which calls the Relational Update Program
    (RUP), can run in the following environments:
    -   IMS/ESA batch or BMP region
    -   TSO foreground or TSO batch using the DB2/TSO attach
    -   DB2 CAF (Call Attachment Facility)
           In TSO and CAF environments, customers cannot issue DL/I
    calls from their programs (that is, from the three DProp exit
    routines or from a program that invokes DProp asynchronously).
o   When IMS/ESA and DB2 are on different MVS/ESA images, the DProp
    Consistency Check Utility (CCU) cannot be used.
SYNCHRONOUS AND ASYNCHRONOUS PROPAGATION:  The following
considerations apply if you are doing both synchronous and
asynchronous propagation:
o   It is possible to propagate the same data both synchronously and
    asynchronously from IMS/ESA to DB2.
o   When data is propagated both synchronously and asynchronously,
    two DProps are required.
PERFORMANCE CONSIDERATIONS:  The impact of data propagation on
performance is dependent on the load of the IMS system, its CPU
utilization, and the percentage of updates to be propagated.  The
additional I/Os and CPU time required for data propagation will
extend IMS internal response time (input-queue to output queue), but,
in many cases, if the capacity in the system (CPU utilization and
region occupancy) is available to absorb these updates, end-user
response time will not be impacted.
       The performance impact during propagation will depend mainly
on:
o   How many updates a batch program or transaction performs per
    execution.
o   The number of those updates that are to be propagated.
o   The capacity of the system to absorb these updates.

SYNCHRONOUS PROPAGATION:  With synchronous IMS/ESA-to-DB2 data
propagation, the extra performance cost in terms of CPU and I/O on
updating IMS/ESA applications mostly results from the SQL calls
issued by DProp to propagate the changed data.  DProp does try to
minimize the impact by doing such things as:
o   Using static rather than dynamic SQL statements to propagate
    IMS/ESA database changes to the target DB2 tables.
o   Exploiting the high-performance services of the MVS Virtual
    Lookaside Facility (VLF).  (Use of VLF, for example, greatly
    reduces the number of SQL calls required to access information in
    the DProp directory.)
o   Using a WHERE clause on the SQL statement for columns of DB2
    indexes.  For medium and large tables, this results in a DB2
    matching index scan.
       IMS/ESA performance during IMS/ESA-to-DB2 synchronous
propagation is also affected by how DB2 applies the updates to its
tables.  There will be cases where IMS/ESA requires few I/Os (for
example, for physical sequential processing of HDAM or DEDB
databases), but DB2 requires many I/Os.
       With synchronous DB2-to-IMS/ESA propagation, the performance
cost is largely due to the time required by the updating IMS/ESA
calls needed to update the target IMS/ESA databases.
       The performance of DB2-to-IMS/ESA propagation might also be
affected by the number of DB2 log records written by the DB2 data
capture function.
ASYNCHRONOUS PROPAGATION:  With asynchronous data propagation,
customers have more control over the potential performance impact,
since they postpone DB2 updates to out-of-peak/"batch-window" times.
       If customers request that the IMS/ESA Asynchronous Data
Capture exit log change segments to the log, then the main
performance impact on updating applications is writing the additional
log records.  This performance impact is usually insignificant,
unless the application's performance is constrained by the amount of
IMS/ESA logging or the volume of data logged is extremely heavy.
       If customers request that their own Asynchronous Data Capture
exit get control, then the main performance cost on updating
applications is typically the processing performed in the exit
routine.  The impact depends, among other things, on how many times
propagated segments are updated and the exit routine is invoked.
PLANNING INFORMATION
CUSTOMER RESPONSIBILITIES:  If delete rules incompatible with data
propagation are currently being used, the data base administrator
(DBA) must change them before performing data propagation.
Application programs may also require changes in this situation.
       DProp generalized mapping logic requires that DB2 tables have
a primary key.
       For one-way IMS/ESA-to-DB2 propagation, implementation of DB2
referential integrity relationships between propagated tables is
optional.  For one-way IMS-to-DB2 propagation and two-way
propagation, implementation of DB2 referential integrity
relationships between propagated tables is strongly recommended.  The
implemented DB2 referential integrity relationships should be
compatible with the parent/child relationships between the IMS/ESA
segments.
SYNCHRONOUS PROPAGATION:  The following considerations apply to
synchronous propagation only:
o   A single DProp system can be invoked by more than one IMS/ESA
    system.  Note that all IMS/ESA systems accessing the same DProp
    system should use the same RECON.
o   Every DProp system propagates to one and only one DB2 system.
    Therefore, if customers want to synchronously propagate different
    IMS/ESA data to DB2 tables in more than one DB2 system (for
    example, a production and an information center), multiple DProps
    (one for each DB2 system) must be defined.
o   DProp requires that all propagation done by one IMS/ESA dependent
    or batch region be done by the same DProp system to the same DB2
    system.  Synchronous propagation done by different DProp systems
    should be performed in a distinct set of IMS/ESA batch and
    dependent regions.
o   Customers can recover both IMS/ESA and DB2 data copy to their
    most recent state.  If they want to recover IMS/ESA and DB2 data
    to a previous state, note that there is no automated way to
    recover both IMS/ESA and DB2 to the same time stamp.  Therefore,
    customers will have to synchronize time stamp recoveries.
o   If customers are using DB2 with the package bind function, it
    will let them bind DProp programs as separate units called
    packages; some of these DProp programs need to be included in the
    propagating application's plan.  This means that future changes,
    for example, new or changed PRs, will not require rebinding plans
    for all affected applications.
ASYNCHRONOUS PROPAGATION:  The following considerations apply to
asynchronous propagation only:
o   Customers can propagate the same data to more than one DB2
    system.  Since one DProp is connected to only one DB2 system (the
    DB2 system that contains the DProp directory tables), customers
    will need one DProp for each DB2 to propagate to more than one
    DB2 system.
o   When IMS/ESA and DB2 are on different MVS/ESA images, DProp must
    reside on the same MVS/ESA image as DB2.
    -   If the different MVS/ESA images are at the same site (local),
        the IMS/ESA data base descriptor library (DBDLIB) for the
        IMS/ESA data being propagated must either exist on shared
        DASD (so DProp can access it) or be copied to the MVS/ESA
        image where DProp resides.
    -   If the different MVS/ESA images are at different sites
        (remote), shared DASD for the IMS/ESA DBDLIB is not possible.
        Therefore, a copy of the IMS/ESA DBDLIB for the propagated
        data must be shipped to the MVS/ESA image where DProp
        resides.
SECURITY, AUDITABILITY AND CONTROL
       The announced program works with the security and auditability
features provided by the IMS/ESA Database Manager and DB2 database
managers.  RACF can be used to protect the data propagator data sets.
       Special consideration should be given to IMS/ESA Database
Manager data with field-level sensitivity and dependent segments that
are propagated as a result of cascade delete.  Also, any IMS/ESA
database system which is currently providing 24 x 7 availability will
need to have its availability requirements re-evaluated before using
DProp.
       User management is responsible for evaluation, selection, and
implementation of security features, administrative procedures, and
appropriate controls in application systems and communication
facilities.
ORDERING INFORMATION
       Ordering information will be available at announcement of
general availability.
TERMS AND CONDITIONS
LICENSING:  The program in this announcement is licensed under the
terms of the IBM Customer Agreement.
VARIABLE CHARGES APPLY:  Yes.
SYSTEM/390 (R) MULTIPLE OPERATING SYSTEMS -- PROCESS RESOURCE/SYSTEM
MANAGER (TM) (MOSP-PR/SM (TM)):  Charge Option Attachment applies for
graduated charge programs licensed to a qualifying machine.
INSTALLATION LICENSE OR LOCATION LICENSE APPLIES:  No.  A separate
license is required for each machine on which the licensed program
materials will be used.
EDUCATIONAL ALLOWANCE:  A 15% educational allowance is applicable
toward eligible license charges and is available to qualifying
institutions in accordance with the Educational Allowance Attachment.
       The educational allowance may not be added to any other
discount or allowance.
VOLUME DISCOUNT:  Not applicable.
VERSION UPGRADES:  Version-to-version upgrade credits apply.
                                                   Single
Replaced Program         Replacement Program      Version
Program      Program     Program        Program   Charging
Number       Name        Number         Name      Applies
5685-124     Data
              Propagator To a follow-on if any      N/A
WARRANTED:  Yes.
LICENSED PROGRAM MATERIALS AVAILABILITY:  Restricted Materials -- No.

This licensed program will be available without source licensed
program materials.  It will be available in object code.
TESTING PERIOD:  Basic License -- Two months.  DSLO -- Not
applicable.
PROGRAM SERVICES:  Central Service, including the IBM Support Center,
will be available until discontinued by IBM upon six months' written
notice.
       Central Service, including the IBM Support Center, for DSLO
licenses will be provided only through the customer location
designated for the basic license.
CHARGES
Program Number
5685-124
                                  Basic      DSLO
        Basic       DSLO          Graduated  Graduated
        Graduated   Graduated     Monthly    Monthly
        One-Time    One-Time      License    License
Group   Charge      Charge        Charge     Charge
 18     $  8,780     $  6,585      $  182     $  136
 20       11,420        8,570         237        178
 25       14,810       11,100         308        231
 28       19,250       14,430         401        300
 29       25,070       18,800         521        390
 30       32,590       24,440         678        509
 31       42,330       31,750         882        661
 32       48,740       36,550       1,015        760
 35       56,090       42,060       1,165        875
 38       64,290       48,210       1,335      1,000
 40       74,080       55,560       1,540      1,155
 50       92,610       69,450       1,925      1,440
 60      115,850       86,890       2,405      1,805
 70      144,700      108,500       3,010      2,255
 80      180,950      135,700       3,765      2,820
 90      208,100      156,050       4,330      3,245
100      239,300      179,450       4,980      3,730
                                  MOSP Basic MOSP DSLO
        MOSP Basic  MOSP DSLO     Graduated  Graduated
        Graduated   Graduated     Monthly    Monthly
        One-Time    One-Time      License    License
Group   Charge      Charge        Charge     Charge
 18     $  8,780     $  6,585      $  182     $  136
 20       10,100        7,580         210        157
 25       13,120        9,840         273        204
 28       17,040       12,770         354        265
 29       22,160       16,620         462        345
 30       28,830       21,630         600        450
 31       37,460       28,090         780        585
 32       45,530       34,150         949        710
 35       52,410       39,310       1,090        817
 38       60,190       45,130       1,250        939
 40       69,190       51,890       1,440      1,080
 50       83,340       62,510       1,735      1,300
 60      104,200       78,180       2,165      1,625
 70      130,300       97,710       2,710      2,030
 80      162,850      122,100       3,390      2,540
 90      194,500      145,850       4,050      3,035
100      223,700      167,700       4,655      3,490
ONE-TIME CHARGE:  Customers who pay a one-time charge for a licensed
program receive enhancements and future releases, if any, at no
additional charge.  Significant new function may be offered as an
optional feature and charged for separately.  If a replacement
program is announced and the customer elects to license the
replacement program and replace the prior program, a time-based
upgrade credit may apply.
VARIABLE CHARGES:  The applicable graduated one-time charge or
graduated monthly license charge will be based on the group of the
designated machine on which the licensed program is licensed for use.
If the program is designated to a processor in a group for which no
charge is listed above, the charge of the next higher group listed
applies.
       For upgrades of one-time charge licenses to a machine in a
higher group, the upgrade charge will be the difference in the then
current charges between the two groups.  For downgrades of one-time
charge licenses to a machine in a lower group, there will be no
adjustment or refund of one-time charges paid.
       For upgrades or downgrades of monthly license charge licenses,
the monthly license charge applicable to the higher or lower group
will apply.