It looks like you have a good setup. I would agree with Mark that anything that doesn't get updated should be mounted read/only and any filesystems that contains executables should DEFINITELY be mounted read/only for security reasons (so no one could intentionally or accidentally update it). If a vendor ships executables and configuration files in the same filesystem, we manually separate them and use symbolic links to logically keep the same paths. The configuration files are in a read/write filesystem and the executables are in a separate, read/only filesystem pointed to by the symbolic links. As for the IGW026I messages, it would appear that either someone is trying to manually mount the filesystem or you have a corrupted mount table. IBM might be able to diagnose a corrupted mount table from a dump, but I would research the possiblity of a manual mount. Best of luck! Jon
Jon L. Veilleux [email protected] (860) 636-2683 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Lizette Koehler Sent: Wednesday, February 18, 2009 9:03 AM To: [email protected] Subject: Re: Automove vs Noautomove in BPXPRMxx I have two BPXPRMxx members. One is system wide, the second it system specific. Because we define these files with SYS1.OMVS.JV390.&SYSNAME we elected to put them in BPXPRM00. This contains the generic names along with the BPX options. When we have a unix file that is system specific, we code that in the BPXPRMxx where xx = last two chars of our LPARs. So - yes we code the file systems in BPXPRM00 where we use a SYMBOLIC in the data set name. For actual files that are only on one system, we code that in the lpar specific BPXPRM member. All defaults are taken and RW is the status in the parms for all files. Lizette > > The only time that BPXPRMxx is used to mount a filesystem is at IPL > time, so unless the system that is trying to perform the mount is > IPLing then someone is trying to manually mount this filesystem. If it > is at IPL time you should be getting an 'BPXF237I FILE > SYSTEM.....Already mounted' message, not the IGW026I. > Are you sharing one BPXPRMxx member within the SYSPLEX? We have two > members for every system, a SYSPLEX BPXPRMxx for filessytems that > should be shared and a System-specific BPXPRMxx for system-specific > filesystems. All of the filesytems in the system-specific BPXPRMxx are > defined with 'unmount'. > > > Basically these are system specific OMVS data sets. They would not be > mounted on any other system because that system already has these files. > I will look at UNMOUNT, however, there is no one trying to move these > files. > It looks to me to be the system trying to do this. I get an IGW026I > indicating the system tried to mount LPAR1 dataset on LPAR2 but could > not because it was already in use. > > It is just strange to me that the system is trying to mount a file it > should not care about. > > From my SMPE environment I have the ZOS19.OMVS.JV390 dataset. I then > copy it as SYS1.OMVS.JV390.LPAR1 and SYS1.OMVS.JV390.LPAR2 and so forth. > So I have 5 copies of the smpe JV390 dataset. For some reason during > its run time, the operating system seems to feel the need to mount > this dataset (say > SYS1.OMVS.JV390.LPAR1) on LPAR2. But LPAR2 already has this data set > mounted as SYS.OMVS.JV390.LPAR2, and LPAR1 is not down and still has > SYS1.OMVS.JV390.LPAR1 mounted. It is then I see the IGW026I message. > > Lizette > > > > > > If that is your scenario then you should be using 'unmount' for the > > automove parameter. Noautomove can still leave entries in the global > > mount table for these filesystems even though the system is down. > > That > > > is usually not a big issue unless you have the need to mount them on > > another system for some reason (maintenance or problem > > determination, etc). > > > > > > > > I have th 5 lpars. Each one has its own set of OMVS datasets. > > > > For example Lpar1 has SYS1.OMVS.ROOT.LPAR1, SYS1.OMVS.JV390.LPAR1, > > SYS1.OMVS.SGIYROOT.LPAR1 and so on. > > Lpar2 has a duplicate set of files that end with LPAR2 rather LPAR1 > > And so forth. > > > > I see in syslog that the LPAR2 gets an IGW026I message trying to > > mount > > > the > > LPAR1 dataset. This is not needed nor required. Each system has > > its own set. > > > > I was thinking that setting the files to NOAUTOMOVE would prevent > > another system from trying to mount them. > > > > Lizette > > > > > > > > On Tue, 17 Feb 2009 11:20:11 -0500, Lizette Koehler > > > <[email protected]> wrote: > > > > > > >I have read the manuals but I am still not clear on the use of > > > >automove > > vs. > > > noautomove. > > > > > > > >My Unix envrionment on z/OS V1.9 is one system/one set of UNIX > files. > > So, > > > yes, I have a lot of duplicated files. > > > > > > > >However, from time to time I notice I will see the following > > > >message in > > SYSLOG > > > > > > > >IGW026I HFS FILE SYSTEM: SYS1.SPG7.OMVS.DB2V91.SDSNAHFS 202 > MOUNT > > > >REQUEST FAILED, RESOURCE HELD EXCLUSIVE ON: SPG7 > > > >RESOURCE HOLDER: OMVS ASID: X000E TCB: X009DB360 > > > > > > > >I am thinking that I should add NOAUTOMOVE to the MOUNT statement > > > >in > > > BPXPRMxx for these files - because they truely cannot move. > > > > > > > >Am I correct in this thought? > > > > > > > >If I could get to a SYSPLEX ROOT, then I would be using a > > > >different > > > approach. However, it is not there yet. > > > > > > > > > > Since you are not using a shared file system, automove is not > > relevant. > > > > > > Are you saying you have the same data set name but 2 physically > > > different > > file > > > systems mounted, but they are in the same sysplex / grsplex? That > > > would be a problem - unless you excluded SYSZDSN - which is there > > > to > > > > protect you from mounting the same file system R/W on 2 LPARs in > > > the > > > > plex when you aren't using a shared file system. > > > > > > Or do I not understand the issue? > > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
