??? 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]> 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]] *On > Behalf Of *Kris Buelens > *Sent:* Thursday, December 30, 2010 3:29 AM > > *To:* [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]> > >> 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]> To: [email protected] >> Date: 29/12/2010 22:52 Subject: Re: Configuration Puzzler Sent by: The >> IBM z/VM Operating System <[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]<[email protected]>] >> *On Behalf Of *Michael Harding* >> Sent:* Wednesday, December 29, 2010 3:36 PM* >> To:* [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] >> [email protected] >> [email protected] >> (925) 926-3179 (w) >> (925) 323-2070 (c) >> IM: VMBearDad (AIM), mbhcpcvt (Y!) >> >> >> The IBM z/VM Operating System <[email protected]> wrote on >> 12/29/2010 03:17:53 PM: >> >> > From: "Schuh, Richard" <[email protected]> >> > To: [email protected] >> > Date: 12/29/2010 03:18 PM >> > Subject: Re: Configuration Puzzler >> > Sent by: The IBM z/VM Operating System <[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]*<[email protected]>] >> >> > On Behalf Of Kris Buelens >> > Sent: Wednesday, December 29, 2010 2:09 PM >> > To: [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]> >> > 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 > >
