(Friday question about priceplex)
It happens that independent systems/apllications are sysplexed
(connected together) just to get savings from licenses etc.
Q: why not to put all the systems on one large CPC?
From licensing point of view it can be as effective as parallel sysplex.
From RAS poi
On Tue, 2009-08-25 at 01:28 -0500, Chris Craddock wrote:
> ...
> So I'll throw the question to the assembled throng; should IBM abandon
> sysplex as the centerpiece of their growth/automation/availability strategy
> for z/OS workloads, or should they remove the barriers (real and imagined)
> to ge
On Tue, 25 Aug 2009 00:38:48 -0500, Barbara Nitz
wrote:
>Don,
>[...]
>>OFFLOAD_SYSTEMS(
>> [INCLUDE(sysname1 [,sysname2]...)]
>> [EXCLUDE(sysname1 [,sysname2]...)]
>>)
>
>This was written so nicely :-), I went and checked the books if it's a function
>in 1.11. Pity it isn't. I like the
- Original Message
From: Barbara Nitz nitz-...@gmx.net
> Isn't this a very human trait: Don't change the way I have always done this,
> I
> am used to it, I am getting older and it is harder to learn new things?
Indeed is human. But this way of thinking can literally kill a company.
Chris,
>it doesn't really alter the point I was making
>that sysplex design is predicated on sharing resources everywhere. That
>design philosophy is what removes single points of failure and enables the
>sysplex' marquee features of high availability and in theory, horizontal
>scaling. It is equ
On Tue, Aug 25, 2009 at 12:38 AM, Barbara Nitz wrote:
> >The inconvenient truth of all things sysplex is that sysplex is a "shared
> >everything" architecture which means for it to work correctly, everything
> >must be available everywhere in the plex. Subdividing the plex with old
> >fashioned i
Don,
>You could request new DEFINE/UPDATE LOGSTREAM options to control which
>systems are permitted to perform offloads. Perhaps something along the lines
>of:
>
>OFFLOAD_SYSTEMS(
> [INCLUDE(sysname1 [,sysname2]...)]
> [EXCLUDE(sysname1 [,sysname2]...)]
>)
This was written so nicely
>> The inconvenient truth of all things sysplex is that sysplex is a "shared
>> everything" architecture which means for it to work correctly, everything
>> must be available everywhere in the plex.
While I respect CC, greatly, I disagree with "must".
>>Subdividing the plex with old fashioned ide
>>> On 8/24/2009 at 10:10 AM, in message
, Chris Craddock
wrote:
>>
>>
>>
> The inconvenient truth of all things sysplex is that sysplex is a "shared
> everything" architecture which means for it to work correctly, everything
> must be available everywhere in the plex. Subdividing the plex with o
t: Re: how-to Sysplex? - the LOGR and exploiters part
>
>
>
The inconvenient truth of all things sysplex is that sysplex is a "shared
everything" architecture which means for it to work correctly, everything
must be available everywhere in the plex. Subdividing the plex with old
fa
>
>
>
The inconvenient truth of all things sysplex is that sysplex is a "shared
everything" architecture which means for it to work correctly, everything
must be available everywhere in the plex. Subdividing the plex with old
fashioned ideas like "Prod runs on SYSA, development runs on SYSB and the
-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Barbara Nitz
Sent: Monday, August 24, 2009 2:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: how-to Sysplex? - the LOGR and exploiters part
>Barbara, we don't data share with DB2, so we don't see the probl
>The problem in itself is NOT DB2 data sharing, it is the fact that DB2 uses
>RRS for some administrative tasks unequivocally. I am NOT a DB2 person. From
>what I understand, in order to see some of the current DB2 definitions, you
need RRS to be active.
It uses RRS for DDF, for sure.
I was inv
>Barbara, we don't data share with DB2, so we don't see the problems with
RRS
>offloads. Does the introduction of the data sharing in a subplex force you to
>share structures for the logstreams, even though they are sub-plexed?
The problem in itself is NOT DB2 data sharing, it is the fact that D
Tom Marchant wrote:
On Fri, 21 Aug 2009 14:10:45 -0700, Edward Jaffe wrote:
... (E)JES implements a feature called "Syslog auto cmd routing".
With this enabled, commands not explicitly routed are automatically
routed to the system whose SYSLOG you are browsing.
Wow. Cool feature!
On Fri, 21 Aug 2009 14:10:45 -0700, Edward Jaffe wrote:
>... (E)JES implements a feature called "Syslog auto cmd routing".
>With this enabled, commands not explicitly routed are automatically
>routed to the system whose SYSLOG you are browsing.
Wow. Cool feature!
--
Tom Marchant
-
Mark Zelden wrote:
On Fri, 21 Aug 2009 12:02:49 -0700, Edward Jaffe
wrote:
FWIW, I submitted a SHARE requirement years ago to allow multiple
OPERLOG log streams in a sysplex. The intent was that each system could
substitute its XCF group name into the log stream name. Then you could
have an
On Fri, 21 Aug 2009 13:45:34 -0500, Mark Zelden
wrote:
>All you have to do is define the volumes / pools (storage group) in the
>different SMSplexes that you want to share and then have consistent ACS
>routines. It's that simple.
>
To clarify that statement, I meant "consistent" only for those
On Fri, 21 Aug 2009 12:02:49 -0700, Edward Jaffe
wrote:
>FWIW, I submitted a SHARE requirement years ago to allow multiple
>OPERLOG log streams in a sysplex. The intent was that each system could
>substitute its XCF group name into the log stream name. Then you could
>have an OPERLOG for each JE
Barbara Nitz wrote:
We *thought* we were safe on this front. Until we found out that the operlog
logstream gets corrupted on a regular basis because it gets offloaded on the
wrong subsysplex where the offload datasets cannot be found from the 'other
side'. One would have thought (and it came as
On Fri, 21 Aug 2009 13:11:53 -0500, Arthur Gutowski wrote:
>Barbara, we don't data share with DB2, so we don't see the problems with RRS
>offloads. Does the introduction of the data sharing in a subplex force you to
>share structures for the logstreams, even though they are sub-plexed?
>
>As for
Barbara, we don't data share with DB2, so we don't see the problems with RRS
offloads. Does the introduction of the data sharing in a subplex force you to
share structures for the logstreams, even though they are sub-plexed?
As for Operlog, we have the same exposure with EJES (we have a lot of
On Mon, 17 Aug 2009 00:27:52 -0500, Barbara Nitz wrote:
>>But the logger problem (for operlog / logrec) was still
>>easily solved by creating a shared SMS pool (even though there were
>>separate SMSplexes), a shared catalog on one of the logger volumes
>>and a new logger HLQ. The priceplex was b
>But the logger problem (for operlog / logrec) was still
>easily solved by creating a shared SMS pool (even though there were
>separate SMSplexes), a shared catalog on one of the logger volumes
>and a new logger HLQ. The priceplex was born!
Given that in our case it is kinda impossible to create
On Fri, 14 Aug 2009 01:01:43 -0500, Barbara Nitz wrote:
>We *thought* we were safe on this front. Until we found out that the operlog
>logstream gets corrupted on a regular basis because it gets offloaded on the
>wrong subsysplex where the offload datasets cannot be found from the 'other
>side'.
>We had problems with OPERLOG, using a structure, so now we only enable it
>on one subplex that shares DASD. We have the odd problem with EJES users
>on other systems trying to connect to the logstream from images outside the
>duplex. Perhaps we should try moving to DASD-only to resolve it.
>
>We
26 matches
Mail list logo
