Discussion:
Mischaracterized HOLDDATA
(too old to reply)
Pinnacle
2017-05-18 19:06:03 UTC
Permalink
Raw Message
For those of you who always laughed when I said read your HOLD(DOC) for
buried HOLD(ACTION) items. Here it is kids, so for those of you who
still ignore HOLD(DOC), keep telling yourselves that you're saving time
and I'm crazy for looking at HOLD(DOC).

++HOLD(UI43841) SYSTEM FMID(HSMA21A) REASON(DOC) DATE(17011)
COMMENT(
Perform the following RACF security steps,
or equivalent steps using your SAF product.
The SAMPLIB sample job, IZUCASEC contains these commented-out
RACF commands and is provided as an aid to perform these steps
if you choose to use it.

RDEFINE OPERCMDS MVS.MCSOPER.* UACC(NONE)

PERMIT MVS.MCSOPER.* CLASS(OPERCMDS) ID(IZUSVR) ACCESS(READ)

RDEFINE OPERCMDS (MVS.VARY.TCPIP.OBEYFILE) UACC(NONE)

PERMIT MVS.VARY.TCPIP.OBEYFILE ACCESS(CONTROL) CLASS(OPERCMDS)
ID(IZUSVR)

RDEFINE OPERCMDS (MVS.DISPLAY.*) UACC(NONE)

PERMIT MVS.DISPLAY.* CLASS(OPERCMDS) ID(IZUSVR) ACCESS(READ)

RDEFINE SERVAUTH EZB.NETSTAT.<mvsname>.<tcpprocname>.VIPADCFG
UACC(NONE)

PERMIT EZB.NETSTAT.<mvsname>.<tcpprocname>.VIPADCFG
CLASS(SERVAUTH) ID(IZUSVR) ACCESS(READ)

RDEFINE SERVAUTH EZB.NETWORKUTILS.CLOUD.<mvsname> UACC(NONE)

PERMIT EZB.NETWORKUTILS.CLOUD.<mvsname> CLASS(SERVAUTH)
ID(IZUSVR) ACCESS(READ)

Grant ALTER access to IZUSVR for the stack include and stack
dynamic update datasets if your system protects data sets with
SAF profiles. These are data sets you will create manually and
then reference in Configuration Assistant when you configure a
TCP/IP stack from the Systems tab in the Cloud perspective.

If the z/OS ROUTE command is protected by SAF, IZUSVR must have
READ access to the MVS.ROUTE.CMD.<system> SAF profile in the
OPERCMDS class.
**NOTE: <system> is the target MVS system name where
IBM Cloud Provisioning and Management for z/OS will provision
resources. e.g.

PERMIT MVS.ROUTE.CMD.<system> CLASS(OPERCMDS)
ID(IZUSVR) ACCESS(READ)

SETROPTS RACLIST(OPERCMDS,SERVAUTH) REFRESH
).



Regards,
Tom Conley

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Burrell, Todd
2017-05-18 19:09:52 UTC
Permalink
Raw Message
Well this really should have been labeled as HOLD(ACTION). And I usually look through the DOC for stuff like this, but I've never seen something quite so egregious.

Todd Burrell | Sr. Mainframe Systems Administrator
CSX Technologies| 550 Water St. (634I), Jacksonville, FL 32202


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Pinnacle
Sent: Thursday, May 18, 2017 3:07 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Mischaracterized HOLDDATA

For those of you who always laughed when I said read your HOLD(DOC) for buried HOLD(ACTION) items. Here it is kids, so for those of you who still ignore HOLD(DOC), keep telling yourselves that you're saving time and I'm crazy for looking at HOLD(DOC).

