Do you know DLIST? The newest version is part of QDISK, http://www.vm.ibm.com/download/packages/descript.cgi?QDISK
With DLIST one can see the disks accessed by *other *virtual machines (CMS or GCS). You place the cursor on a disk, and: - pressing enter tells you who's the owner of a disk - with PF11 you get the FILELIST of it With DLIST A and DLIST B, you would probably have seen that one of them had an SFS directory as A-disk. I can't live anymore without DLIST, surely not on systems that "are not my own", full of service machines I don't know. Seeing what disks they access, easily looking at their PROFILE EXEC, makes it much easier to figure it all out. A sample: DLIST BUSERVER 1/12 => *BUSERVER 0120 = VMRMAINT 0192 - VTE001 741 TO 790 (50)* LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS_USED (%) BLKS_LEFT BLK_TOTAL BUSERV 191 A R/W 15 3390 4096 169 1228-45 1472 2700 TOOLS 193 B R/O 75 3390 4096 656 7206-53 6294 13500 GOODIE 194 C R/O 30 3390 4096 1045 5265-98 135 5400 BUS192 192 D R/W 1 3390 4096 45 67-37 113 180 *VMR192 120 E R/O 50 3390 4096 1323 4873-54 4127 9000* VMR193 130 F R/O 38 3390 4096 5121 6163-90 677 6840 - DIR G R/O - - 4096 762 SFSD:KRIS.LOCAL DIR1DF 150 H R/O 10 3390 4096 109 352-20 1448 1800 CMS23A 190 S R/O 100 3390 4096 690 14786-82 3214 18000 MNT19E 19E Y/S R/O 250 3390 4096 1239 31780-71 13220 45000 - 0195 - R/W 3339 3390 - - BUSERVER 0195 on VTERES - 019D - R/O 146 3390 - - MAINT 019D on VTE531 1)Help 2)Ref 3)Quit 4)S/A 5)S/D 6)Top 7)Ba 8)Fo 9)Bot 10)Get 11)FileL 12)Det 2010/12/31 Scott Rohling <[email protected]> > ??? 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 >> >> > -- Kris Buelens, IBM Belgium, VM customer support
