Re: OMVS File System Automove question
I did that, it didn't change from what I could see. I might open a question to IBM support. See what they say. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com --- Original Message --- On Monday, March 20th, 2023 at 1:05 PM, Dave Jousma <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 20 Mar 2023 14:42:41 +, Mark Jacobs markjac...@protonmail.com > wrote: > > > Thanks, no I didn't think of the chmount command. I ran a test on my > > sandbox. the /u directory is showing that automove will exclude the system > > I specified, but the file systems mounted under it don't show that > > attribute, just Automove=Y. Do I need to change the mount attribute for all > > automounted file systems, or will automove attribute for the parent /u/ > > directory override each individual file system? > > > > Mark Jacobs > > > you might unmount one, and let it mount again, and see if it inherits the > settings from /u. if that works, you could try a chmount -D system /u/* to > change ownership manually this time. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS File System Automove question
On Mon, 20 Mar 2023 14:42:41 +, Mark Jacobs wrote: >Thanks, no I didn't think of the chmount command. I ran a test on my sandbox. >the /u directory is showing that automove will exclude the system I specified, >but the file systems mounted under it don't show that attribute, just >Automove=Y. Do I need to change the mount attribute for all automounted file >systems, or will automove attribute for the parent /u/ directory override each >individual file system? > >Mark Jacobs > > you might unmount one, and let it mount again, and see if it inherits the settings from /u. if that works, you could try a chmount -D system /u/* to change ownership manually this time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS File System Automove question
Thanks, no I didn't think of the chmount command. I ran a test on my sandbox. the /u directory is showing that automove will exclude the system I specified, but the file systems mounted under it don't show that attribute, just Automove=Y. Do I need to change the mount attribute for all automounted file systems, or will automove attribute for the parent /u/ directory override each individual file system? Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com --- Original Message --- On Monday, March 20th, 2023 at 9:14 AM, Dave Jousma <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 20 Mar 2023 13:04:44 +, Mark Jacobs markjac...@protonmail.com > wrote: > > > Thanks, but that's not helpful in my situation. The problematic file system > > is under /u which is under the sysplex root, That has to be automove. > > > > Mark Jacobs > > > Correct. Then the only way to "avoid" a lpar is to avoid it with the sysplex > root too. > > Have you tried the chmount commands? > > TEC1:$ chmount -D TEC2 /home > TEC1:$ df -vk /home > Mounted on Filesystem Avail/Total Files Status > /home (*AMD/home) 0/4 0 Available > AUTOMNT, Read/Write, Device:66, ACLS=N > File System Owner : TEC2 Automove=Y Client=N > Filetag : T=off codeset=0 > TEC1:$ chmount -a exclude,TEC1 /home > TEC1:$ df -vk /home > Mounted on Filesystem Avail/Total Files Status > /home (*AMD/home) 0/4 0 Available > AUTOMNT, Read/Write, Device:66, ACLS=N > File System Owner : TEC2 Automove=E Client=N > System List (Exclude) : TEC1 > Filetag : T=off codeset=0 > TEC1:$ > > You would likely have to run a CRON job to do this, so that it is not > forgotten post-ipl? > > Are you saying that the operating system doesnt honor these commands on > shutdown? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS File System Automove question
On Mon, 20 Mar 2023 13:04:44 +, Mark Jacobs wrote: >Thanks, but that's not helpful in my situation. The problematic file system is >under /u which is under the sysplex root, That has to be automove. > >Mark Jacobs > Correct. Then the only way to "avoid" a lpar is to avoid it with the sysplex root too. Have you tried the chmount commands? TEC1:$ chmount -D TEC2 /home TEC1:$ df -vk /home Mounted on FilesystemAvail/TotalFiles Status /home (*AMD/home) 0/40 Available AUTOMNT, Read/Write, Device:66, ACLS=N File System Owner : TEC2Automove=Y Client=N Filetag : T=off codeset=0 TEC1:$ chmount -a exclude,TEC1 /home TEC1:$ df -vk /home Mounted on FilesystemAvail/TotalFiles Status /home (*AMD/home) 0/40 Available AUTOMNT, Read/Write, Device:66, ACLS=N File System Owner : TEC2Automove=E Client=N System List (Exclude) : TEC1 Filetag : T=off codeset=0 TEC1:$ You would likely have to run a CRON job to do this, so that it is not forgotten post-ipl? Are you saying that the operating system doesnt honor these commands on shutdown? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS File System Automove question
Thanks, but that's not helpful in my situation. The problematic file system is under /u which is under the sysplex root, That has to be automove. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com --- Original Message --- On Monday, March 20th, 2023 at 8:30 AM, Dave Jousma <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 20 Mar 2023 12:03:28 +, Mark Jacobs markjac...@protonmail.com > wrote: > > > I've been looking at that and testing somethings in our sandbox > > environment. The problematic file system that's already impacted us twice > > is being managed by automount and I can't see anyway to instruct OMVS not > > to automove filesystems that are managed by the automount policy. > > > > Mark Jacobs > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > Mark, I cant tell from your description if you want automove, or not, or just > not to the one certain system. Looks like the next directory up controls what > happens and where, not the /AMD directory itself. > > > Have you seen this info yet: > https://www.ibm.com/docs/en/zos/2.3.0?topic=descriptions-automount-configure-automount-facility > > The automount file system (*AMD/) is mounted with an automove attribute of > either AUTOMOVE or UNMOUNT. The automove attribute is set to UNMOUNT only > when its parent file system has its automove attribute set to UNMOUNT. When > the automove attribute is set to UNMOUNT, the owning system of the automount > file system is identical to the owning system of the parent. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS File System Automove question
On Mon, 20 Mar 2023 12:03:28 +, Mark Jacobs wrote: >I've been looking at that and testing somethings in our sandbox environment. >The problematic file system that's already impacted us twice is being managed >by automount and I can't see anyway to instruct OMVS not to automove >filesystems that are managed by the automount policy. > >Mark Jacobs > > >Sent from ProtonMail, Swiss-based encrypted email. > Mark, I cant tell from your description if you want automove, or not, or just not to the one certain system. Looks like the next directory up controls what happens and where, not the /AMD directory itself. Have you seen this info yet: https://www.ibm.com/docs/en/zos/2.3.0?topic=descriptions-automount-configure-automount-facility The automount file system (*AMD/) is mounted with an automove attribute of either AUTOMOVE or UNMOUNT. The automove attribute is set to UNMOUNT only when its parent file system has its automove attribute set to UNMOUNT. When the automove attribute is set to UNMOUNT, the owning system of the automount file system is identical to the owning system of the parent. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS File System Automove question
I've been looking at that and testing somethings in our sandbox environment. The problematic file system that's already impacted us twice is being managed by automount and I can't see anyway to instruct OMVS not to automove filesystems that are managed by the automount policy. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com --- Original Message --- On Sunday, March 19th, 2023 at 7:08 AM, David Geib wrote: > This link has more details about file system movement/ownership during > recovery scenarios. > > https://www.ibm.com/docs/en/zos/2.4.0?topic=recovery-managing-movement-data > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS File System Automove question
This link has more details about file system movement/ownership during recovery scenarios. https://www.ibm.com/docs/en/zos/2.4.0?topic=recovery-managing-movement-data -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS File System Automove question
Check the INCLUDE/EXCLUDE parameters on the MOUNT statements in BPXPRMxx https://www.ibm.com/docs/en/zos/2.4.0?topic=parameters-statements-bpxprmxx -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OMVS File System Automove question
When the owning system is removed from the sysplex is there a way to influence which remaining systems becomes the owner of the file system? I'd like a way to tell OMVS not to assign any automoved file systems to one specific system in the sysplex. Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
