Understand the bridge performance requirements. If the bridge
is slated to be burned, these are less important than for
interface bridges:
- batch window
- on-line response time
- CPU usage
- disk usage
Verify bridge parameters to ensure that they are still
appropriate:
- Communication protocols must be compatible for on-line
bridges
- Database recoverability must be compatible when you are
bridging database types.
Change data definitions by:
- altering date declarations to the specified format
(expansion, compression...)
- creating additional data as needed to hold switches and
codes
- defining new file and/or database types
- making these available to those modifying the
corresponding code.
Implement data conversion by (in order from most to least
effort):
- writing a data conversion program from scratch
- customizing a model data conversion program
- generating a data conversion program
- using a utility program
- defining a different database view
This is one place where using a century window can be quite
useful:
- To expand your data
- Create a mirror image of your production system
- Read in the old; write out the new
READ OLD-INPUT-FILE
CALL CEEDAYS USING OLD-INPUT-FILE-DATE,
OLD-PIC-STRING,
LILIAN-RETURN,
FC
CALL CEEDATE USING LILIAN-RETURN,
NEW-PIC-STRING,
NEW-OUTPUT-FILE-DATE,
FC
WRITE NEW-OUTPUT-RECORD
You can do the same thing for IMS and DB2 data.
DFSORT can do the same thing.
Implement date scrubbing via:
- inference rules (example: if policy number > 8000000
then billing cycle = 063097)
- default values (example: if membership date is invalid,
set it to Dec 31 of current year)
- table lookups (example: change i1Z20O to 112200,
"oh" to zero, "el" to one,
"zee" to two)
- error suspense (hold record for manual correction)
Compile and link conversion programs.
Create bridge programs that:
- satisfy performance requirements
- maintain sufficient data integrity (real-time vs. batch
updates)
- perform appropriate record selection
- contain sufficient validation and controls
Tip: you may be able to choose an
implementation alternative:
- Avoid the need for a bridge to do on-line file updates by
playing transactions twice: once for legacy update and
once for compliant update
- Avoid the need for a bridge to do batch file updates by
passing transaction records through the bridge and
letting an update program within the owning partition do
the updates
- Pass data records through the bridge, but let a separate
update program do updates
Remember: in addition to building bridges between
partitions, you may have to build interfaces (internal bridge)
within a partition if a mix of date approaches is used.
©1997 IBM Corporation