++HOLD(UI43841) SYSTEM FMID(HSMA21A) REASON(DOC) DATE(17011)
COMMENT(
Perform the following RACF security steps,
or equivalent steps using your SAF product.
The SAMPLIB sample job, IZUCASEC contains these commented-out
RACF commands and is provided as an aid to perform these steps
if you choose to use it.

RDEFINE OPERCMDS MVS.MCSOPER.* UACC(NONE)

PERMIT MVS.MCSOPER.* CLASS(OPERCMDS) ID(IZUSVR) ACCESS(READ)

RDEFINE OPERCMDS (MVS.VARY.TCPIP.OBEYFILE) UACC(NONE)

PERMIT MVS.VARY.TCPIP.OBEYFILE ACCESS(CONTROL) CLASS(OPERCMDS)
ID(IZUSVR)

RDEFINE OPERCMDS (MVS.DISPLAY.*) UACC(NONE)

PERMIT MVS.DISPLAY.* CLASS(OPERCMDS) ID(IZUSVR) ACCESS(READ)

RDEFINE SERVAUTH EZB.NETSTAT.<mvsname>.<tcpprocname>.VIPADCFG
UACC(NONE)

PERMIT EZB.NETSTAT.<mvsname>.<tcpprocname>.VIPADCFG
CLASS(SERVAUTH) ID(IZUSVR) ACCESS(READ)

RDEFINE SERVAUTH EZB.NETWORKUTILS.CLOUD.<mvsname> UACC(NONE)

PERMIT EZB.NETWORKUTILS.CLOUD.<mvsname> CLASS(SERVAUTH)
ID(IZUSVR) ACCESS(READ)

Grant ALTER access to IZUSVR for the stack include and stack
dynamic update datasets if your system protects data sets with
SAF profiles. These are data sets you will create manually and
then reference in Configuration Assistant when you configure a
TCP/IP stack from the Systems tab in the Cloud perspective.

If the z/OS ROUTE command is protected by SAF, IZUSVR must have
READ access to the MVS.ROUTE.CMD.<system> SAF profile in the
OPERCMDS class.
**NOTE: <system> is the target MVS system name where
IBM Cloud Provisioning and Management for z/OS will provision
resources. e.g.

PERMIT MVS.ROUTE.CMD.<system> CLASS(OPERCMDS)
ID(IZUSVR) ACCESS(READ)

SETROPTS RACLIST(OPERCMDS,SERVAUTH) REFRESH
).



Regards,
Tom Conley

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



This email transmission and any accompanying attachments may contain CSX privileged and confidential information intended only for the use of the intended addressee. Any dissemination, distribution, copying or action taken in reliance on the contents of this email by anyone other than the intended recipient is strictly prohibited. If you have received this email in error please immediately delete it and notify sender at the above CSX email address. Sender and CSX accept no liability for any damage caused directly or indirectly by receipt of this email.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-05-18 20:13:23 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
This is a swampy area captured in the caveat 'perform these steps if you choose to use it'.
Ugh.
Post by Jesse 1 Robinson
Well this really should have been labeled as HOLD(ACTION). And I usually look through the DOC for stuff like this, but I've never seen something quite so egregious.
Can IBM repair this even after the fact? I know SMPHOLD may contain
++HOLD ... ACTION. But I doubt that LIST ERRSYSMODS will show it,
so it does little to alert the programmer who relies on ERRSYSMODS
after APPLY and before deployment.

I could envision a ++HOLD ... ERROR resolved by a trivial PTF with
the corrected ++HOLD ... ACTION. Ugh.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-05-18 20:00:28 UTC
Permalink
Raw Message
This is a swampy area captured in the caveat 'perform these steps if you choose to use it'. If a shop has not already RDEFINEd MVS.MCSOPER.* with elaborate profile support in place, blandly issuing these commands as documented would immediately bring a shop to its knees. Putting a HOLD(ACTION) label on this bottomless can of worms would only increase the likelihood of operational catastrophe.

If you're inclined to take this action willy-nilly, be sure to update your resume beforehand.


.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Burrell, Todd
Sent: Thursday, May 18, 2017 12:11 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Mischaracterized HOLDDATA

