On Mon, 28 Jan 2013 16:19:49 -0500, Jim Mulder <[email protected]> wrote:
>> A couple instances of "n MESSAGE BUFFERS MISSING" (total of 6), but
>> otherwise lists just about all the active ASIDs being processed.
>
> This, along with the other symptoms, suggests that IPCS
>is not seeing the data from all of the volumes.
>
> IPCS said:
>28,578 blocks, 118,884,480 bytes, in DSNAME('SYS1.SADMP.DDS1 ')
>
>That's around 188 megabytes.
>
>SADMP said:
>
>AMD095I REAL DUMP 63% COMPLETED. TOTAL MEGABYTES DUMPED: 2,912
>
> You are running IPCS directly against the original multivolume
>SADMP output data set. The documentation (and I) strongly recommend
>that you should copy that data set with IPCS COPYDUMP, and then
>do further IPCS processing against the copy.
As we determined in my PMR, we did use IPCS COPYDUMP to copy the dump into a
single dataset, but we did not have the fix for OA36232 installed; so COPYDUMP
only copied the first volume, even though it read all 5 volumes. Thus,
"IPCS-ing" the copy gave the appearance of "IPCS-ing" the first volume of the
actual dump.
After changing our COPYDUMP JCL to specify all five VOLSERs, we did get a "full
copy" of the SADUMP.
> Sometimes, running some utility other than SADMP or IPCS
>against the multi-volume data set may cause the "last volume"
>indicator to get turned on in the F1/F8 DSCB for some volume other
>than the last volume. This will cause subsequent attempts to read
>the data set sequentially to not see all of the data. COPYDUMP
>will avoid this issue, and improve IPCS performance by merging
>the data back into logical dumping order.
>
> With the PTF for APAR OA37350 installed, SADMP should fix
>an incorrect "last volume" indicator each time it takes
>a dump.
We have duly added UA63883 to our "apply list" for maintenance.
-jc-
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
