I did my first z/OS (from OS390) as /Zervice. I've been able to alternate that 
with /Service :) 

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]]
> On Behalf Of Jesse 1 Robinson
> Sent: Saturday, May 07, 2016 3:07 PM
> To: [email protected]
> Subject: Re: Mounting Unique zFS for SMPE APPLY
> 
> The problem with a generic name like /Service is that for some transitional
> period at least, you most likely need to maintain a viable SMPE environment
> for two different releases: the current production level and some new level
> being installed and rolled out. That's why we use, for example, /OSR13 and
> /OSR21--with similarly named zFS--in order to manage them independently.
> 
> 
> 
> Production names drop the OSRxx prefix. So on the SMPE system, we have
> (up to) three distinct sets of zFS with names that make them easily
> identifiable.
> 
> 
> 
> .
> 
> .
> 
> .
> 
> J.O.Skip Robinson
> 
> Southern California Edison Company
> 
> Electric Dragon Team Paddler
> 
> SHARE MVS Program Co-Manager
> 
> 323-715-0595 Mobile
> 
> 626-302-7535 Office
> 
> [email protected]
> 
> 
> 
> 
> 
> -----Original Message-----
> 
> From: IBM Mainframe Discussion List [mailto:[email protected]]
> On Behalf Of Lucas Rosalen
> 
> Sent: Friday, May 06, 2016 4:54 PM
> 
> To: [email protected]
> 
> Subject: (External):Re: Mounting Unique zFS for SMPE APPLY
> 
> 
> 
> True thing!
> 
> If SMPE is pointing to some directory that's not the "hot" one (under
> /Service, usually), then no SMPE update would be required. Simply mounting
> the "new" filesystem under the correct directory would work.
> 
> If SMPE is pointing to the "hot" path (which is weird), then it would require
> either the SMPE DDDEF update or a JCL DD override to the SMPE setup.
> 
> 
> 
> Anyway, it's a good idea to have a convention to easily identify the
> Maintenance filesystem and the Production one - could be a simple char in
> datasets names or something else...
> 
> 
> 
> Regards,
> 
> 
> 
> --------------------------------------------------------------------------------------------------------
> -----------------------
> 
> *Lucas Rosalen*
> 
> Emails: [email protected] / *[email protected]
> 
> <[email protected]>*
> 
> LinkedIn: https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__br.linkedin.com_in_lrosalen&d=CwIGaQ&c=C3yme8gMkxg_ihJNXS06Zy
> Wk4EJm8LdrrvxQb-
> Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=FimZwB1mJyzrixN5i8vA_1wAjZwB
> UF9alrQFnPX_oko&s=pE6lLzln_srXlpZyiUP_BI641vAUvtVx6BAgf3K4N1c&e=
> 
> Phone: +48 (71) 792 809 198
> 
> 
> 
> 
> 
> 2016-05-06 16:16 GMT-03:00 Paul Gilmartin <
> 
> [email protected]>:
> 
> 
> 
> > On Fri, 6 May 2016 19:42:05 +0200, Lucas Rosalen wrote:
> 
> >
> 
> > >ADRDSSU copy with RENAME and either DDDEF update on SMPE or DD
> 
> > >statement
> 
> > in
> 
> > >JCL will do the trick.
> 
> > >
> 
> > Doesn't SMP/E employ UNIX pathnames rather than DFSMF data set names,
> 
> > making it harder to trick.
> 
> >
> 
> > Copy; update; copy back.  Ouch!  And the filesystems must be quiesced
> 
> > (or R/O) during the copy processes.
> 
> >
> 
> > If you're sharing zFS, can they be mounted at distinct mountpoints and
> 
> > SMP/E apprised of this in DDDEFs or symlinks?  (Unless the supplier
> 
> > relies on absolute pathnames.)  chroot?
> 
> >
> 
> > See "rcopy" thread current in MVS-OE.  pax may require prohibitive
> 
> > bandwidth.
> 
> >
> 
> > >On May 6, 2016 19:23, "George Henke" wrote:
> 
> > >
> 
> > >The zFS names on our SMPE maintenance system are the same as on the
> 
> > >PROD RES VOLS.
> 
> > >
> 
> > >How do you make them unique so they can be mounted on the SMPE
> 
> > >maintenance system for the SMPE APPLYs?
> 
> > >
> 
> > >I suppose just DSS copy and rename them to something else?
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------
> 
> For IBM-MAIN subscribe / signoff / archive access instructions,
> 
> send email to [email protected] with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to