A simple approach to figuring out what's going on would be to 'spool' the guests' VM consoles so that all console activity is captured. That would certainly show whether or not the guest was entering some weird state. And also to monitor the main VM operator console for any relevant messages.
---------------------------------------------------------- news:<of9a85af5a.737ab5cb-on85257a78.004a68a1-85257a78.004a6...@us.ibm.c om>... > Hi, > > I would also like to warn you that having automation reply to the IXC402D > message without also ensuring that the subject system has been reset > creates a data integrity exposure. It appears to me that you have this > exposure. The IXC220W message suggests that the system wait-stated itself > because it recognized that it have been removed from the sysplex. This > suggests that the system came back to life at some point, made an attempt > to read data from the sysplex couple data set, and discovered that it had > been removed from the sysplex. This suggests that the system was in fact > NOT reset when the peer system was told to remove system XT1K from the > sysplex. That is what worried me too, also because he told he copied the system, including the SA policy, from another system. I fear, the other system had different circumstances, possibly under GDPS control that would have Reset the other system and validly replied to IXC402D. That was why I advised him to get more information about the SA policy. Probably the copy was done a little too quick and simple. Kees. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
