Thanks Alan, great explanation. In my case the cms files are pretty static. I have some bash scripts that run when the Linux system starts up. All the Linux’s share a r/o 191 cms disk. It’s purely a convenience for me. Some of our Linux systems are wiped out and copied over from a “golden image” regularly but have various server-specific customizations. I have a cms script in /usr/local/bin that takes the cms file name as a parm and runs that bash script. For example we have a script that registers the server with a satellite for updates and that script changes from time to time. I found it easier to put it on the 191 disk as “REGISTER BASH”, and on Linux I run “cms register”. Instead of updating the script file on each individual server.
Where I noticed this “odd behavior” was when I was testing changes to one of the cms files. Cause I’d make a change, run the Linux command and notice “it didn’t use the updated code”. It all makes sense when I know why. 🙂 Cheers, Don On Mon, Dec 30, 2024 at 07:40 Alan Altmark <alan_altm...@us.ibm.com> wrote: > It doesn't matter what OS is accessing the disk. The CMS minidisk file > system was not designed for concurrent access while there is an active > writer, as the reader has no way to know that the disk has become an active > minefield. > > In CMS, IIRC, the only thing persistent in cache is the directory, so > re-ACCESSing the disk gets you an updated directory, though not necessarily > a valid one. Any transient cached data blocks are discarded. The more > often the disk changes, the less likely it is to be valid. Or, put > another way, the more likely you are to see invalid control data or, worse, > stale *valid* control data. Imagine reading a file that is a mix of data > blocks from multiple files. (This is why we created SFS - we needed this > all to just Go Away.) > > Linux has not only the directory cache, but the disk block cache. With > CMS on different systems, we would see this same effect caused by the > CP-managed minidisk cache. You have to turn off MDC for a minidisk on > System B to see the changes made by System A. (This is something that SSI > manages for you.) > > So, you not only have to unmount the file system to throw away any cached > file system control structures, you have to ensure that you discard the > cached data maintained by the block driver (control and data), AND you have > to worry about MDC. (Watch out for 2nd level MDC, too!) > > As a matter of Computer Science, stale data is the Enemy. Without SFS (a > database), you have window that cannot be closed unless you layer a control > plane on top of (or within) the file system to manage concurrent access. > > Don't get me wrong. Getting data from a CMS disk is fine as long as you > understand what's happening at the file system level and take steps to > mitigate issues introduced by your usage. If you have automation to > trigger an unmount and take the disk offline on all linked Linux servers > before you update the CMS file, and then tell them all to bring it online > and mount it again afterward, you're good to go. You might place a hash > value in the first line of a file that will tell you if the rest of the > file is self-consistent. It all depends on your level of paranoia and the > impact of getting bad data. > > And think about *why* you are sharing with CMS. History? Habit? > Inherent CMS coolness factor? For example, I see people using CMS disks to > hold Linux network config data that they read at Linux boot. I suggest > that they use persistent DHCP instead, if they really think they're going > to change the IP address of a server. Otherwise, simply feed that data to > the installation parm file creation process and leave CMS out of boot > equation. > > Or, if you must, boot CMS first and pull information out of SFS onto a > local CMS disk or put it in a TAG on the printer or .... Then boot Linux > and have Linux use the local copy. No worries about concurrent disk > updates. > > The tricks we used in the Before Times were good enough. There were more > plusses than minuses. But today, the expectations are higher and the cost > of failure is higher. > > "Hey. Let's be careful out there!" > > Regards, > Alan > > Alan Altmark > IBM Senior z/VM Engineer and Consultant > 1 607 321 7556 (Mobile) > alan_altm...@us.ibm.com > > > -----Original Message----- > > From: Linux on 390 Port <LINUX-390@VM.MARIST.EDU> On Behalf Of Donald > Russell > > Sent: Friday, December 27, 2024 9:42 PM > > To: LINUX-390@VM.MARIST.EDU > > Subject: [EXTERNAL] Re: [LINUX-390] Accessing cms disks from Linux > > > > Thanks Rick, > > Yes, I know and expect cms access to work that way. If I have an R/O > link to a dial and that disk > > changes, I have to access it again. That’s because the access command > copies the disk directory to my > > storage/memory. If the disk contents change, my in-memory copy doesn’t > know about it. That’s not > > too bad, cms is a single user system. > > > > On Linux if I have to take the device offline/online to ensure I don’t > see stale data, that can impact > > other Linux users. > > > > Good tip about flushing the cache… I’ll see if that’s an option. Even > just unmounting the file system > > could fail if it’s in use. My bash script tries to unmount/mount. If > the unmount fails it issues a warning > > saying the disk contents may be stale. > > > > I suppose another approach is to keep the device offline and serialize > access so a process that needs > > those files would get exclusive use of a semaphore, bring the disk > online, mount it, use whatever, > > unmount it, take it offline and finally release the semaphore so another > waiting process could access > > it. That would ensure freshness but sure seems ugly in a multiuser > environment. 🙁 > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www2.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