Well this really should have been labeled as HOLD(ACTION). And I usually look through the DOC for stuff like this, but I've never seen something quite so egregious.

Todd Burrell | Sr. Mainframe Systems Administrator CSX Technologies| 550 Water St. (634I), Jacksonville, FL 32202


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Pinnacle
Sent: Thursday, May 18, 2017 3:07 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Mischaracterized HOLDDATA

For those of you who always laughed when I said read your HOLD(DOC) for buried HOLD(ACTION) items. Here it is kids, so for those of you who still ignore HOLD(DOC), keep telling yourselves that you're saving time and I'm crazy for looking at HOLD(DOC).

++HOLD(UI43841) SYSTEM FMID(HSMA21A) REASON(DOC) DATE(17011)
COMMENT(
Perform the following RACF security steps,
or equivalent steps using your SAF product.
The SAMPLIB sample job, IZUCASEC contains these commented-out
RACF commands and is provided as an aid to perform these steps
if you choose to use it.

RDEFINE OPERCMDS MVS.MCSOPER.* UACC(NONE)

PERMIT MVS.MCSOPER.* CLASS(OPERCMDS) ID(IZUSVR) ACCESS(READ)

RDEFINE OPERCMDS (MVS.VARY.TCPIP.OBEYFILE) UACC(NONE)

PERMIT MVS.VARY.TCPIP.OBEYFILE ACCESS(CONTROL) CLASS(OPERCMDS)
ID(IZUSVR)

RDEFINE OPERCMDS (MVS.DISPLAY.*) UACC(NONE)

PERMIT MVS.DISPLAY.* CLASS(OPERCMDS) ID(IZUSVR) ACCESS(READ)

RDEFINE SERVAUTH EZB.NETSTAT.<mvsname>.<tcpprocname>.VIPADCFG
UACC(NONE)

PERMIT EZB.NETSTAT.<mvsname>.<tcpprocname>.VIPADCFG
CLASS(SERVAUTH) ID(IZUSVR) ACCESS(READ)

RDEFINE SERVAUTH EZB.NETWORKUTILS.CLOUD.<mvsname> UACC(NONE)

PERMIT EZB.NETWORKUTILS.CLOUD.<mvsname> CLASS(SERVAUTH)
ID(IZUSVR) ACCESS(READ)

Grant ALTER access to IZUSVR for the stack include and stack
dynamic update datasets if your system protects data sets with
SAF profiles. These are data sets you will create manually and
then reference in Configuration Assistant when you configure a
TCP/IP stack from the Systems tab in the Cloud perspective.

If the z/OS ROUTE command is protected by SAF, IZUSVR must have
READ access to the MVS.ROUTE.CMD.<system> SAF profile in the
OPERCMDS class.
**NOTE: <system> is the target MVS system name where
IBM Cloud Provisioning and Management for z/OS will provision
resources. e.g.

PERMIT MVS.ROUTE.CMD.<system> CLASS(OPERCMDS)
ID(IZUSVR) ACCESS(READ)

SETROPTS RACLIST(OPERCMDS,SERVAUTH) REFRESH
).



Regards,
Tom Conley


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Conley
2017-05-18 20:22:05 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
This is a swampy area captured in the caveat 'perform these steps if you choose to use it'. If a shop has not already RDEFINEd MVS.MCSOPER.* with elaborate profile support in place, blandly issuing these commands as documented would immediately bring a shop to its knees. Putting a HOLD(ACTION) label on this bottomless can of worms would only increase the likelihood of operational catastrophe.
If you're inclined to take this action willy-nilly, be sure to update your resume beforehand.
.
.
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
Skip,

I didn't even look at the content of said RACF commands, but you have of
course lurched uncontrollably into the truth, yet again. Well said, sir!

Tom

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pommier, Rex
2017-05-18 20:25:08 UTC
Permalink
Raw Message
I don't know of any sysprog in his/her right mind who would willy-nilly perform any SMP/E action hold without going through the hold actions to see if they are required or need tweaking at a particular shop.

