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. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-----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
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Best Practices for z/OS Maintenance

On Fri, 9 Feb 2018 04:46:33 +0000, Craig Pace wrote:

>I always kept a SERVICE copy of the filesystems that were IBM related and then 
>applied and that is what SMP/E pointed to.  Each shop usually has what works 
>best for them, but below are the two main ways that I have done it.
>
>1)  Less Work, but Less Control (from SMP/E that is if someone bypasses SMP/E).
>
>Have a single set of RESVOLs, DLIBVOLs and USS Filesystem libraries that SMP/E 
>points toward.  If you have a stand-along Tech LPAR or Sandbox, have the 
>ability to IPL from this only for validation, but I try to keep this just for 
>SMP/E only!
>
>2)  More Work/More SME/E Control
>
>Have a Tech set of SMP/E SYSRES, DLIB and USS Filesystems.  Applied all 
>initial maintenance (RECEIVE, APPLY, ACCEPT) to this as normal 
>processing
>
>Have a separate SMP/E SYSRES, DLIB and USS Filesystems per shared (or single) 
>environment.  Once maintenance is validated within the Tech environment, you 
>can run SMP/E compares between the Tech and next environment to dynamically 
>create the required SMP/E input statement to APPLY and/or ACCEPT as needed.
>

Or, my preference:
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.

--
Tom Marchant

----------------------------------------------------------------------
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