(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 Thu, 20 Aug 2009 13:13:28 -0400, Joel Wolpert
wrote:
>Sorry for the ignorance. What is an ELA (enterprise licensing agreement?)?
Yes, that's it.
>Why would this cause you to dismantle your sysplex?
Not me, personally, but as a technician, sometimes I'm just a tourist. I'm
sure
the reaso
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 Fri, 14 Aug 2009 00:35:55 -0500, Barbara Nitz wrote:
>
>Good thing we never defined the OMVS CDS!
Got that right. Until we fully deploy 1.10, planned D/R is a pain (NEWROOT
will
alleviate the need for sysplex-wide IPLs). Until 1.11 is available (or we try
to
press for an SPE), we are exp
Newsgroups: bit.listserv.ibm-main
To:
Sent: Thursday, August 20, 2009 1:08 PM
Subject: Re: how-to Sysplex?
Sysplex may have been conceived as a way for applications and systems
to "grow beyond a box", but like it or not, it has evolved into a means to
merge independent systems together. Underst
Sysplex may have been conceived as a way for applications and systems
to "grow beyond a box", but like it or not, it has evolved into a means to
merge independent systems together. Understanding the technical limitations
(we're closer to that now), each shop can decide how far to exploit it. T
Thanks for the input. I did not install MIM. My colleague, who did,
said this was a feature of the MIMPLEX.
I will refer him to your postings when he returns from vacation.
--
For IBM-MAIN subscribe / signoff / archive access in
On Tue, 18 Aug 2009 09:00:20 +0200, Vernooij, CP - SPLXM
wrote:
>
>>
>> >>Have you ever read my doc? We have had a MIMplex here since ??
>(longer
>> than I have worked or consulted here - which was 1998). I set up same
>> userid across systems back then.
>
>
>> >
>> >I did it in a MIMPLEX, as w
>
> >>Have you ever read my doc? We have had a MIMplex here since ??
(longer
> than I have worked or consulted here - which was 1998). I set up same
> userid across systems back then.
> >
> >I did it in a MIMPLEX, as well.
> >Ever since MVS (OS/390 2.7?) supported it.
>
> I was been doing if
On Mon, 17 Aug 2009 16:54:45 +, Ted MacNEIL wrote:
>>Have you ever read my doc? We have had a MIMplex here since ?? (longer
than I have worked or consulted here - which was 1998). I set up same
userid across systems back then.
>
>I did it in a MIMPLEX, as well.
>Ever since MVS (OS/390 2.7?)
>Have you ever read my doc? We have had a MIMplex here since ?? (longer than I
>have worked or consulted here - which was 1998). I set up same userid across
>systems back then.
I did it in a MIMPLEX, as well.
Ever since MVS (OS/390 2.7?) supported it.
That was when I wrote my first REXX exec t
IIRC, it's just that the SYSIKJUA ENQ has to be stopped from going cross system.
>>> Ted MacNEIL 8/17/2009 12:37 PM >>>
>While z/OS & JES2 will allow multiple sessions with the same User ID,
>MIMPLEXex do not.
The first place I used multiple sessions with the same TSO ID was in a MIMPLEX
shop
>While z/OS & JES2 will allow multiple sessions with the same User ID,
>MIMPLEXex do not.
The first place I used multiple sessions with the same TSO ID was in a MIMPLEX
shop.
I didn't do the setup, so I don't know how it was done.
-
Too busy driving to stop for gas!
--
On Mon, 17 Aug 2009 08:55:33 -0700, Mark Yuhas wrote:
>We use MIM and a feature of the 'MIMPLEX' is that MIM disallows multiple
>TSO sessions with the same User ID.
>At this installation, the MIMPLEX crosses all Sysplex boundaries. We
>have 3 monoplexes and 1 base sysplex and the MIMPLEX compris
We use MIM and a feature of the 'MIMPLEX' is that MIM disallows multiple
TSO sessions with the same User ID.
At this installation, the MIMPLEX crosses all Sysplex boundaries. We
have 3 monoplexes and 1 base sysplex and the MIMPLEX comprises all 4
plexes.
While z/OS & JES2 will allow multiple sessi
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
Ted MacNEIL pisze:
Many things CAN be done, but not necessarily were intended by designer.
Are you in contact with the designer(s)?
Or, just a mind-meld?
As I said I talked to IBMers. Sysplex specialists with deep knowledge
and experience. I don't repeat their answers word by word, but the
>Many things CAN be done, but not necessarily were intended by designer.
Are you in contact with the designer(s)?
Or, just a mind-meld?
>As I said, there's nothing wrong in such usage, but it could yield unusual
>issues.
Name one!
>Q1: Why did you merge the systems? What was a goal? To have lo
Ted MacNEIL pisze:
[...]
Sysplex was meant as a way for the systems to grow up and to achieve higher
levels of availability.
You are limiting what can be done with a proper exploitation of SYSPLEX.
Many things CAN be done, but not necessarily were intended by designer.
As I said, there's not
>Technical possibilities may not always reflect business needs.
True, but we, as technicians, have a responsibility to meet, or compromise
with, as much of the business need as possible.
>For example, there is no painless and easy way to merge RACF db's and for sure
>it is IRRUT400 is not reco
Ted MacNEIL pisze:
[...]
The proper way is to meet your business needs and implement SYSPLEX,
application merging, in a low risk and properly planned way.
Technical possibilities may not always reflect business needs.
For example, there is no painless and easy way to merge RACF db's and
for s
>sysplex is not a way for connecting (merge)
several independent systems and applications together.
I disagree.
>Sysplex is meant rather to expand single system. So, the proper way is to
>merge the systems before and then create sysplex.
Again, I disagree.
Where I first had implemented Parall
Arthur Gutowski pisze:
[...]
RACF is a sticky wicket. In addition to profile and protection differences,
sysplex communication requires either a shared database, or unique dataset
names. Because we chose not to rename our existing subplex DSNames (too
many ICHRDSNT's to manage), and not to me
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'.
Hi Barbara,
This is what I run after TSO logon and before ISPF is started for real.
The code runs as an ISPF dialog...better if the ISPF LOG is set to 0 pages.
We use 5 character user IDs.
Address TSO
sysclone_name = Strip(Left('M
>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
>And HFS - this was a big pain for us, particularly since we are multi-site.
>1.10
>and 1.11 will make this easier, but for now we are relegated to sysplex-wide
>IPLs for D/R events. And not just sysplex root -
>AUTOMOVE/NOAUTOMOVE/UNMOUNT require attention, and settings will
>depend on your lev
IIRC, when running in Ring mode, each GRS keeps a copy of all ENQs from all
systems in memory, while in Star mode each GRS only keeps ENQs for his own
system, so it seems logical that there would be a point at which Star uses less
memory overall.
Try being an all SAP shop, I am going to be g
On Thu, 13 Aug 2009 10:46:44 -0400, Scott Rowe
wrote:
>Arthur, I snipped most of your text, which I whole-heartedly agree with, but
I have one comment about the "cost" of GRS-Star: I don't know if anyone
has truly studied this, but I have doubts as to whether GRS Star has a CPU
cost, at leas
On Wed, 12 Aug 2009 01:02:32 -0500, Barbara Nitz
wrote:
>It depends. There are components that you cannot separate/configure for a
>subset. One of them is DAE, for instance. (Has caused us *a lot* of grief.)
>Another is console. A third is GRS. And WLM. And RMF. And PDSE.
And HFS - this was a b
Arthur, I snipped most of your text, which I whole-heartedly agree with, but I
have one comment about the "cost" of GRS-Star: I don't know if anyone has
truly studied this, but I have doubts as to whether GRS Star has a CPU cost, at
least in an environment with relatively low ENQ activity. I h
With others making judicious mention of GRS RNLs, I realized I omitted another
important reference: "z/OS MVS Planning: Global Resource Serialization",
SA22-7600, as well as sections in the various components' (HSM, RACF,
etc.) "sysprog" or "reference" manuals that speak to GRS requirements.
>
On Wed, 12 Aug 2009 17:49:46 -0600, Frank Swarbrick
wrote:
>Does the ISPF PROFILE_SHARING feature address this issue?
>
No. It addresses profile sharing issue. :-)
The issues related to profile sharing (or not) without the new feature
are covered in my doc. Please read it and then ask your
>>> >If you use the same userid on all systems, your users are going to
>>complain as there can be only one userid with the same name in the
>>sysplex,
>
>Huh? I've been using the same userid on multiple systems in a sysplex
>since sysplex was invented.
Then your setup was quite clearly different
Thank you! As the original poster, I got a bit confused with Allan's
recommendation, as I could have sworn others were recommending one Sysplex
owning both PROD and TEST/DEV. Thought maybe I had misinterpreted everything
and had to start over! :-)
--
Frank Swarbrick
Applications Architect -
Does the ISPF PROFILE_SHARING feature address this issue?
On 8/12/2009 at 3:00 AM, in message
<3310ac9d797ec94db8d89ccabdea47a7010a0...@kl1221tc.cs.ad.klmcorp.net>,
"Vernooij, CP - SPLXM" wrote:
> "Ted MacNEIL" wrote in message
> news:1940869721-1250064774-cardhu_decombobulator_blackberry.rim.n
>>> On 8/12/2009 at 12:02 AM, in message
, Barbara Nitz
wrote:
> You will need to define GRS RNLs. You will need to combine your separate WLM
> policies. If you use the same userid on all systems, your users are going to
> complain as there can be only one userid with the same name in the sysple
On Tue, 11 Aug 2009 14:34:17 -1000, Stephen Y Odo
wrote:
>We have 3 LPARs configured as monoplex. One for our Production
>environment, one for our Test/QA environment, and one for our
>Application Development environment.
>
>From this discussion, it sounds like everybody is saying even we would
>Just allocate it in the logon clist with &SYSNAME.
That's what my EXEC did.
But, it also created a new one for a system that you had not signed onto
before, by copying your original ISPPROF dataset.
I last updated the EXEC for a 1.4 system, when profile sharing was not
supported.
It's nice t
I am curious why you would need to take an outage to "harden any dynamic
changes to the IODF"?
It was IODF and microcode. I am limited to a single CEC (a Z/9).
Eventually, dynamic IODF changes will fail when the allocated HSA fills
up. Either that, or an LPAR won't activate because the HSA has
e
Well then, you don't agree with me!
There are many smaller shops which share DASD across PROD/DEV/TEST, and a
Sysplex can be a very appropriate configuration for them.
>>> "Staller, Allan" 8/12/2009 10:01 AM >>>
I agree. 1 sysplex for all is not a good design point for the O/P. I
believe he co
Allan,
I am curious why you would need to take an outage to "harden any dynamic
changes to the IODF"?
Scott
>>> "Staller, Allan" 8/12/2009 8:54 AM >>>
The purpose of a sysplex is z/OS availability. I commonly go 3 months
between outages (production IPL's) and I am in the middle of creating 2
I agree. 1 sysplex for all is not a good design point for the O/P. I
believe he could still benefit from a 2 sysplex design in the same box.
1 for Prod, and 1 for DEV/TEST/QA. Two LPARs for each.
The OP was asking about using Sysplex to join his three monoplexes into
a single Sysplex. Availabili
Allan,
The OP was asking about using Sysplex to join his three monoplexes into a
single Sysplex. Availability may have been the original purpose of Sysplex,
but it can and has been used for other purposes since it's inception. You have
obviously not been following the recent discussion that
Barbara wrote:
>> >If you use the same userid on all systems, your users are going to
>complain as there can be only one userid with the same name in the
>sysplex,
Huh? I've been using the same userid on multiple systems in a sysplex
since sysplex was invented.
>Mark Zeldens instructions in how
Afterword:
And what about the non-IBM components? We run ADABAS/Natural from
Software Ag.
Most major software vendors have had to coexist in or with a SYSPLEX
environment for at least 10 years. I would expect them to be able to
cope!
Check with the vendor for specific information.
HTH,
-
We have 3 LPARs configured as monoplex. One for our Production
environment, one for our Test/QA environment, and one for our
Application Development environment.
>From this discussion, it sounds like everybody is saying even we would
benefit from Sysplex.
The purpose of a sysplex is z/OS avail
>> Yes, there is a tendency to drift; so what?
>
>The downside of that is that the ISPPROF datasets will have different contents.
That's what I meant by 'drift'.
And, I still say: "So what"?
-
Too busy driving to stop for gas!
"Ted MacNEIL" wrote in message
news:1940869721-1250064774-cardhu_decombobulator_blackberry.rim.net-1268
4658...@bxe1287.bisx.prod.on.blackberry...
> >If you use the same userid on all systems, your users are going to
complain as there can be only one userid with the same name in the
sysplex, Mark
>If you use the same userid on all systems, your users are going to complain as
>there can be only one userid with the same name in the sysplex, Mark Zeldens
>instructions in how-to-overcome that not withstanding.
I've used the same ID on multiple systems for years. I even wrote a REXX EXEC
to
>If we did do Sysplex, would we still be able to maintain that separation
>between the environments? How? Does anybody have a "cookbook" on how
>to go from where we are to where we should be? And how does the change
>affect the way we do things? i.e. what do we need to warn our customers
>about?
We have 3 LPARs configured as monoplex. One for our Production
environment, one for our Test/QA environment, and one for our
Application Development environment.
>From this discussion, it sounds like everybody is saying even we would
benefit from Sysplex.
If we did do Sysplex, would we still be
73 matches
Mail list logo
