I don't know if they work. Have you tried an IDCAMS PRINT (perhaps with dump option). IEHLIST is more directory oriented, but comparing before and after and looking at the start location.
Say you create a xyz.loadlib. Directory is 62 (or so) blocks (to take up the entire first track). You compile and successfully link program AAAA1111 and it is stored in Cyl 0 Track 1 Record 1 (CCHHR=0000000101) through Cyl 0 Track 3 Record 4 (CCHHR=0000000304). You compile and successfully link program BBBB2222 and it is stored in Cyl 0 Track 4 Record 1 (CCHHR=0000000401) through Cyl 0 Track 8 Record 2 (CCHHR=0000000802). You compile and successfully link program CCCC3333 and it is stored in Cyl 0 Track 8 Record 3 (CCHHR=0000000803) through Cyl 1 Track 1 Record 8 (CCHHR=0001000108). You compile and successfully link program DDDD4444 and it is stored in Cyl 1 Track 2 Record 1 (CCHHR=0001000201) through Cyl 1 Track 7 Record 5 (CCHHR=0001000705). You compile and successfully link program BBBB2222 and it is stored in Cyl 1 Track 8 Record 1 (CCHHR=0001000801) through Cyl 1 Track 14 Record 2 (CCHHR=0001000E02). Since you used the same name as a previous entry, the old space is no longer used or valid, but can't be reused until you compress it. You run the compress program. It reads the directory entries and sorts them by the order they are stored in the library. The directory is first. There is no gap between the directory and AAAA1111. There is a gap between AAAA1111 and CCCC3333. It reads CCCC3333 in its entirety and writes it directly after AAAA1111. It reads DDDD4444 in its entirety and writes in directly after CCCC3333. It reads BBBB2222 in its entirety and writes it directly after DDDD4444. That is the end of the members and the used space was compressed to the front and the free space bubbled through to the end. The space is not release and can be used for the next compile and link. If you used the COPYMOD function, the binder can re-block the load modules. 2011/10/28 Sérgio Lima Costa <sergio.co...@cetip.com.br>: > Hello List, > > We try made here, all end-of-week , a compress of our load libraries. > So, We think first, do a Backup from Tape (Cartridge), and then execute a > EIBCOPY JOB, that Will do a compress. > What We don't know, IF this is that is possible, get a report, before , and > after the libraries, for see what was doing. > > Under TSO, we have a command that show this : > > ISRUAIPO Data Set Information > Command ===> > > Data Set Name . . . : XXXXXXXX.TSO.LOAD > > General Data Current Allocation > Volume serial . . . : GRV32E Allocated blocks . : 600 > Device type . . . . : 3390 Allocated extents . : 12 > Organization . . . : PO Maximum dir. blocks : 6 > Record format . . . : U > Record length . . . : 0 > Block size . . . . : 6144 Current Utilization > 1st extent blocks . : 72 Used blocks . . . . : 138 > Secondary blocks . : 45 Used extents . . . : 3 > Used dir. blocks . : 6 > Number of members . : 37 > > Dates > Creation date . . . : 2011/01/11 > Referenced date . . : 2011/10/28 > Expiration date . . : ***None*** > > Someone know, IF is possible get this information under a batch JOB ? > May be, CBTTAPE have some program ? > > Thanks. > > Sergio Lima Costa > São Paulo - Brazil -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
