As stated, one has it R/W the other R/O. Someone has to log on to the machine that has it R/W to update it, there is nothing in the machine, itself, that writes anything. I am aware of MDC, and it is not in play, here. Both are on the same VM system. The update was done while both were logged off. The file was only updated once. The trials, including several logoff/logon sequences, spanned a couple of hours on a system that is lightly loaded.
Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Wednesday, December 29, 2010 2:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Configuration Puzzler Your machines don't share it in MW mode? If yes, anything is possible.... They are on the same z/VM system? If not, the MDC cache on the system that didn't update the disk can be backlevel. 2010/12/29 Schuh, Richard <rsc...@visa.com<mailto:rsc...@visa.com>> We have two service machines, I will call them A and B for this discussion. These machines share a 191 disk. When A is xautologged, it initializes itself and then xautologs B. I logged both machines off and added two new ACCESS commands to the PROFILE EXEC. I then logged A on and checked its configuration. It reflected the changes from the PROFILE. It AUTOLOGGed B. B came up using the old profile. I stopped the server code on B and checked the configuration. It was indeed the old profile that was used. A q links 191 showed that A had it as its 191 in R/W mode, while B had it as 191 R/O. A list profile exec * found only one such file, on the A disk, , and on B it was the old configuration. I then logged both off and xautologged A. Again, B came up with the old configuration. I tried the logoff/logon sequence several times, all with the same result. I finally detached the 191 disk from B and relinked it. This time, the new profile exec was there, like it should have been all along. How is this even possible? Are we going to be plagued by this every time we xautolog A? Clearly the pointers were all correct when the first machine logged on. Given that, I would certainly expect that they would be correct when the second machine linked to the same disk and accessed it. Regards, Richard Schuh -- Kris Buelens, IBM Belgium, VM customer support
