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&search=markjac...@protonmail.com ------- Original Message ------- On Monday, March 20th, 2023 at 8:30 AM, Dave Jousma <000001a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 20 Mar 2023 12:03:28 +0000, 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
