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 were 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 is 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

Reply via email to