Quite a puzzler. As a debugging suggestion, turn off MDC for that minidisk and see if the problem persists.
Brian Nielsen On Wed, 29 Dec 2010 16:51:44 -0800, Schuh, Richard <rsc...@visa.com> wrot e: >Mike, > > 1. >If it had not been fully logged off, then the XAUTOLOG commands probably would have failed, would they not? It was logged off many times, both wer e logged off many times.When A was logged off, it would XAUTOLOG B, otherwise I would do the honors. Q USER B, preceded by Q USER A when appropriate, prior to entering the XAUTOLOG command showed that the user was not logged on. > 2. >Q LINKS 191 was used to verify that the disk was the correct one. A had it as its 191 R/W disk, B had it as its 191 R/O disk.The the manual link command used was LINK * 191 191 RR. If that got a different disk, then there was an error in the processing of the LINK command - the directory entry is LINK A 191 191 RR. When the profile was updated, both A and B were logged off and the update was done from another id, mine. > >We still do not have an answer. It has all of the appearances of being a cache problem of some kind. MDC should have kept things straight since these were two guests of the same CP. DASD cache should also have given both users the same answer. It appears as though A was being given data from a cache, and the cache was being bypassed by B. That would be understandable if the guests were in different LPARS or on different CECs and MDC were in use; however, they were in the same LPAR, hosted by the same CP, using the same I/O hardware and program interfaces. If not a cache problem, then the ACCESS command could have been giving 9ncorrect results, i.e. using the active ADT for A and the inactive for B. > >I am planning to take both users logoff/xautolog cycles to see if this i s a recurring problem. > >Regards, >Richard Schuh > > > > > >________________________________ >From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Michael Harding >Sent: Wednesday, December 29, 2010 3:36 PM >To: IBMVM@LISTSERV.UARK.EDU >Subject: Re: Configuration Puzzler > > >The fact that you had to logon to B, and detach/relink the disk tells me that either (1) B never really logged off, or more likely (2) B wasn't linking the disk you thought it was, but when you did it manually you got the disk you thought it should have (the one A updated). >-- >Mike Harding >z/VM System Support > >mhard...@us.ibm.com >mike.b.hard...@kp.org >mikehard...@mindless.com >(925) 926-3179 (w) >(925) 323-2070 (c) >IM: VMBearDad (AIM), mbhcpcvt (Y!) > > >The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> wrote on 12/29/2010 03:17:53 PM: > >> From: "Schuh, Richard" <rsc...@visa.com> >> To: IBMVM@LISTSERV.UARK.EDU >> Date: 12/29/2010 03:18 PM >> Subject: Re: Configuration Puzzler >> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> >> >> 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> >> 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 >
