/SERVICE/ alone cannot handle more than one release (or maintenance level) 

What I was talking about was using Automount to manage /SERVICE in a manner 
similar to the way many shops manage /u. When a path beginning with 
/SERVICE/RES001 is referenced by SMP/E, a filesystem named, e.g. 
SYS1.OMVS.RES001 will be mounted at that mount point, which Automount manages 

The DDDEFs for the Unix paths are edited using ZONEEDIT as Tom Conley wrote in 
another post. The only difference is that the path names all start with 
/SERVICE/resvol/ rather than just /SERVICE/ or just /resvol/. The reason is 
that you can't automount manage /.

On Tue, 13 Feb 2018 22:24:47 +0000, Jesse 1 Robinson wrote:

>This schema looks good, but I don't understand how '/SERVICE/' alone can 
>handle more than one z/OS release concurrently. We use '/OSRxx/' where xx 
>represents the version/release such as 12, 13, 21, 23. That way any number of 
>releases can be managed and *distinguished* concurrently. This has served us 
>well since OMVS was introduced. Besides handling the transition from one 
>ver/rel to another, we have at times had to keep more than one in production 
>for extended periods. 
>-----Original Message-----
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Tom Marchant
>Sent: Tuesday, February 13, 2018 6:09 AM
>Subject: (External):Re: Best Practices for z/OS Maintenance
>3)  More DASD, more flexibility
>Clone SYSRES, DLIB and USS Filesystems as needed. Choose 4 or 5 unique 
>characters for each that will become part of the SYSRES VOLSER(s), DLIB 
>VOLSER(s), Target zone name, and Distribution zone name. The zFS filesystem 
>name includes the SYSRES VOLSER as part of the name and it is mounted using 
>&SYSR1. DDDEFs in target zone TZONE for Unix paths are mounted at 
>/SERVICE/TZONE and /SERVICE is automount managed, so that the correct 
>Filesystem is always used.
>When a SYSRES, DLIB and USS Filesystem set is no longer needed, get rid of it. 
>Setting this all up is a bit of work, but once done, it works very well.
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to