Re: [EXTERNAL] Re: Best Practices for z/OS Maintenance

2018-02-14 Thread Sankaranarayanan, Vignesh
"what DFDSS does with respect to DUMPing and COPYing zFS filesystems, quite the 
nightmare "

Hey Tom,

In the tiniest chances that you're seeing some zFS not being updated, I would 
suggest reviewing the DSS dump job to see if all he zFSes you intended to dump 
got dumped.
I learnt only recently that DUMP will just ignore migrated datasets; good thing 
I checked the count of my source 'Service' zFS files against the 'resvol' zFS 
set.

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: 14 February 2018 19:35
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Best Practices for z/OS Maintenance

On 2/14/2018 7:58 AM, Tom Marchant wrote:
> /SERVICE/ alone cannot handle more than one release (or maintenance level) 
> concurrently.
>
> 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 
> automatically.
>
> 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 /.
>

Tommee likeee this automount idea, I'll have to check it out.  It would solve 
one problem I have with cloning zFS's, where DFDSS does weird
(stuff) if the zFS filesystem is mounted.  Currently have a six-month PMR open 
with IBM trying to hammer out exactly what DFDSS does with respect to DUMPing 
and COPYing zFS filesystems, quite the nightmare.  I may owe you a beer 
Monsieur Marchant.

Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: [EXTERNAL] Re: Best Practices for z/OS Maintenance

2018-02-08 Thread Craig Pace
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!

Share SYSRES and/or USS Filesystems where possible.  Makes life a lot easier 
with maintenance.

Have two copies per LPAR(s), that can be alternated between during IPLs.  A lot 
of maintenance can be applied live these days; however, there are still ones 
that still required an IPL.

Perform a DFDSS copy of the required volumes and filesystems from the SMP/E 
target to the LPAR(s) target.

For USS, all configuration files, etc. that are normally in /etc & /var are 
never overwritten by IBM.  The sample configuration files are what are updated 
and then you must apply those changes or merge your updates with the new 
samples, if required or needed.  I also use a Company level filesystem, where 
you can override the default path, as this makes upgrades even easier.  Most of 
the items that you put in /etc & /var can be overridden by parameters passed 
during execution or profile settings.

2)  More Work/More SMP/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.

For USS, same concept as the first method.

The trick is to simply the process as much as possible without loosing control. 
 The smaller the support team, the less SMP/E management you can allow.  If you 
have people that don't follow the rules or too large (multiple teams, etc.) 
Allowing more control by SMP/E can save you a lot of headache with keeping 
things in sync.



Thanks,


Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Thursday, February 8, 2018 21:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Best Practices for z/OS Maintenance

On 2/8/2018 3:22 PM, Seymour J Metz wrote:
> SMP should not be pointing at the live Unix directories. The real question is 
> how to merge  new/changed files in the target file system with production 
> files, whether in /etc and /var or elsewhere.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gm
> u.edu%2F~smetz3&data=02%7C01%7CCraig.Pace%40FOTLINC.COM%7Cf70440474759
> 4fd459a508d56f6a2a02%7C899afa299b73498f8294e6528bc00a38%7C0%7C0%7C6365
> 37424132131227&sdata=NoTyURkvnydFn4sjbHcS0p%2F88l6ug%2BD1H47vbUUF%2By8
> %3D&reserved=0
>
> 
> From: IBM Mainframe Discussion List  on
> behalf of Dyck, Lionel B. (TRA) 
> Sent: Thursday, February 8, 2018 2:36 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Best Practices for z/OS Maintenance
>
> A question was asked what the best practices are for installing z/OS 
> maintenance to make sure that the /etc and /var files are not replaced by IBM 
> maintenance?
>
> (cross posting to MVS OpenEdition and IBM-Main Listservs)
>
> Thank you
>

I'm covering that in my Advanced SMP/E session at zTechU in Orlando and London, 
if IBM accepts the sessions.

Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying 
or use of this communication or the information in it is strictly prohibited. 
If you have received this communication in error, please notify the sender 
immediately and then destroy any copies of it.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN