> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Monday, May 02, 2016 10:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: OA49446 on RSU1603 - RACF / DFSMS change
>
> I have no
Subject: (External):Re: OA49446 on RSU1603 - RACF / DFSMS change
On Fri, 29 Apr 2016 07:15:09 -0400, Robert S. Hansel (RSH)
wrote:
>(Cross-posting to RACF-L)
>
>Mark,
>
>
>If this works as per my interpretation, then I think the concerns
>raised by others are valid. If I can c
On Fri, 29 Apr 2016 07:15:09 -0400, Robert S. Hansel (RSH)
wrote:
>(Cross-posting to RACF-L)
>
>Mark,
>
>
>If this works as per my interpretation, then I think the concerns raised by
>others are
> valid. If I can create an alias with a name to which I have access that
> points to a dataset
> t
On Fri, 29 Apr 2016 07:21:12 -0500, Tom Marchant wrote:
>The old way, which surprises me a little, DEFINE ALIAS required access to the
>data set to which the alias is related, but not to the alias name being
>defined.
Sorry, this part seems to be incorrect. The old way didn't require any access
On Thu, 28 Apr 2016 12:01:17 -0500, Mark Zelden wrote:
>I'm applying z/OS 2.1 RSU1603 and came across this PTF. Is anyone running
>with
>it in production and has it caused you any grief? This seems to change a
>behavior
>that has been around "forever", so it concerns me a bit even though the
-MAY 3-5, 2016
- RACF Level III Admin, Audit, & Compliance - JUN 14-16, 2016
- Securing z/OS UNIX - WebEx - JUL 25-29, 2016
-Original Message-
Date:Thu, 28 Apr 2016 12:01:17 -0500
From:Mark Zelden
Subj
On Thu, 28 Apr 2016 12:22:17 -0500, Paul Gilmartin wrote:
>On Thu, 28 Apr 2016 12:01:17 -0500, Mark Zelden wrote:
>
>>I'm applying z/OS 2.1 RSU1603 and came across this PTF. Is anyone running
>>with
>>it in production and has it caused you any grief? This seems to change a
>>behavior
>>that
On 4/28/2016 1:41 PM, Tom Marchant wrote:
On Thu, 28 Apr 2016 12:28:58 -0500, Mike Schwab wrote:
I would think this would apply to a discrete authorization, without an
ending .**.
I. E. authorize DATA.SET.NAME instead of DATA.SET.NAME.**
Define DS(DATA.SET.NAME) would fail because of no authori
On Thu, 28 Apr 2016 12:28:58 -0500, Mike Schwab wrote:
>I would think this would apply to a discrete authorization, without an
>ending .**.
>I. E. authorize DATA.SET.NAME instead of DATA.SET.NAME.**
>Define DS(DATA.SET.NAME) would fail because of no authorization for
>DATA.SET.NAME.DATA (optional
I would think this would apply to a discrete authorization, without an
ending .**.
I. E. authorize DATA.SET.NAME instead of DATA.SET.NAME.**
Define DS(DATA.SET.NAME) would fail because of no authorization for
DATA.SET.NAME.DATA (optional DATA.SET.NAME.INDEX, DATA.SET.NAME.PATH,
etc) .
On Thu, Apr
On Thu, 28 Apr 2016 12:01:17 -0500, Mark Zelden wrote:
>I'm applying z/OS 2.1 RSU1603 and came across this PTF. Is anyone running
>with
>it in production and has it caused you any grief? This seems to change a
>behavior
>that has been around "forever", so it concerns me a bit even though the
I'm applying z/OS 2.1 RSU1603 and came across this PTF. Is anyone running with
it in production and has it caused you any grief? This seems to change a
behavior
that has been around "forever", so it concerns me a bit even though there
is a work around by defining a special RACF profile in the
12 matches
Mail list logo
