| 1) |
External definition: FILE1 must be externally
defined. It is analysed for record layout (key and
non-key fields) and record length. FILE2 is
assumed to have the same record layout and record
length. So FILE2 does not have to be externally
defined, as long as it has the same implicit
record layout/length as FILE1. |
| 2) |
The field names reported in PCMPDBRS are those
in FILE1. If FILE2 has different field names,
these do not appear in PCMPDBRS. |
| 3) |
Single record format in FILE1 (FILE2 assumed to
have same format). |
| 4) |
Non-keyed files: Files do not have to be keyed.
In this case, processing is simply by relative
record number (RRN), which is the value that
appears for the key in PCMPDBRS. If arrival
sequence is a concern, you may need to sort the
underlying records prior to running the command.
To keep life simple, there is a restriction that
MBR1 and MBR2 must have same number of records if
not keyed. |
| 5) |
Keyed files: Files do not have to be keyed
unique, as long as you accept that records with
the same key may not be compared exactly - arrival
sequence is not predictable. |
| 6) |
FILE1 and FILE2 do not have to be physical files
or logical files. Either/both may also be a DDM
file, in which case the MBR1 and MBR2 values on
the PCMPDBF command are ignored. A DDM file itself
has no members, although you may create it to
point to selected member(s) in the file on the
remote system. |
| 7) |
Maximum 99 keys and 2048 fields with maximum
record length of 4K (4096 bytes): These
limitations can be bumped up quite easily if needs
be. |
| 8) |
PCMPDBRS results: For every field-level
difference, a record is written to the PCMPDBRS
member you select. This includes fields (e.g.
RSAV1, RSAV2) that show the values that are
different. For large field values it is difficult
to show exactly where the difference occurs. So if
you look at a PCMPDBRS record and do not see an
obvious field difference, always examine the
original files that are being compared to detect
the actual difference. The difference does
exist - PCMPDBRS may just not show it exactly. |
| 9) |
Field types: The following DDS types are fully
supported:
- A (Alphanumeric)
- P (Packed Decimal)
- S (Zoned Decimal)
- F (Floating Point)
- L (Date)
- T (Time)
- Z (Timestamp)
DDS types B (Binary) and H (Hexadecimal) are
supported, but with two restrictions:
- A binary or hexadecimal field can not be a
key field.
- In the record in the PCMPDBRS results file,
a different value for a a Binary field is
reported in the RSAV1 and RSAV2 fields with
the word *BIN and a different value
for a hexadecimal field is reported with the
word *HEX. This is done because there
is no absolutely safe way to capture the
binary/hexadecimal values (they could contain
unprintable characters). You still see which
record/field has the difference, but have to
look in the original database files to find
out the actual values that differ.
|
| 10) |
Field lengths: Alphanumeric fields (DDS type A)
are limited to maximum 4096 characters. Numeric
fields (DDS types P/S/F) are limited to maximum 15
decimal places and 29 digits in total. |
| 11) |
Floating point numbers: If you use floating
point fields (DDS type F) then you need to have a
good understanding of how their numeric values are
actually stored in your database files. Otherwise
PCMPDBF may report a difference that you struggle
to reconcile with your actual data. |