That was the problem. When the conversion to use SFS was done, it was only half done. One machine, the one that owned the minidisk, was converted, the other was not.
Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Scott Rohling Sent: Thursday, December 30, 2010 4:21 PM To: [email protected] Subject: Re: Configuration Puzzler ??? I thought there was linking, etc involved... as in minidisks. Well - glad you figured it out... it was a puzzler as stated :-) Scott Rohling On Thu, Dec 30, 2010 at 1:01 PM, Schuh, Richard <[email protected]<mailto:[email protected]>> wrote: Mystery solved. There was an incomplete conversion to SFS. Converting the B machine to actually look like A solved the problem. Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Kris Buelens Sent: Thursday, December 30, 2010 3:29 AM To: [email protected]<mailto:[email protected]> Subject: Re: Configuration Puzzler RELEASE in not implicit with LOGOFF: when you enter LOGOFF, CMS passes this to CP, without lokking. So, CMS doesn't perform a RELEASE. But, somehow you give a good idea, even though I don't think it applies here. When you update a file, CMS doesn't commit the changes until all files on the updated minidisk are closed. CMS will close all files when returning to CMS Ready, something an ever running server will not do. (that's why good written execs always close the files they opened. Mostly no problem if using PIPE, requires action if using EXECIO). But, as mentioned, it should not apply here: Richard saw the new version of the file after a new LINK. But, Richard, if you XAUTOLOGged B after the update, the logon process implies a LINK... So that LINK or the explicit LINK should have behaved the same. Compare Q MDISK 191 LOCATION perhaps? 2010/12/30 <[email protected]<mailto:[email protected]>> Richard, One possibility: I remember that a FST is maintained in memory, until command "RELEASE" completes. RELEASE is implicit into LOGOFF. Because this, MultiWrite must be avoided in CMS. If A Xautolog B, is possible that the altered FST was not saved yet. When A change something, try "CMS RELEASE A", before "CP XAUTOLOG B"... Only a idea... _____________________________________________ Clovis From: "Schuh, Richard" <[email protected]<mailto:[email protected]>> To: [email protected]<mailto:[email protected]> Date: 29/12/2010 22:52 Subject: Re: Configuration Puzzler Sent by: The IBM z/VM Operating System <[email protected]<mailto:[email protected]>> ________________________________ 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:[email protected]] On Behalf Of Michael Harding Sent: Wednesday, December 29, 2010 3:36 PM To: [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> (925) 926-3179 (w) (925) 323-2070 (c) IM: VMBearDad (AIM), mbhcpcvt (Y!) The IBM z/VM Operating System <[email protected]<mailto:[email protected]>> wrote on 12/29/2010 03:17:53 PM: > From: "Schuh, Richard" <[email protected]<mailto:[email protected]>> > To: [email protected]<mailto:[email protected]> > Date: 12/29/2010 03:18 PM > Subject: Re: Configuration Puzzler > Sent by: The IBM z/VM Operating System > <[email protected]<mailto:[email protected]>> > > 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:[email protected]] > On Behalf Of Kris Buelens > Sent: Wednesday, December 29, 2010 2:09 PM > To: [email protected]<mailto:[email protected]> > 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 <[email protected]<mailto:[email protected]>> > 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 -- Kris Buelens, IBM Belgium, VM customer support
