This sounds as though it should be easy, but it is in reality
deceptively difficult. It would take quite a bit of work to be certain
that everything is really the same.
The block size and starting location on a track determine how much space
is used for two "identical" copies of a particular load module. Both
that and the order in which members are loaded will change the directory
content for both PDS and PDSE, and also affect the number and content of
text records and the amount of space used in a PDS. Additionally, the
number and content of at least some non-text records (control records,
at a minimum) will likely differ, at least for PDSs. This applies to
both copied (with COPYMOD) and bound modules. These challenges make
disk-to-disk compares difficult at best.
The order in which CSECTs are bound will likely cause a number of both
AMBLIST and binary compares, no matter how performed, to show different
outputs for "identical" copies of modules (really, those with the same
bits and pieces of code at the same levels, but bound in different
orders). This will potentially affect the content of any module
represented by an LMOD entry that has more than one MOD and has no LKED
ORDER statements in the LMOD entry. Even those with ORDER statements
can have different orders when all of the CSECTs in all of the MODs are
not named on the ORDER statements. (Also, multi-CSECT MODs can make
this more time-consuming to determine.)
Unless you have the same starting point as the original system, and
install same PTFs that were installed on the original system on the
rebuilt system in the same number of APPLY steps run in the same order,
the probability that all the "identical" copies of modules that are at
the same service level will actually appear to be identical is very low.
Add in some ERROR HOLDs, GEXT, etc., and things quickly go from bad
worse (in this respect, at least).
From a practical standpoint, if you cannot find backups of the CSI data
sets that are known to correspond with the code levels you are running,
my suggestion is to rebuild, put on current service, and treat the
result like any other maintenance upgrade from testing and migration
points of view. It will almost certainly take far less time, and if you
put recommended service on the result could well be better.
--
John Eells
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
