I have given up on the idea of doing this via an IBM utility or ISPF function (like SEARCH FOR). Instead, I'm playing around with a REXX EXEC using ISPF services that will do the following... 1. Build a list containing the names of each of the modules in the "old" load library. 2. Read each module, record by record, into a single REXX variable string so I end up with one large string that contains the entire module. 3. Scan the resulting data string looking for the character string I'm interested in and count the number of occurrences of the string. 4. Repeat 2 and 3 for each module in the load library. 5. Repeat 1 thru 4 for the "new" load library. 6. Display totals. Initial tests suggest this will work, but I haven't thought about all of the possibilities. Note that an occasional "false negative" (reporting that the load libraries contain different numbers of occurrences of the string when they really have the same "count") is much more acceptable than a "false positive" (reporting that the load libraries contain the same number of occurrences when they really don't). Comments? Thanks, Ira In a message dated 4/27/2007 11:45:27 A.M. Central Standard Time, [EMAIL PROTECTED] writes:
Tom Marchant wrote: > On Fri, 27 Apr 2007 11:01:13 -0400, John Eells <[EMAIL PROTECTED]> wrote: > >> 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): > > Not true. The TTR points to the track and record number where the member > starts. I just looked at one of my load libraries that has 27 members and is > using 19 tracks. This would be impossible if each member had to start on a > new track. It would also be very inefficient. > > SYS1.LINKLIB on one system here has 3725 members and is using 70% of 3318 > tracks. SYS1.LPALIB has 1695 members and is using 79% of 909 tracks. > Doh! That's what the "R" stands for, of course. You're completely right. -- 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 ************************************** See what's free at http://www.aol.com. ---------------------------------------------------------------------- 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
