Re: Best Practices for z/OS Maintenance

[Jousma, David]

We also use the RESVOL as the base mount point, but then mount ALL of the 
filesystems starting with the SMPE serviced ROOT, and everything else.   Then 
you have the entire tree available for SMPE maintenance.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Wednesday, February 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 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 since I was working as a sysprog and doing 
this stuff, and things like z/OSMF and Java complicate it. One solution might 
be to use /service/mvs/resvol, service/java/resvol, service/zosmf/resvol, etc. 
And now it's getting uglier...

I wonder if Art G. remembers how we handled it.

--
Tom Marchant

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: Best Practices for z/OS Maintenance

[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 since I was working 
as a sysprog and doing this stuff, and things like z/OSMF and Java 
complicate it. One solution might be to use /service/mvs/resvol, 
service/java/resvol, service/zosmf/resvol, etc. And now it's 
getting uglier...

I wonder if Art G. remembers how we handled it.

-- 
Tom Marchant

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

[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: Best Practices for z/OS Maintenance

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

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

Re: Best Practices for z/OS Maintenance

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

Re: Best Practices for z/OS Maintenance

[Tom Marchant]

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

On Tue, 13 Feb 2018 22:24:47 +, 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
>To: IBM-MAIN@LISTSERV.UA.EDU
>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 
> 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

Re: Best Practices for z/OS Maintenance

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



I rise in support of my good friend, the distinguished gentleman from 
SoCal, and proffer another option.  I now use the mountpoint / 
for my version root, so /Z21RS1, /Z21RS2, etc.  /SERVICE is so last 
century.  PITA to maintain, PITA to keep current.  With the volume name 
as the mount point, mounting and maintaining the version filesystem is a 
snap.  Just edit the path name to change all the paths after your 
ZONECOPY, and you're done.  If you have a symbol for your alternate res, 
you can mount the offline filesystem at IPL time.


Regards,
Tom Conley

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

Re: Best Practices for z/OS Maintenance

[Jesse 1 Robinson]

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

Re: Best Practices for z/OS Maintenance

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

Re: Best Practices for z/OS Maintenance

[Seymour J Metz]

Just that issue, or the whole question of what paradigms to use for maintenance 
and rollout? Will your presentation be available online?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Tom 
Conley <pinnc...@rochester.rr.com>
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 target file system with production 
> files, whether in /etc and /var or elsewhere.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
> Dyck, Lionel B. (TRA) <lionel.d...@va.gov>
> 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

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

Re: Best Practices for z/OS Maintenance

[Mark Jacobs - Listserv]

Usually when I did a new zOS upgrade I used the /var filesystem that shipped 
with that release, as well as the /etc file system. Made whatever necessary 
changes to the new /etc that we needed and moved along. Cloned the new /var and 
/etc file systems to each system in the sysplex.

Mark Jacobs


Jesse 1 Robinson<mailto:jesse1.robin...@sce.com>
February 9, 2018 at 2:41 PM
Thanks. That seems obvious, but I generally use the SMPE dialog, which lists 
only one DDDEF at a time. I did a batch LIST DDDEF and found the same result: 
no reference to /etc or /var. I feel much better.

OTOH I think we're remiss in looking for new or modified /etc or /var values in 
a new release to incorporate in our local file systems. Is this just a matter 
of IEYEBALL inspection?

.
.
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<mailto:robin...@sce.com>


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

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President 
david.jou...@53.com<mailto:david.jou...@53.com>
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, February 09, 2018 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto: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**

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 said previously, 
our /etc and /var file systems in production are 'permanent' in that they are 
not updated by our maintenance migration. But I am concerned about the 
situation on the (only) system where we actually run SMPE.

.
.
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<mailto:robin...@sce.com>


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


SMP/E LIST DDDEF will confirm that assumption. It's been a while since I've had 
to do z/OS maintenance, but I've learned not to take anything for granted with 
SMP/E, and especially with z/OS UNIX filesystems.

IF you find any DDDEFs pointing to /etc or /var, they would need to be changed 
to some variation of /service as you hopefully do with your version FS. If you 
manage multiple target and distribution pairs, I highly recommend using 
automount to ensure SMP/E mounts the matching version root FS for the target 
zone and SYSRES. A colleague (who frequents this list), set this up at a prior 
shop of ours. It was not trivial. He had a ServiceLink Q open with IBM for 
weeks, and there was much discussion among the team and extensive testing. 
However, once the various maps were defined (we had to support multiple 
versions of languages as well), the DDDEFs were updated, and we modified our 
cloning process to keep up, everything worked flawlessly.

IJS, I would not take the lack of errors as a golden stamp of approval. We were 
burned badly by this assumption - our SYSRES and version FS (and SMP/E) got out 
of sync, and we had no obvious indication. If memory serves, we had to dig 
through the SMP/E LOG (the job SYSOUT was probably long gone) to find that 
SMP/E had done exactly what it was told to do: apply UNIX elements to the wrong 
path/filesystem.

Art

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


Please be alert for any emails that may ask you for login information or 
directs you to login via a link. If you believe this message is a phish or 
aren't sure whether this message is trustworthy, please send the original 
message as an attachment to 
'phish...@meredith.com<mailto:phish...@meredith.com>'.


--

Mark Jacobs
Time Customer Service
Global Technology Services

Re: Best Practices for z/OS Maintenance

[Carmen Vitullo]

I use the Unix diff command to review and differences between what's in my 
order and what we have customized on prod 

4) Compare the two filesystems and direct output to a file by issuing the shell 
command: 
diff -r /ServerPac/etc /Service/TST1/etc > 
/u/jistxxx/TST1_etc_compare_zos112.txt 

Carmen Vitullo 

- Original Message -

From: "Jesse 1 Robinson" <jesse1.robin...@sce.com> 
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 one DDDEF at a time. I did a batch LIST DDDEF and found the same result: 
no reference to /etc or /var. I feel much better. 

OTOH I think we're remiss in looking for new or modified /etc or /var values in 
a new release to incorporate in our local file systems. Is this just a matter 
of IEYEBALL inspection? 

. 
. 
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 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 references in my V2.3 
target zones for anything /etc or /var or /Service/etc or /Service/var 

_ 
Dave Jousma 
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson 
Sent: Friday, February 09, 2018 1:32 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** 

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 said previously, 
our /etc and /var file systems in production are 'permanent' in that they are 
not updated by our maintenance migration. But I am concerned about the 
situation on the (only) system where we actually run SMPE. 

. 
. 
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 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 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/E LIST DDDEF will confirm that assumption. It's been a while since I've had 
to do z/OS maintenance, but I've learned not to take anything for granted with 
SMP/E, and especially with z/OS UNIX filesystems. 

IF you find any DDDEFs pointing to /etc or /var, they would need to be changed 
to some variation of /service as you hopefully do with your version FS. If you 
manage multiple target and distribution pairs, I highly recommend using 
automount to ensure SMP/E mounts the matching version root FS for the target 
zone and SYSRES. A colleague (who frequents this list), set this up at a prior 
shop of ours. It was not trivial. He had a ServiceLink Q open with IBM for 
weeks, and there was much discussion among the team and extensive testing. 
However, once the various maps were defined (we had to support multiple 
versions of languages as well), the DDDEFs were updated, and we modified our 
cloning process to keep up, everything worked flawlessly. 

IJS, I would not take the lack of errors as a golden stamp of approval. We were 
burned badly by this assumption - our SYSRES and version FS (and SMP/E) got out 
of sync, and we had no obvious indication. If memory serves, we had to dig 
through the SMP/E LOG (the job SYSOUT was probably long gone) to find that 
SMP/E had done exactly what it was told to do: apply UNIX elements to the wrong 
path/filesystem. 

Art 

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


--
For IBM-MAIN subscribe / signoff / archive access

Re: Best Practices for z/OS Maintenance

[Jesse 1 Robinson]

Thanks. That seems obvious, but I generally use the SMPE dialog, which lists 
only one DDDEF at a time. I did a batch LIST DDDEF and found the same result: 
no reference to /etc or /var. I feel much better.

OTOH I think we're remiss in looking for new or modified /etc or /var values in 
a new release to incorporate in our local file systems. Is this just a matter 
of IEYEBALL inspection?  

.
.
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 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 references in my V2.3 
target zones for anything /etc or /var or /Service/etc or /Service/var

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, February 09, 2018 1:32 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**

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 said previously, 
our /etc and /var file systems in production are 'permanent' in that they are 
not updated by our maintenance migration. But I am concerned about the 
situation on the (only) system where we actually run SMPE.  

.
.
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 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 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/E LIST DDDEF will confirm that assumption.  It's been a while since I've 
had to do z/OS maintenance, but I've learned not to take anything for granted 
with SMP/E, and especially with z/OS UNIX filesystems.  

IF you find any DDDEFs pointing to /etc or /var, they would need to be changed 
to some variation of /service as you hopefully do with your version FS.  If you 
manage multiple target and distribution pairs, I highly recommend using 
automount to ensure SMP/E mounts the matching version root FS for the target 
zone and SYSRES.  A colleague (who frequents this list), set this up at a prior 
shop of ours.  It was not trivial.  He had a ServiceLink Q open with IBM for 
weeks, and there was much discussion among the team and extensive testing.  
However, once the various maps were defined (we had to support multiple 
versions of languages as well), the DDDEFs were updated, and we modified our 
cloning process to keep up, everything worked flawlessly.

IJS, I would not take the lack of errors as a golden stamp of approval.  We 
were burned badly by this assumption - our SYSRES and version FS (and SMP/E) 
got out of sync, and we had no obvious indication.  If memory serves, we had to 
dig through the SMP/E LOG (the job SYSOUT was probably long gone) to find that 
SMP/E had done exactly what it was told to do:  apply UNIX elements to the 
wrong path/filesystem.

Art

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

Re: Best Practices for z/OS Maintenance

[Carmen Vitullo]

I found this from a PMR I opened about 10 years ago asking about /etc or /var 
updates, the response from IBM then was and I believe still is fact; 



IBM will not via SMP/E apply place anything in either the /etc or 
/var directories, thus it is not necessary to mount them for the 
SMP/E apply portion of the maintenance upgrade process. 
If any updates are required they would be as hold actions in 
the applicable ptf's, and as such the /etc and /var hfs data sets 
can be mounted separately to facilitate the required updates. 
If you do require that the directories be changed back to real 
directories for another purpose, then SYS1.SAMPLIB member BPXISETD 
will convert the symbolic links back to real directories, and BPXISETS 
will convert the directories back to symbolic links. 

Carmen Vitullo 

- Original Message -

From: "David Jousma" <david.jou...@53.com> 
To: IBM-MAIN@LISTSERV.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 or /Service/var 

_ 
Dave Jousma 
Manager Mainframe Engineering, Assistant Vice President 
david.jou...@53.com 
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H 
p 616.653.8429 
f 616.653.2717 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson 
Sent: Friday, February 09, 2018 1:32 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** 

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 said previously, 
our /etc and /var file systems in production are 'permanent' in that they are 
not updated by our maintenance migration. But I am concerned about the 
situation on the (only) system where we actually run SMPE. 

. 
. 
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 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 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/E LIST DDDEF will confirm that assumption. It's been a while since I've had 
to do z/OS maintenance, but I've learned not to take anything for granted with 
SMP/E, and especially with z/OS UNIX filesystems. 

IF you find any DDDEFs pointing to /etc or /var, they would need to be changed 
to some variation of /service as you hopefully do with your version FS. If you 
manage multiple target and distribution pairs, I highly recommend using 
automount to ensure SMP/E mounts the matching version root FS for the target 
zone and SYSRES. A colleague (who frequents this list), set this up at a prior 
shop of ours. It was not trivial. He had a ServiceLink Q open with IBM for 
weeks, and there was much discussion among the team and extensive testing. 
However, once the various maps were defined (we had to support multiple 
versions of languages as well), the DDDEFs were updated, and we modified our 
cloning process to keep up, everything worked flawlessly. 

IJS, I would not take the lack of errors as a golden stamp of approval. We were 
burned badly by this assumption - our SYSRES and version FS (and SMP/E) got out 
of sync, and we had no obvious indication. If memory serves, we had to dig 
through the SMP/E LOG (the job SYSOUT was probably long gone) to find that 
SMP/E had done exactly what it was told to do: apply UNIX elements to the wrong 
path/filesystem. 

Art 


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails** 

This e-mail transmission contains information that is confidential and may be 
privileged. It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this informati

Re: Best Practices for z/OS Maintenance

[Jousma, David]

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

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, February 09, 2018 1:32 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**

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 said previously, 
our /etc and /var file systems in production are 'permanent' in that they are 
not updated by our maintenance migration. But I am concerned about the 
situation on the (only) system where we actually run SMPE.  

.
.
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 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 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/E LIST DDDEF will confirm that assumption.  It's been a while since I've 
had to do z/OS maintenance, but I've learned not to take anything for granted 
with SMP/E, and especially with z/OS UNIX filesystems.  

IF you find any DDDEFs pointing to /etc or /var, they would need to be changed 
to some variation of /service as you hopefully do with your version FS.  If you 
manage multiple target and distribution pairs, I highly recommend using 
automount to ensure SMP/E mounts the matching version root FS for the target 
zone and SYSRES.  A colleague (who frequents this list), set this up at a prior 
shop of ours.  It was not trivial.  He had a ServiceLink Q open with IBM for 
weeks, and there was much discussion among the team and extensive testing.  
However, once the various maps were defined (we had to support multiple 
versions of languages as well), the DDDEFs were updated, and we modified our 
cloning process to keep up, everything worked flawlessly.

IJS, I would not take the lack of errors as a golden stamp of approval.  We 
were burned badly by this assumption - our SYSRES and version FS (and SMP/E) 
got out of sync, and we had no obvious indication.  If memory serves, we had to 
dig through the SMP/E LOG (the job SYSOUT was probably long gone) to find that 
SMP/E had done exactly what it was told to do:  apply UNIX elements to the 
wrong path/filesystem.

Art


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: Best Practices for z/OS Maintenance

[Jesse 1 Robinson]

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 said previously, 
our /etc and /var file systems in production are 'permanent' in that they are 
not updated by our maintenance migration. But I am concerned about the 
situation on the (only) system where we actually run SMPE.  

.
.
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 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 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/E LIST DDDEF will confirm that assumption.  It's been a while since I've 
had to do z/OS maintenance, but I've learned not to take anything for granted 
with SMP/E, and especially with z/OS UNIX filesystems.  

IF you find any DDDEFs pointing to /etc or /var, they would need to be changed 
to some variation of /service as you hopefully do with your version FS.  If you 
manage multiple target and distribution pairs, I highly recommend using 
automount to ensure SMP/E mounts the matching version root FS for the target 
zone and SYSRES.  A colleague (who frequents this list), set this up at a prior 
shop of ours.  It was not trivial.  He had a ServiceLink Q open with IBM for 
weeks, and there was much discussion among the team and extensive testing.  
However, once the various maps were defined (we had to support multiple 
versions of languages as well), the DDDEFs were updated, and we modified our 
cloning process to keep up, everything worked flawlessly.

IJS, I would not take the lack of errors as a golden stamp of approval.  We 
were burned badly by this assumption - our SYSRES and version FS (and SMP/E) 
got out of sync, and we had no obvious indication.  If memory serves, we had to 
dig through the SMP/E LOG (the job SYSOUT was probably long gone) to find that 
SMP/E had done exactly what it was told to do:  apply UNIX elements to the 
wrong path/filesystem.

Art


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

Re: Best Practices for z/OS Maintenance

[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/E LIST DDDEF will confirm that assumption.  It's been a while since I've 
had to do z/OS maintenance, but I've learned not to take anything for granted 
with SMP/E, and especially with z/OS UNIX filesystems.  

IF you find any DDDEFs pointing to /etc or /var, they would need to be changed 
to some variation of /service as you hopefully do with your version FS.  If you 
manage multiple target and distribution pairs, I highly recommend using 
automount to ensure SMP/E mounts the matching version root FS for the target 
zone and SYSRES.  A colleague (who frequents this list), set this up at a prior 
shop of ours.  It was not trivial.  He had a ServiceLink Q open with IBM for 
weeks, and there was much discussion among the team and extensive testing.  
However, once the various maps were defined (we had to support multiple 
versions of languages as well), the DDDEFs were updated, and we modified our 
cloning process to keep up, everything worked flawlessly.

IJS, I would not take the lack of errors as a golden stamp of approval.  We 
were burned badly by this assumption - our SYSRES and version FS (and SMP/E) 
got out of sync, and we had no obvious indication.  If memory serves, we had to 
dig through the SMP/E LOG (the job SYSOUT was probably long gone) to find that 
SMP/E had done exactly what it was told to do:  apply UNIX elements to the 
wrong path/filesystem.

Art

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

Re: Best Practices for z/OS Maintenance

[Jousma, David]

Lionel,

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.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion 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 unexpected 
emails**

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

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

[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=02%7C01%7CCraig.Pace%40FOTLINC.COM%7Cf70440474759
> 4fd459a508d56f6a2a02%7C899afa299b73498f8294e6528bc00a38%7C0%7C0%7C6365
> 37424132131227=NoTyURkvnydFn4sjbHcS0p%2F88l6ug%2BD1H47vbUUF%2By8
> %3D=0
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on
> behalf of Dyck, Lionel B. (TRA) <lionel.d...@va.gov>
> 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

Re: Best Practices for z/OS Maintenance

[Tom Conley]

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
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Dyck, 
Lionel B. (TRA) <lionel.d...@va.gov>
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

Re: Best Practices for z/OS Maintenance

[Jesse 1 Robinson]

For us, both /etc and /var live their own respective file systems that are not 
touched by standard migration from SMPE install to prod. Hence there's no 
danger of overlaying installation values. OTOH, as Shmuel says, the problem is 
how to propagate an updated install value into production. First of all it 
would have to be a manual process, but how to know when/whether to perform such 
an update? I can't suggest an algorithmic way to do this, but I'm not an OMVS 
whiz by any means.  

.
.
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 Seymour J Metz
Sent: Thursday, February 08, 2018 12:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (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.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Dyck, Lionel B. (TRA) <lionel.d...@va.gov>
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

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


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

Re: Best Practices for z/OS Maintenance

[Seymour J Metz]

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.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Dyck, Lionel B. (TRA) <lionel.d...@va.gov>
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

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


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

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

Best Practices for z/OS Maintenance

[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

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


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