It's no different from the ServerPac jobs that slam a whole slug of security changes in. Whenever I hit one of these jobs, I go through them line by line to see if they apply, if they are already in place, and what I need to change to make them fit the environment.

Personally, I would prefer it be an action hold rather than a doc hold in this case.

Rex

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Thursday, May 18, 2017 3:01 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Mischaracterized HOLDDATA

This is a swampy area captured in the caveat 'perform these steps if you choose to use it'. If a shop has not already RDEFINEd MVS.MCSOPER.* with elaborate profile support in place, blandly issuing these commands as documented would immediately bring a shop to its knees. Putting a HOLD(ACTION) label on this bottomless can of worms would only increase the likelihood of operational catastrophe.

If you're inclined to take this action willy-nilly, be sure to update your resume beforehand.


.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Burrell, Todd
Sent: Thursday, May 18, 2017 12:11 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Mischaracterized HOLDDATA

Well this really should have been labeled as HOLD(ACTION). And I usually look through the DOC for stuff like this, but I've never seen something quite so egregious.

Todd Burrell | Sr. Mainframe Systems Administrator CSX Technologies| 550 Water St. (634I), Jacksonville, FL 32202


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Pinnacle
Sent: Thursday, May 18, 2017 3:07 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Mischaracterized HOLDDATA

For those of you who always laughed when I said read your HOLD(DOC) for buried HOLD(ACTION) items. Here it is kids, so for those of you who still ignore HOLD(DOC), keep telling yourselves that you're saving time and I'm crazy for looking at HOLD(DOC).

++HOLD(UI43841) SYSTEM FMID(HSMA21A) REASON(DOC) DATE(17011)
COMMENT(
Perform the following RACF security steps,
or equivalent steps using your SAF product.
The SAMPLIB sample job, IZUCASEC contains these commented-out
RACF commands and is provided as an aid to perform these steps
if you choose to use it.

RDEFINE OPERCMDS MVS.MCSOPER.* UACC(NONE)

PERMIT MVS.MCSOPER.* CLASS(OPERCMDS) ID(IZUSVR) ACCESS(READ)

RDEFINE OPERCMDS (MVS.VARY.TCPIP.OBEYFILE) UACC(NONE)

PERMIT MVS.VARY.TCPIP.OBEYFILE ACCESS(CONTROL) CLASS(OPERCMDS)
ID(IZUSVR)

RDEFINE OPERCMDS (MVS.DISPLAY.*) UACC(NONE)

PERMIT MVS.DISPLAY.* CLASS(OPERCMDS) ID(IZUSVR) ACCESS(READ)

RDEFINE SERVAUTH EZB.NETSTAT.<mvsname>.<tcpprocname>.VIPADCFG
UACC(NONE)

PERMIT EZB.NETSTAT.<mvsname>.<tcpprocname>.VIPADCFG
CLASS(SERVAUTH) ID(IZUSVR) ACCESS(READ)

RDEFINE SERVAUTH EZB.NETWORKUTILS.CLOUD.<mvsname> UACC(NONE)

PERMIT EZB.NETWORKUTILS.CLOUD.<mvsname> CLASS(SERVAUTH)
ID(IZUSVR) ACCESS(READ)

Grant ALTER access to IZUSVR for the stack include and stack
dynamic update datasets if your system protects data sets with
SAF profiles. These are data sets you will create manually and
then reference in Configuration Assistant when you configure a
TCP/IP stack from the Systems tab in the Cloud perspective.

If the z/OS ROUTE command is protected by SAF, IZUSVR must have
READ access to the MVS.ROUTE.CMD.<system> SAF profile in the
OPERCMDS class.
**NOTE: <system> is the target MVS system name where
IBM Cloud Provisioning and Management for z/OS will provision
resources. e.g.

PERMIT MVS.ROUTE.CMD.<system> CLASS(OPERCMDS)
ID(IZUSVR) ACCESS(READ)

SETROPTS RACLIST(OPERCMDS,SERVAUTH) REFRESH
).



