Re: Best Practices for z/OS Maintenance

2018-02-15 Thread Jousma, David
14, 2018 1:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Best Practices for z/OS Maintenance **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** On Wed, 14 Feb 2018 09:38:46 -0600, Dana Mitchell wrote: >I like this too, is th

Re: Best Practices for z/OS Maintenance

2018-02-14 Thread Tom Marchant
On Wed, 14 Feb 2018 09:38:46 -0600, Dana Mitchell wrote: >I like this too, is there any way to handle recursive automounts like: > >OMVS.SIZUROOT.RES001 on /service/res001/usr/lpp/zosmf/ Alas, no, unless things have changed when I was doing this. And now I must confess that it has been a while

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

2018-02-14 Thread Sankaranarayanan, Vignesh
RV.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) > concurrentl

Re: Best Practices for z/OS Maintenance

2018-02-14 Thread Dana Mitchell
I like this too, is there any way to handle recursive automounts like: OMVS.SIZUROOT.RES001 on /service/res001/usr/lpp/zosmf/ Dana On Wed, 14 Feb 2018 09:04:52 -0500, Tom Conley wrote: >On 2/14/2018 7:58 AM, Tom Marchant wrote: >> /SERVICE/ alone cannot handle more than one release (or main

Re: Best Practices for z/OS Maintenance

2018-02-14 Thread Tom Conley
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

Re: Best Practices for z/OS Maintenance

2018-02-14 Thread Tom Marchant
es 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 >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (

Re: Best Practices for z/OS Maintenance

2018-02-13 Thread Tom Conley
On 2/13/2018 5:23 PM, 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

Re: Best Practices for z/OS Maintenance

2018-02-13 Thread Jesse 1 Robinson
ernal):Re: Best Practices for z/OS Maintenance On Fri, 9 Feb 2018 04:46:33 +, 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

Re: Best Practices for z/OS Maintenance

2018-02-13 Thread Tom Marchant
On Fri, 9 Feb 2018 04:46:33 +, 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

Re: Best Practices for z/OS Maintenance

2018-02-09 Thread Seymour J Metz
Conley Sent: Thursday, February 8, 2018 10:06 PM To: IBM-MAIN@listserv.ua.edu Subject: 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

Re: Best Practices for z/OS Maintenance

2018-02-09 Thread Mark Jacobs - Listserv
U<mailto:IBM-MAIN@LISTSERV.UA.EDU> Subject: (External):Re: Best Practices for z/OS Maintenance Just did the LIST DDDEF. As suspected, there are no references in my V2.3 target zones for anything /etc or /var or /Service/etc or /Service/var __

Re: Best Practices for z/OS Maintenance

2018-02-09 Thread Carmen Vitullo
s112.txt Carmen Vitullo - Original Message - From: "Jesse 1 Robinson" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, February 9, 2018 1:41:38 PM Subject: Re: Best Practices for z/OS Maintenance Thanks. That seems obvious, but I generally use the SMPE dialog, which lists only o

Re: Best Practices for z/OS Maintenance

2018-02-09 Thread Jesse 1 Robinson
ginal Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, February 09, 2018 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Best Practices for z/OS Maintenance Just did the LIST DDDEF. As suspected, there are no refer

Re: Best Practices for z/OS Maintenance

2018-02-09 Thread Carmen Vitullo
RV.UA.EDU Sent: Friday, February 9, 2018 1:17:26 PM Subject: Re: Best Practices for z/OS Maintenance Just did the LIST DDDEF. As suspected, there are no references in my V2.3 target zones for anything /etc or /var or /Service/etc

Re: Best Practices for z/OS Maintenance

2018-02-09 Thread Jousma, David
: Best Practices for z/OS Maintenance **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I would like to investigate this issue here, but I don't know how to find a DDDEF that might point to the /etc or /var file system. As I

Re: Best Practices for z/OS Maintenance

2018-02-09 Thread Jesse 1 Robinson
- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Art Gutowski Sent: Friday, February 09, 2018 9:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Best Practices for z/OS Maintenance >We don't mount the IBM provided /etc /var file systems for actual u

Re: Best Practices for z/OS Maintenance

2018-02-09 Thread Art Gutowski
>We don't mount the IBM provided /etc /var file systems for actual use. We >use those to compare with what we have. >AFAIK, there is NOT any SMPE that updates those anyway, its just what >Serverpac provides. >I never mount those filesystems for SMPE maintenance and never get any errors. SMP/

Re: Best Practices for z/OS Maintenance

2018-02-09 Thread Jousma, David
ssion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dyck, Lionel B. (TRA) Sent: Thursday, February 08, 2018 2:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Best Practices for z/OS Maintenance **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexp

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

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

Re: Best Practices for z/OS Maintenance

2018-02-08 Thread Tom Conley
/~smetz3 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

Re: Best Practices for z/OS Maintenance

2018-02-08 Thread Jesse 1 Robinson
: (External):Re: Best Practices for z/OS Maintenance 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 http://mason.

Re: Best Practices for z/OS Maintenance

2018-02-08 Thread Seymour J Metz
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

Best Practices for z/OS Maintenance

2018-02-08 Thread Dyck, Lionel B. (TRA)
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 --