Tom Marchant wrote:
On Fri, 27 Apr 2007 10:14:55 -0300, ITURIEL DO NASCIMENTO NETO
<[EMAIL PROTECTED]> wrote:
Ira,
Try copying one of these PDSs (IEBCOPY - COPYMOD) to a new one with the
other blksize, and then proceed with your compare step.
Still might not work. Unless you can guarantee that each member starts at
the same location on a track, you will likely have blocks in one PDS that are
different sizes than the blocks in the other.
If a large load module starts on a new track, you'll have a 32K block at the
beginning of the track, then a shorter block at the end. If the same load
moule starts after a member that ends with a 32K block at the beginning of a
track, it will start with a smaller block, then have a 32K block at the beginning
of the next track.
Well...this ain't easy.
Each member must start on a new track, because directory entries
use TTR pointers to PDS members. See (watch for wrap):
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d450/3.7.2?ACTION=MATCHES&REQUEST=directory&TYPE=EXACTN&SHELF=EZ2ZO10h&DT=20060524093000&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT
So there is no worry there.
However, for load modules, any change in device type that changes
the track length (e.g., 3380 -> 3390) or cell size (I can't cite
a specific example but if different physical emulations change
the cell size then it counts) can cause text blocks to be
arranged differently on the tracks. This is because COPY won't
split them and COPYMOD will very probably split them differently
for modules longer than one track of the shortest *effective*
length accounting for cell size.
Any difference in the location of the text records will, I think,
cause the control records to change. Any difference in the
length of the text records will certainly cause the control
records to change. This is because control records contain the
length of the next record to be read and a prepared CCW (or part
of one) for reading the next record. This is due to the Loader's
PCI design, which tries to tack CCWs on as it goes to minimize
latency and the number of SSCH's.
See (watch for wrap, again):
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2B260/B.2?SHELF=EZ2ZO10h&DT=20060606155355&CASE=
While I have never had anything to do with the Linkage Editor,
Binder, Loader, or IEBCOPY, I actually think this design was
quite clever (bordering on brilliant at the time) and must
respectfully disagree with one poster's assertion that it is
"WABD" where "B" stands for "Badly." The folks who wrote that
code, Lo! these many years ago, had a lot on the ball in my
opinion, back when Giants walked the Earth.
Also, you have to think about what "equal" means. If the load
module in question contains multiple CSECTs that are represented
by multiple SMP/E MOD entries and the LMOD entry does not include
comprehensive ORDER statements, then the CSECT ordering will be a
function of the order in which CSECTs were added and replaced.
Consider two different target zones that are maintained at
different times over a year or two. Even if they are now at the
same service level there is no guarantee that the very same PTFs
affecting a particular load module were installed in the same
order if you (as would be rational) use current HOLDDATA and
GROUPEXTEND at APPLY time. The resulting load modules might have
a different order. The same can be true, for the same underlying
reason, of two load modules comprising MOD-represented unordered
CSECTs at the same service level delivered in different ServerPac
orders built at different times.
Even LOADing these resulting modules at the same starting address
would not show them to be binary equivalents, though they would
of course be functionally equivalent. You could, I suppose, use
LOAD to load the first one, use MVC(L) to copy it to another
storage area, DELETE it, LOAD the second, copy it to a second
storage area, figure out where the CSECTs started and ended,
compute the new address constants, replace them, and compare the
results CSECT by CSECT...but if I forgot anything (or quite
possibly got some of it wrong ;-) then it still would not work
perfectly.
Naturally, if the CSECTs are ordered differently the text records
will differ in content, and possibly (in some or most cases,
probably) in length as well.
Of course, the same goes for non-SMP/E-maintained libraries whose
load modules are not always bound using comprehensive ORDER
statements. (I would expect them to be in the majority, but what
do I know?)
For Ira's original request, which was to find the number of
occurrences of a specific string in different copies of load
module at different block sizes, it seems to me that LOADing all
the modules in a particular library in turn to search for the
string in question should work. Also, unless I'm missing
something, I think it should work equally well for load modules
and program objects.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
