Thanks, Glenn. This is the same thing that I did, except that I established an Automount policy to mount the HFS when it is referenced. For the simple case of managing the MVS root (Version) HFS, it looks like this.
/etc/auto.master contains this: /service /etc/service.map /etc/service.map looks like this: name * type HFS filesystem OMVS.<uc_name>.ROOT mode rdwr duration 10 delay 10 Thus, when SMP/E references /service/ASR41Z/, Automount will automatically mount OMVS.ASR41Z.ROOT at that mount point. The duration and delay specification of ten minutes each means that the HFS will remain mounted for ten minutes regardless of access, then after the initial ten minutes, the HFS will be unmounted after it has not been referenced for ten minutes. This part of it works beautifully, and it has the additional advntage that I can't mount the wrong HFS at /service/ASR41Z/. The problem is that Java is then expected to be mounted at /service/ASR41Z/usr/lpp/java, but I can't use Automount to manage that mount point, because Automount uses the lowest level directory to build the HFS name. My initial solution is to change my /etc/auto.master like this: /service/mvs /etc/service_mvs.map /service/java /etc/service_java.map My /etc/service/map, as above is renamed to /etc/service_mvs.map and I have created /etc/service_java.map, which looks the same, except that the HFS that is mounted is OMVS.<uc_name>.JV390. Now, when I service the ASR41Z target zone, I will mount OMVS.ASR41Z.ROOT at /service/mvs/ASR41Z/ and OMVS.ASR41Z.JV390 at /service/java/ASR41Z/. I can change my path for JAVA to /service/java/ASR41Z/J1.4 and everything works fine until AJVSCRPT is called to unwind the tarball. It fails, because it expects the J1.4 directory to be at /service/java/ASR41Z/usr/lpp/java/J1.4. My solution is to create a /usr/lpp/java symbolic link in the Java HFS root so that AJVSCRPT can find /service/java/ASR41Z/usr/lpp/java/J1.4. Thanks agaib, Tom Marchant --- Glenn Miller <[EMAIL PROTECTED]> wrote: Snip! > We have > four SYSRES volumes ( named: ASR41Z, ASR42Z, ASR43Z & ASR44Z ) that > support > these seven z/OS images. Each z/OS R4 SYSRES volume may have a > different > 'maintenance level' applied to it. Our preference is to apply our z/OS > maintenance to > these SYSRES volumes in numeric order, sometimes that is not possible. > So, > we > addressed this requirement by taking the '/service' concept one level > further. We created > a second-level directory to the '/service' directory and added that > second-level directory > to the HFS DDDEFs within each Target Zone. For example: > > > ASR41Z /service/ASR41Z/ > ASR42Z /service/ASR42Z/ > ASR43Z /service/ASR43Z/ > ASR44Z /service/ASR44Z/ > > > The above structure allows me another way to cross check the DDDEFs in a > Target Zone Snip! > > Glenn Miller ---------------------------------------------------------------------- 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