Regards,
Tom Conley


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

The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Conley
2017-05-18 20:44:29 UTC
Permalink
Raw Message
Point of clarity here. When SMP/E added the HOLDDATA report, they added
the ability to exclude any category, and many sysprogs immediately
excluded DOC, thinking they were a waste of time to look at. Whenever I
talked about looking at ALL HOLDDATA, even the DOCs, because sometimes
it's mischaracterized, I was roundly criticized for being too
conservative, nuts, or <unprintable>. I finally found one (and I found
a few more in this same APPLY CHECK I'm working on), so I feel
vindicated. :-P And to my critics, yes, you are #1.

Regards,
Tom Conley

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-05-18 20:33:15 UTC
Permalink
Raw Message
Post by Paul Gilmartin
Can IBM repair this even after the fact? I know SMPHOLD may contain
++HOLD ... ACTION. But I doubt that LIST ERRSYSMODS will show it,
Do you mean LIST HOLDERROR? or perhaps REPORT ERRSYSMODS?
Either way, it will not. Doc and Action holds are System holds, not Error Holds.
You could use LIST HOLDSYSTEM.
Post by Paul Gilmartin
so it does little to alert the programmer who relies on ERRSYSMODS
after APPLY and before deployment.
Relying on ERROR holds to know about SYSTEM holds would be a foolish
thing to do.
Especially if you mean an ERRSYSMODS Report. That only reports on
unresolved error holds.
Post by Paul Gilmartin
I could envision a ++HOLD ... ERROR resolved by a trivial PTF with
the corrected ++HOLD ... ACTION. Ugh.
Sure, the PTF with an incorrect SYSTEM hold could have an ERROR hold
and a resolving PTF with an updated SYSTEM hold. That could be an
appropriate thing to do.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-05-18 20:36:18 UTC
Permalink
Raw Message
Whether ACTION or DOC, these instructions need to be qualified many times over. IBM occasionally PEs a PTF over some problem with HOLD data--usually when it's missing. There may be nothing wrong with the code, just the packaging and accompanying--or not--documentation.

I'm obviously perturbed in this case because we're trying to simply the platform for a new generation. In particular, that's one of the main goals of z/OSMF, for which this sysmod was created. Like tossing a grenade to a kid with the directive to pull the pin or not--as you choose.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tom Marchant
Sent: Thursday, May 18, 2017 1:34 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Mischaracterized HOLDDATA
Post by Paul Gilmartin
Can IBM repair this even after the fact? I know SMPHOLD may contain
++HOLD ... ACTION. But I doubt that LIST ERRSYSMODS will show it,
Do you mean LIST HOLDERROR? or perhaps REPORT ERRSYSMODS?
Either way, it will not. Doc and Action holds are System holds, not Error Holds.
You could use LIST HOLDSYSTEM.
Post by Paul Gilmartin
so it does little to alert the programmer who relies on ERRSYSMODS
after APPLY and before deployment.
Relying on ERROR holds to know about SYSTEM holds would be a foolish thing to do.
Especially if you mean an ERRSYSMODS Report. That only reports on unresolved error holds.
Post by Paul Gilmartin
I could envision a ++HOLD ... ERROR resolved by a trivial PTF with
the corrected ++HOLD ... ACTION. Ugh.
Sure, the PTF with an incorrect SYSTEM hold could have an ERROR hold
and a resolving PTF with an updated SYSTEM hold. That could be an
appropriate thing to do.
--
Tom Marchant


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2017-05-19 12:55:41 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
Whether ACTION or DOC, these instructions need to be qualified many times over. IBM occasionally PEs a PTF over some problem with HOLD data--usually when it's missing. There may be nothing wrong with the code, just the packaging and accompanying--or not--documentation.
I'm obviously perturbed in this case because we're trying to simply the platform for a new generation. In particular, that's one of the main goals of z/OSMF, for which this sysmod was created. Like tossing a grenade to a kid with the directive to pull the pin or not--as you choose.
<snip>

I brought this one to the developer's attention yesterday. The current
thought is that we will PE it and SUP it with a PTF that correctly
specifies REASON(ACTION).

Guys, when you find stuff like this...please open a PMR!
--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-05-18 20:36:44 UTC
Permalink
Raw Message
Post by Pommier, Rex
I would prefer it be an action hold rather than a doc hold in this case.
It isn't either/or. Sometimes it is appropriate to have both a DOC and an ACTION hold.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pommier, Rex
2017-05-18 20:38:56 UTC
Permalink
Raw Message
Agreed, a better wording for me would have been "I would prefer it included an action hold rather than JUST a doc hold in this case."

Rex

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tom Marchant
Sent: Thursday, May 18, 2017 3:38 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Mischaracterized HOLDDATA
Post by Pommier, Rex
I would prefer it be an action hold rather than a doc hold in this case.
It isn't either/or. Sometimes it is appropriate to have both a DOC and an ACTION hold.

--
Tom Marchant

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


The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-05-19 15:01:44 UTC
Permalink
Raw Message
I agree that this forum is no substitute for the SR process, but I for one am not sure how to handle it. As written, the procedure for activating the function provided by this APAR is potentially deadly. The user should absolutely not be advised to RDEFINE command control. If and only if command control is already in place, then the including the new function within the scope is both appropriate and benign.

So yes, it should be a HOLD(ACTION), but the entire procedure should be reworded to indicate that this is an addition to an already existing framework, not Step 1 down a primrose path.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John Eells
Sent: Friday, May 19, 2017 5:57 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Mischaracterized HOLDDATA
Post by Jesse 1 Robinson
Whether ACTION or DOC, these instructions need to be qualified many times over. IBM occasionally PEs a PTF over some problem with HOLD data--usually when it's missing. There may be nothing wrong with the code, just the packaging and accompanying--or not--documentation.
I'm obviously perturbed in this case because we're trying to simply the platform for a new generation. In particular, that's one of the main goals of z/OSMF, for which this sysmod was created. Like tossing a grenade to a kid with the directive to pull the pin or not--as you choose.
<snip>

I brought this one to the developer's attention yesterday. The current thought is that we will PE it and SUP it with a PTF that correctly specifies REASON(ACTION).

Guys, when you find stuff like this...please open a PMR!

--
John Eells
IBM Poughkeepsie
***@us.ibm.com


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Nims,Alva John , Al
2017-05-19 16:27:45 UTC
Permalink
Raw Message
I just received a notification of a couple fixes for this problem.


My Notifications for Software - 19 May 2017

Dear Subscriber (***@ufl.edu),

Here are your daily updates from IBM My Notifications.

Your support Notifications display in English by default. Machine translation based on your IBM profile
language setting is added if you specify this option in My defaults within My Notifications.
(Note: Not all languages are available at this time, and the English version always takes precedence
over the machine translated version.)

------------------------------------------------------------------------------
1. z/OS Communications Server: Troubleshooting

- TITLE: PI81866: ++HOLD DATA FOR APAR PI70767 WAS MIS-CHARACTERIZED AS ++HOLD DOCINSTEAD OF ++HOLD ACTION.
- URL: http://www.ibm.com/support/docview.wss?uid=isg1PI81866&myns=swgother&mynp=OCSSSN3L&mync=E&cm_sp=swgother-_-OCSSSN3L-_-E
- ABSTRACT: ++HOLD data for APAR PI70767 was mis-characterized as ++HOLD REASON(DOC) instead of ++HOLD REASON(ACTION).

- TITLE: PI81862: ++HOLD DATA FOR APAR PI72532 WAS MIS-CHARACTERIZED AS ++HOLD DOCINSTEAD OF ++HOLD ACTION.
- URL: http://www.ibm.com/support/docview.wss?uid=isg1PI81862&myns=swgother&mynp=OCSSSN3L&mync=E&cm_sp=swgother-_-OCSSSN3L-_-E
- ABSTRACT: ++HOLD data for APAR PI72532 was mis-characterized as ++HOLD REASON(DOC) instead of ++HOLD REASON(ACTION).

------------------------------------------------------------------------------
Manage your My Notifications subscriptions, or send questions and comments.
- Subscribe or Unsubscribe - https://www.ibm.com/support/mynotifications
- Feedback - https://www-01.ibm.com/support/feedback/techFeedbackCardContentMyNotifications.html

To ensure proper delivery please add ***@stg.events.ihost.com to your address book.
You received this email because you are subscribed to IBM My Notifications as:
***@ufl.edu

Please do not reply to this message as it is generated by an automated service machine.

(C) International Business Machines Corporation 2017. All rights reserved.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Pinnacle
Sent: Thursday, May 18, 2017 3:07 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Mischaracterized HOLDDATA

For those of you who always laughed when I said read your HOLD(DOC) for buried HOLD(ACTION) items. Here it is kids, so for those of you who still ignore HOLD(DOC), keep telling yourselves that you're saving time and I'm crazy for looking at HOLD(DOC).

++HOLD(UI43841) SYSTEM FMID(HSMA21A) REASON(DOC) DATE(17011)
COMMENT(
Perform the following RACF security steps,
or equivalent steps using your SAF product.
The SAMPLIB sample job, IZUCASEC contains these commented-out
RACF commands and is provided as an aid to perform these steps
if you choose to use it.

RDEFINE OPERCMDS MVS.MCSOPER.* UACC(NONE)

PERMIT MVS.MCSOPER.* CLASS(OPERCMDS) ID(IZUSVR) ACCESS(READ)

RDEFINE OPERCMDS (MVS.VARY.TCPIP.OBEYFILE) UACC(NONE)

PERMIT MVS.VARY.TCPIP.OBEYFILE ACCESS(CONTROL) CLASS(OPERCMDS)
ID(IZUSVR)

RDEFINE OPERCMDS (MVS.DISPLAY.*) UACC(NONE)

PERMIT MVS.DISPLAY.* CLASS(OPERCMDS) ID(IZUSVR) ACCESS(READ)

RDEFINE SERVAUTH EZB.NETSTAT.<mvsname>.<tcpprocname>.VIPADCFG
UACC(NONE)

PERMIT EZB.NETSTAT.<mvsname>.<tcpprocname>.VIPADCFG
CLASS(SERVAUTH) ID(IZUSVR) ACCESS(READ)

RDEFINE SERVAUTH EZB.NETWORKUTILS.CLOUD.<mvsname> UACC(NONE)

PERMIT EZB.NETWORKUTILS.CLOUD.<mvsname> CLASS(SERVAUTH)
ID(IZUSVR) ACCESS(READ)

Grant ALTER access to IZUSVR for the stack include and stack
dynamic update datasets if your system protects data sets with
SAF profiles. These are data sets you will create manually and
then reference in Configuration Assistant when you configure a
TCP/IP stack from the Systems tab in the Cloud perspective.

If the z/OS ROUTE command is protected by SAF, IZUSVR must have
READ access to the MVS.ROUTE.CMD.<system> SAF profile in the
OPERCMDS class.
**NOTE: <system> is the target MVS system name where
IBM Cloud Provisioning and Management for z/OS will provision
resources. e.g.

PERMIT MVS.ROUTE.CMD.<system> CLASS(OPERCMDS)
ID(IZUSVR) ACCESS(READ)

SETROPTS RACLIST(OPERCMDS,SERVAUTH) REFRESH
).



Regards,
Tom Conley

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

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