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
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 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.
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
o To define the mapping, needed by DProp, between the IMS/ESA
database and DB2 table definitions of the DProp-maintained
o To perform the selection and extract of data from one copy and
assist its initial load into the other.
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.
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
o MVS/DFP Version 3 Release 2 (5665-XA3), if using IMS/ESA
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
- 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
- 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
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
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
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
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
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
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
o How many updates a batch program or transaction performs per
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
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.
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
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
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
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
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
User management is responsible for evaluation, selection, and
implementation of security features, administrative procedures, and
appropriate controls in application systems and communication
Ordering information will be available at announcement of
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.
Replaced Program Replacement Program Version
Program Program Program Program Charging
Number Name Number Name Applies
Propagator To a follow-on if any N/A
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
PROGRAM SERVICES: Central Service, including the IBM Support Center,
will be available until discontinued by IBM upon six months' written
Central Service, including the IBM Support Center, for DSLO
licenses will be provided only through the customer location
designated for the basic license.
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
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