[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: Leaving Sysplex Communication
From:       "BUCKLEY Pete (AXA-TECH-UK)" <Pete.Buckley () AXA-TECH ! COM>
Date:       2013-11-25 10:57:16
Message-ID: CF7110B124213148824E02C661E7245EAD2620068A () WSIEMB10 ! axa-uk ! intraxa
[Download RAW message or body]

Thanks for sharing that Skip.
I have run with a similar configuration in the past..

As stated, one of the RACF databases in the new sysplex will be set up for \
sysplex/data-sharing. Unfortunately it won't be the one I'm looking after. It's a \
shame that we can't set up multiple RACFPlexes (Plices?) like you can with CICS.

We are avoiding unnecessary GRS contention by renaming any conflicting dataset hlqs. \
Fortunately, there have not been too many conflicts. In your circumstance, I think \
that CA MIM might help - But that would not be cheap.

Pete BUCKLEY
 Put wood in th'ole and save some coal


-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of Skip \
                Robinson
Sent: 22 November 2013 23:10
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: Leaving Sysplex Communication

A few years ago we were induced to bolt two separate parallel sysplexes
together for similar reasons. This 'bronze-plex' previously had only one
member in one sysplex and two in the other. We were concerned about
muddying the RACF waters because the two sysplexes handled security
differently, one more stringently than the other.

The solution was to share one RACF data base between the two equivalent
systems but let the third system keep his own RACF data base to himself.
The two RACF-sharing systems get the advantage of sysplex update
propagation, while the third system has no need to propagate updates. This
configuration may seem odd, but it has worked fine, except that most DASD
is not physically shared. This causes a certain amount of false GRS
contention when data set A.B.C appears to be use on both systems just
because names are the same for physically different data sets. Even I
grouse about this now and again, but all in all it's worth the cost
savings.

We have no special software to facilitate the bronze-plex. It's all
standard issue ServerPac components.

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
JO.Skip.Robinson@sce.com



From:   "BUCKLEY Pete (AXA-TECH-UK)" <Pete.Buckley@AXA-TECH.COM>
To:     RACF-L@LISTSERV.UGA.EDU,
Date:   11/20/2013 12:54 AM
Subject:        Re: Leaving Sysplex Communication
Sent by:        RACF Discussion List <RACF-L@LISTSERV.UGA.EDU>



Thanks Lennie.

With my security hat on, I agree. Unfortunately, my security hat does not
wear the trousers.
The pressure to form a single sysplex comes from the pricing policies of a
major international software and hardware vendor, with whom you may be
familiar. I can't do anything to stop this happening, so I'm concentrating
on steps to mitigate it (Which could form the basis of an entirely
different discussion).

With my sysprog hat on, I could have been clearer with the postscript to
my original post. One of the RACF databases in the sysplex will continue
to operate in sysplex mode. But it won't be the one I control. So no
solution here.

With my solution design hat on, I could probably write something from
scratch. However I thought I'd see if anyone else had been through this
loop before, or had any useful info.

With my potential-sales-target hat on, I can tell you we already have
zSecure Admin. We don't currently have CKNSERVE configured. However if
it's capable of taking a command issued by zSecure on one lpar, and
automatically propagating it to another lpar *with the same security
database*, then this could be the solution for me.
I'll investigate further...

Pete Buckley

"If you didn't like the answer, you shouldn't have asked the question."
-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
Lennie J Dymoke-Bradshaw
Sent: 19 November 2013 17:55
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: Leaving Sysplex Communication

If I put my security hat on, I would not recommend having a sysplex with
multiple security systems within it. There are security issues with the
sharing of devices which can be accessed by multiple systems under
potentially different security rules. One wonders why there is pressure to
consolidate into a single sysplex, when clearly these are distinct systems
with different requirements. My normal rule of thumb for sysplexes is that
the LPARs within them should have like availability requirements, and like
security requirements.

If I put my sysprog hat on, I have to point out that you can continue to
share those systems in the sysplex, as long as there are no other systems
sharing another RACF database using sysplex capabilities.

If I put my solution design hat on, I would say that you could probably
develop a solution using a started task running on each system which has
the capability of running the commands for you, and then using some
communications method (TCP/IP?) to signal the command to be run on the
(other) system.

Putting my pre-sales hat on, you can get solutions for this on the market.
 IBM Security zSecure Admin has a multisystem capability to issue commands
on remote systems. This would probably meet your need. You may find other
such solutions as well.

My security hat is my most important one.

Lennie Dymoke-Bradshaw MBCS CITP
Accredited Senior I/T Specialist, System z, Security and Cryptography, IBM
Software Group
Mail:    Lennie J Dymoke-Bradshaw/UK/IBM@IBMGB  or
Lennie_Bradshaw@uk.ibm.com
There are two types of people in the world; those who have been hacked,
and those who will be hacked.




From:   Pete Buckley <pete.buckley@AXA-TECH.COM>
To:     RACF-L@listserv.uga.edu,
Date:   19/11/2013 16:38
Subject:        Leaving Sysplex Communication
Sent by:        RACF Discussion List <RACF-L@listserv.uga.edu>



Hello Listers,

Currently, we have a set-up where two lpars share a RACF database, and
Sysplex communication and Data-Sharing are enabled.

Next year, we will be moving into a larger sysplex, shared with lots of
other lpars and RACF databases. So we'll have to disable Sysplex
Communication.*

My issue is: I would like to still be able to automatically propagate e.g.
SETROPTS REFRESH from one lpar to another. I know I can simply route it as
an operator command to both lpars. The problem is with Security
Administrators, who only REFRESH when zSecure automatically issues one for
them.

I assume that RRSF would be no use, since both lpars would be part of the
same RRSF node?

Any advice would be greatly appreciated.

Cheers,

Pete Buckley

"If you didn't like the answer, you shouldn't have asked the question."

* I realise it's still possible for one database to have Sysplex
communication enabled - But it won't be ours.



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

This email originates from AXA Technology Services UK Limited (reg.
no. 1854856) which has its registered office at 5 Old Broad Street,
London EC2N 1AD, England.

This message and any files transmitted with it are confidential and
intended solely for the individual or entity to whom they are addressed.
If you have received this in error, you should not disseminate or copy
this email.  Please notify the sender immediately and delete this email
from your system.

Please also note that any opinions presented in this email are solely
those of the author and do not necessarily represent those of The AXA
UK Plc Group.

Email transmission cannot be guaranteed to be secure, or error free as
information could be intercepted, corrupted, lost, destroyed, late in
arriving or incomplete as a result of the transmission process.  The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of email
transmission.

Finally, the recipient should check this email and any attachments for
viruses.  The AXA UK Plc Group accept no liability for any damage
caused by any virus transmitted by this email.


[prev in list] [next in list] [prev in thread] [next in thread]