Amen.
On Oct 30, 2013 12:00 PM, "John McKown"
wrote:
> IMO, use of UID(0) for a non-BCP component by a vendor or by IBM is simply
> an indication that the software designer is too damn lazy to determine what
> access they really need and simply refuse to spend the effort (and money)
> to determin
Specifics are for MXG users, but the APAR is a general note:
Change 30.268 RACF317='BPX*DEFAULT*USER*USED?' is added to TYPE8028
VMAC80Athru TYPE8065 to identify if the FACILITY class profile
Dec 25, 2012 BPX.DEFAULT.USER is being used; that facility will NOT
exist in z/O
On Wed, 30 Oct 2013 10:59:55 -0500, John McKown
wrote:
>IMO, use of UID(0) for a non-BCP component by a vendor or by IBM is simply
>an indication that the software designer is too damn lazy to determine what
>access they really need and simply refuse to spend the effort (and money)
>to determine
On Wed, 30 Oct 2013 16:57:31 +0100, R.S. wrote:
>Well, AIM3 (and AIM at all) was introduced in OS/390 2.10 AFAIR, approx
>13 years ago.
>It's much more time, than BPX.UNIQUE.USER - it was new feature in z/OS
>1.11 and have-to-be-done in 1.13. Big difference.
Yes, I recall trying to get my cli
IMO, use of UID(0) for a non-BCP component by a vendor or by IBM is simply
an indication that the software designer is too damn lazy to determine what
access they really need and simply refuse to spend the effort (and money)
to determine which of the UNIXPRIV authorities might actually let them do
W dniu 2013-10-30 16:27, Mark Zelden pisze:
Usually customers have more time to migrate off fading solution/technique.
Not to mention ISAM or IMBED...
It's a bit more complicated than just migrating to BPX.UNIQUE.USER. You have to
be at AIM (Application identity Mapping ) stage 3 for RACF. H
>Usually customers have more time to migrate off fading solution/technique.
>Not to mention ISAM or IMBED...
It's a bit more complicated than just migrating to BPX.UNIQUE.USER. You have to
be at AIM (Application identity Mapping ) stage 3 for RACF. However, you can't
convert to AIM 3 if you ha
/racf-l.html
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: Wednesday, October 30, 2013 5:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FACILITY Class profile BPX.DEFAU
W dniu 2013-10-30 13:35, Elardus Engelbrecht pisze:
[...]
This was mentioned since z/OS 1.11 (if I remember correctly) and that
z/OS v1.13 would be the last z/OS which support it. In fact,
BPX.UNIQUE.USER was introduced in z/OS v1.11.
Usually customers have more time to migrate off fading solut
, October 30, 2013 5:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FACILITY Class profile BPX.DEFAULT.USER in zOS 2.1
>
> RCG wrote:
>
> >Not sure if this was already discussed / notified... So for the benefit of
> >everyone..
>
> It was discussed here and
RCG wrote:
>Not sure if this was already discussed / notified... So for the benefit of
>everyone..
It was discussed here and also on RACF-L. Check out RACF-L for lots of
discussion of that profile.
>The FACILITY class profile BPX.DEFAULT.USER is not supported in z/OS 2.1.
This was mentioned
Dear group,
Not sure if this was already discussed / notified... So for the benefit of
everyone..
The FACILITY class profile BPX.DEFAULT.USER is not supported in z/OS 2.1.
> BPX.DEFAULT.USER provides users without OMVS segment a 'temporary' OMVS
> segment when USS services are invoked.
>
> So, be
12 matches
Mail list logo
