> Talking of AUTOIPL and sadump, when I tested this, the only way to > see that sadump had finished was when the NIP messages came up on > the real console, indicating sadump was done. That's fine and dandy > when I am expecting an sadump, but what about when the sadump is > taken due to a real problem (and not me just v xcf,sadump,reipl)? > How can I see (without interrupting sadump) how far it had come? > Just open the operating system messages window on the HMC?
Since you have SMSYSC in the loadparm, SADMP should be happily writing its usual progress messages to the operating system messages window on the HMC. > >It used to be that you would not get any paged out > >storage dumped if you did that, but I fixed that in > >z/OS 1.9. > Now he tells me! I had been standing there and thinking to just > reload sadump. The last time I did this I ended up with a nice > system trace of what sadump had done :-(. > What's the point of no return? In other words, when shouldn't I > reload sadump in order to get a dump with meaningful content for the > problem I am sadumping for? (I think I understand the 4K pages in nucleus.) I don't think there is a point of no return. SADMP only uses 4MB of storage for itself, and as long as there is some useable DAT structure in place when you IPL SADMP, it will use the 4MB of real storage that was backing the 4MB of virtual storage starting at virtual address 01000000. So no matter how many times you reload, SADMP will be using the same 4MB of real storage, and the rest of real storage is still from the z/OS system that you were trying to dump. When SADMP issues AMD087I DUMP OF A PREVIOUS STAND-ALONE DUMP PROGRAM NOW COMPLETE AMD088D REPLY 'T' TO TERMINATE, OR 'U' TO CONTINUE DUMPING. REPLY= it means that SADMP has finished dumping all of the real storage that was in use by SADMP and the z/OS system that was being dumped. If you reply U, it will continue on to dump the requested paged out storage, and then any real storage that was not in use (i.e., on an available frame queue). It used to be that you had to know how to do some incantations in IPCS to make sense of one of these dumps, but I changed SADMP in z/OS 1.10 to put a little but of extra information in the dump header record that z/OS 1.10 IPCS uses to avoid the need for the incantations. These also used to be some potential problems when SADMP had to use the store status data to determine whether it the thing it was dumping had been running in ESA/390 mode, or z/Architecture mode. In z/OS 1.12, I changed z/OS IPL and SADMP IPL processing to immediately switch into z/Architecture mode, so that SADMP and IPCS can safely assume that the thing being dumped was z/Architecture. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
