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
