)' and a 'CONSOLE
DEACTIVATE'.
The 'CONSOLE' command is specified in the IKJTSOxx parmlib member.
The modules IKJCNXCI (CONSPROF authority for TSO User) and IKJCNXAC (CONSOLE
authority for TSO User) are in SYS1.LPALIB.
This works flawlessly in a non-SYSPLEX environment.
In a SYSPLEX(GRS) environment
Yep. Got that. My confusion was that it wasn't immediately obvious that once
the system was IPLed it was in Sysplex communications mode.
Mark Jacobs
Sent from ProtonMail, Swiss-based encrypted email.
GPG Public Key -
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
I just went through this. There are 2 "levels" of RACF sharing
SYSPLEX Data Sharing (CF required) and SYSPLEX Communications (no CF required).
SYSPLEX Data Sharing is b'10001100' (x'8C')
SYSPLEX Communication is b'10001000' (x'88').
What you have set up is SYSPLEX Communica
, 2019 6:42 AM, Elardus Engelbrecht
wrote:
> Mark Jacobs wrote:
>
> > Since there's more activity here than in the RACF mailing list, thought I'd
> > ask here first. I changed the flag byte in the RACF dataset names table to
> > enable sysplex communications today, an
Mark Jacobs wrote:
>Since there's more activity here than in the RACF mailing list, thought I'd
>ask here first. I changed the flag byte in the RACF dataset names table to
>enable sysplex communications today, and ipled the first system with the
>changed table. Even though it's
t;><0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
>>
>>> Since there's more activity here than in the RACF mailing list, thought I'd
>>> ask here first. I changed the flag byte in the RACF dataset names table to
>>> enable sysplex communications today, and
l Message ‐‐‐
>On Thursday, May 23, 2019 6:37 PM, Mark Jacobs
><0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Since there's more activity here than in the RACF mailing list, thought I'd
>> ask here first. I changed the flag byte in the RACF dataset names table
Message ‐‐‐
On Thursday, May 23, 2019 6:37 PM, Mark Jacobs
<0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
> Since there's more activity here than in the RACF mailing list, thought I'd
> ask here first. I changed the flag byte in the RACF dataset names table to
>
Since there's more activity here than in the RACF mailing list, thought I'd ask
here first. I changed the flag byte in the RACF dataset names table to enable
sysplex communications today, and ipled the first system with the changed
table. Even though it's not talking to another system yet via
On Fri, 8 Mar 2019 08:16:10 +1300, Laurence Chiu wrote:
>But we have a number of batch jobs that calls CICS transactions in those
>regions and we are wondering what happens if the batch job is running in a
>LPAR where the region isn't.
>
>Will it abend or will MRO work out to send the work to
I think you'll want to ask this question in the CICS list.
https://listserv.uga.edu/cgi-bin/wa?A0=CICS-L
Cheers,
Jantje.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu
Looking at implementing a parallel Sysplex primarily to support CICS
regions that need to be up on more than one LPAR.
But some of the regions are not Sysplex compliant so we'll run them on one
LPAR only.
But we have a number of batch jobs that calls CICS transactions in those
regions and we
> I'm helping a coworker (she supports IBM Comm Server) whose is seeking
> information about companies or information that could be shared to assist
> with
> solution building to provide a Multi-Site Parallel Sysplex implementation
> in our
> infrastructure, utilizing GDPS-PPRC, two s
Cross posting to both IBM-MAIN and IBMTCP-L
I'm helping a coworker (she supports IBM Comm Server) whose is seeking
information about companies or information that could be shared to assist with
solution building to provide a Multi-Site Parallel Sysplex implementation in our
infrastructure
On Wed, 12 Dec 2018 19:33:14 -0500, Matt Hogstrom wrote:
>I’m looking to detect differences across the LPARs in terms of shared storage
>and want to pull together an aggregate view.
I wonder if an API into the active IODF would help.
I don't know if such is available.
--
Tom Marchant
nter/SSLTBW_2.2.0/com.ibm.zos.v2r2.cfzu100/ibmzos_logicaldisk.htm
>
> On Wed, Dec 12, 2018 at 12:41 PM Matt Hogstrom wrote:
>
>> Is there a callable API that returns the list of online volumes to LPARs
>> in a Sysplex? I assume one could route a command and write script
I’m looking to detect differences across the LPARs in terms of shared storage
and want to pull together an aggregate view.
Matt Hogstrom
PGP Key: 0x90ECB270
“Quantity has a quality all its own.”
— Joseph Stalin
> On Dec 12, 2018, at 4:23 PM, Tony Harminc wrote:
>
> running
You may want to try: IBMzOS_LogicalDisk
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.cfzu100/ibmzos_logicaldisk.htm
On Wed, Dec 12, 2018 at 12:41 PM Matt Hogstrom wrote:
> Is there a callable API that returns the list of online volumes to LPARs
> in a Syspl
On Wed, 12 Dec 2018 at 13:41, Matt Hogstrom wrote:
> Is there a callable API that returns the list of online volumes to LPARs
> in a Sysplex? I assume one could route a command and write scripts. I’m
> looking for an API that can be incorporated into a program where all the
&g
On Wed, 12 Dec 2018 13:41:24 -0500, Matt Hogstrom wrote:
>Is there a callable API that returns the list of online volumes to LPARs in a
>Sysplex? I assume one could route a command and write scripts. I’m looking
>for an API that can be incorporated into a program where all the
IDCAMS DCOLECT VOLS(*) will give you the volume data you need.
Other record types can give you the cataloged data sets.
On Wed, Dec 12, 2018 at 12:41 PM Matt Hogstrom wrote:
>
> Is there a callable API that returns the list of online volumes to LPARs in a
> Sysplex? I assume one co
Is there a callable API that returns the list of online volumes to LPARs in a
Sysplex? I assume one could route a command and write scripts. I’m looking
for an API that can be incorporated into a program where all the searching and
cataloging is done.
Matt Hogstrom
m...@hogstrom.org
PGP Key
rything else is shutdown, hence
> research on whether it's feasible to begin a system split prior to
> everything else being shut down.
>
> Mark Jacobs
>
> Elardus Engelbrecht wrote on 8/30/18 2:35 AM:
>
> Mark Jacobs - Listserv wrote:
>
>
>
> We're in a parallel sy
Just dial down the defined capacity of each LPAR as work leaves the mainframe.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
for a while after everything else is shutdown, hence research on
whether it's feasible to begin a system split prior to everything else being
shut down.
Mark Jacobs
Elardus Engelbrecht wrote on 8/30/18 2:35 AM:
Mark Jacobs - Listserv wrote:
We're in a parallel sysplex, sharing most everything
Mark Jacobs - Listserv wrote:
>We're in a parallel sysplex, sharing most everything, and need to begin
>planning activities to remove one system from the sysplex, while continuing to
>use it to run a subset of our current workload.
Why? You lose many benefits of being in a SysPlex, b
My easy guesses
1) Prepping to sell off a business unit
2) separation dev/test from prod or some version of a compliance separation
Not so serious guess
3) manager subscribes to PHB (pointy hair boss) Magazine and thinks that 1
less system will make sysplex lighter
Out there.. maybe
4) some
I don't claim the experience to understand *all* the ramifications, but
Jerry's idea is the first thing that occurred to me.
sas
On 8/29/2018 17:34, Jerry Whitteridge wrote:
I agree with Skip - the risk in pulling apart a Sysplex is high, where to
stand up a new stand-alone system
I agree with Skip - the risk in pulling apart a Sysplex is high, where to
stand up a new stand-alone system will ensure the isolation required. I'd
build a new system and move the work as needed to it.
Jerry Whitteridge
Delivery Manager / Mainframe Architect
GTS - Safeway Account
602 527 4871
The issues listed in the original post plus those suggested by others are
potentially *very* serious. I have to ask what benefits are expected that would
justify the risk. Surely sysplex overhead alone would not be worth damaging a
catalog for example. Whose idea is this?
.
.
J.O.Skip Robinson
On Wed, 29 Aug 2018 13:57:14 -0400, Mark Jacobs - Listserv
wrote:
>We're in a parallel sysplex, sharing most everything, and need to begin
>planning activities to remove one system from the sysplex, while continuing to
>use it to run a subset of our current workload.
>
>Some o
and output?
Change control - application code, duplicates of anything shared, promotion
to multi-environment, data movement between sysplex and non-sysplex
Change control for sysprog and promotion of fixes
Change IPL doc for operations
HTH,
Rob
On Wed, Aug 29, 2018, 2:16 PM Cameron Conacher wrote
if the remaining LPAR
hosting your CICSPLEX CICS regions were to fail you would have no CICS
availability.
You probably already considered this.
Sent from my iPhone
> On Aug 29, 2018, at 1:57 PM, Mark Jacobs - Listserv
> wrote:
>
> We're in a parallel sysplex, sharing most everything, and n
We're in a parallel sysplex, sharing most everything, and need to begin
planning activities to remove one system from the sysplex, while continuing to
use it to run a subset of our current workload.
Some of the things we need to consider are;
* PDS/e Sharing
* Catalogs (we're ECS shared
To avoid misunderstandings: n*z/OS + m*CF = Parallel Syplex, and
n=1...32, m=1...16.
I don't know what "most people" interpret, and without some sociological
survey. My survey told me that no one of my family members, neighbours
or local shop seller do understand parallel sysp
Radoslaw Skorupka wrote:
>RLS require Parallel Sysplex, but not everyone need it.
We should be more precise and careful, to avoid any misunderstandings. VSAM
RLS requires:
* At least one z/OS instance (let's go with exactly one in this example);
* A Coupling Facility (CF)(*), which can e
n have up to 16
CFs in a sysplex, but usually we protect against SINGLE failure, not
coordinated series of failures. That's why we carry only one spare wheel
in a car (typically).
Regards
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2018-07-11 o 11:34, Richards, Robert B. pisze:
Just make s
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of R.S.
Sent: Wednesday, July 11, 2018 5:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sysplex between two hardware
Maybe it's illusory, but that is in David Raften document.
Obviously it's cheaper
W dniu 2018-07-11 o 09:41, Timothy Sipples pisze:
J.O.Skip Robinson wrote:
It's easy to diss a solution as 'budget' when it saves
someone *else* money.
I quite agree.
As it happens, I'm quite fond of the single machine z/OS Parallel Sysplex
configuration that David also describes. I wish more
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of R.S.
Sent: Tuesday, July 10, 2018 3:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Sysplex between two hardware
W dniu 2018-07-10 o 06:56, Timothy Sipples pisze:
I should also respond to this part:
Radoslaw Skorupka wrote
J.O.Skip Robinson wrote:
>It's easy to diss a solution as 'budget' when it saves
>someone *else* money.
I quite agree.
As it happens, I'm quite fond of the single machine z/OS Parallel Sysplex
configuration that David also describes. I wish more installations without
Parallel Sysplex would
] On Behalf
Of R.S.
Sent: Tuesday, July 10, 2018 3:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Sysplex between two hardware
W dniu 2018-07-10 o 06:56, Timothy Sipples pisze:
> I should also respond to this part:
>
> Radoslaw Skorupka wrote:
>> ...for availability reasons o
.
Even when there's some merit in physically separating the CF, the physical
separation need only be between that CF and the particular z/OS Parallel
Sysplex it serves. Having other z/OS LPARs, even LPARs that are
participating in other Parallel Sysplexes, on the same machine as the CF is
consistent
Date: 10/07/2018 09:35
Subject:Re: Sysplex between two hardware
Sent by:IBM Mainframe Discussion List
Martin, thanks I time to time read your blogs very useful however one you
pasted for the deactivated lpar's doesn't have much on the performance
side ...anyway yes we have L
Martin, thanks I time to time read your blogs very useful however one you
pasted for the deactivated lpar's doesn't have much on the performance side
...anyway yes we have LOCK1 duplex...here's an example from our dev partitions.
STRNAME: Dxxx_LOCK1
A common pattern (and I often see the inactive LPARs in RMF* SMF) but tell me:
Do you duplex DB2 LOCK1? And how is that working out performancewise?
* I wrote about how to do this in
https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/lpars_what_s_in_a_name?lang=en
in 2014.
We took an approach where for each plex we had CF defined on two cec's as that
make sense :
1. Systems defined in the plex are defined on both CEC ...i.e. Say we have plex
of 4 systems (SYS1,SYS2,SYS3,SYS4), each with 2 systems on one CEC1(SYS1 & SYS2
Active(Normal running) the rest 2 in
gt; > Sent: 09 July, 2018 18:07
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Sysplex between two hardware
> >
> > I stand by my original reply. All you need is an ICF LPAR in each CEC
> > and physical links to connect the CECs, together with full CF structure
> &
t; Behalf Of Jesse 1 Robinson
> Sent: 09 July, 2018 18:07
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex between two hardware
>
> I stand by my original reply. All you need is an ICF LPAR in each CEC
> and physical links to connect the CECs, together with full CF structure
> d
ically separating the CF, the physical
separation need only be between that CF and the particular z/OS Parallel
Sysplex it serves. Having other z/OS LPARs, even LPARs that are
participating in other Parallel Sysplexes, on the same machine as the CF is
consistent with IBM's recommendations here.
David Raft
-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Monday, July 09, 2018 8:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Sysplex between two hardware
nframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Allan Staller
> Sent: 09 July, 2018 16:33
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex between two hardware
>
> That configuration is perfectly valid. You are merely missing some(but
> not all) redu
Subject: Re: Sysplex between two hardware
W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze:
> The essence of the matter is to ensure that the selected configuration meets
> the availability objectives of the business services supported by the
> sysplex. One must consider the service re
W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze:
The essence of the matter is to ensure that the selected configuration meets the
availability objectives of the business services supported by the sysplex. One must
consider the service restoration objectives for the business services in light
The essence of the matter is to ensure that the selected configuration meets
the availability objectives of the business services supported by the sysplex.
One must consider the service restoration objectives for the business services
in light of the potential failures that can occur
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: 09 July, 2018 14:26
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex between two hardware
>
> W dniu 2018-07-09 o 13:12, Vernooij, K
STP (or earlier sysplex timer) is mandatory for sysplex, even for basic sysplex.
For production parallel sysplex it is good idea to have standalone CF.
Not if entire sysplex is in one box. If that is the case, SYSPLEX time is not
needed.
As long as all participants use the same time source
W dniu 2018-07-09 o 13:12, Vernooij, Kees (ITOPT1) - KLM pisze:
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of R.S.
Sent: 09 July, 2018 12:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sysplex between two hardware
W dniu 2018-07-06 o
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: 09 July, 2018 12:47
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex between two hardware
>
> W dniu 2018-07-06 o 18:22, Jesse 1 Robinso
W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze:
We all have lots of questions about your goals here, but the short answer to
your question is Yes, sysplex is the answer. I assume that your two boxes are
already connected in some way as to share access to data. Turning such a
configuration
We all have lots of questions about your goals here, but the short answer to
your question is Yes, sysplex is the answer. I assume that your two boxes are
already connected in some way as to share access to data. Turning such a
configuration into a sysplex may require some additional hardware
Peter wrote:
>We are looking up for a solution where we need a LPAR to have a hot
standby
>in other LPAR running in a different machine .
>As we are trying to create a sysplex relationship between two LPARS
running
>in a different machines .
>Apology for my ignorance and is it
Peter,
What is your question exactly?
If you MEAN a "hot standby" - which I understand to mean a system that is IPL'd
but not being used, but could take on workload from a currently active and used
system, I'd say that's not a SYSPLEX, that's a disaster recovery scenario.
If you
Hi
We are looking up for a solution where we need a LPAR to have a hot standby
in other LPAR running in a different machine .
As we are trying to create a sysplex relationship between two LPARS running
in a different machines .
Apology for my ignorance and is it possible ?
Peter
-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Sankaranarayanan, Vignesh
Sent: Friday, May 18, 2018 8:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: [EXTERNAL] Re: RACF on a Sysplex
on a Sysplex??
One sort of obvious point. Before cloning your RACF data base make sure that
*all* data set profiles are generic. Convert any that are not.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543
⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mark Zelden
Sent: Thursday, May 03, 2018 3:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF on a Sysplex??
My client has a mixture of things
plexes has separate RACF databases, but RRSF
keeps
things in sync. Both have sysplex communications enabled in the DSNT and CF
structures.
Another business unit has one RACF database shared between 2 sysplexes. MII is
the
integrity manager and SYSZRACF is excluded, so the DB is protected with
non-shared DASD so prod
>has its own databases and test has its own. In a Sysplex should the RACF
>databases still reside on DASD that both sides of the sysplexes share (so both
>prod lpars in the plex) or should they reside in the coupling facility or ??
Wait a moment please. Fir
We have separate DB's for each Sysplex BUT keep them in sync using
RRSAF so password changes and profile updates flow from the initial
system to all the others. In the case of the Sandbox Sysplex we
allow updates IN but not OUT - allowing us to test RACF changes in
the Sandbox Sysplex
I would do the split post sysplex.
Make a copy of production to be used by the test sysplex.
Get to the two sysplex mode.
Then do the cleanup.
Remember, you scope of sharing is SYSPLEX. Do not cross sysplex boundaries. You
will (most likely) be very sorry if you do.
-Original Message
;IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
> fred glenlake
> Sent: Thursday, May 03, 2018 9:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RACF on a Sysplex??
>
> Hello,
>
> We are going from one production lpar and one test lpar to two sysplexs, one
> plex for production,
databases and test has its own. In a Sysplex should the RACF databases still
reside on DASD that both sides of the sysplexes share (so both prod lpars in
the plex) or should they reside in the coupling facility or ??
Are there any tools that will help me get to my end state, split up the
databases
This looks like a problem we had some time ago, although it was part of a much
more complex outage.
The problem was a power failure (Murphy during actions on the power infra) in
one site of the 2 site 9-LPAR sysplex.
Several things like automatic recovery action (sysplex partitioning etc) were
MASDEF DORMANCY=(100,500), HOLD=60, LOCKOUT=1000,SYNCTOL=120. That what I have.
Been like this for 11 month.
Not convinced this is a JES2 problem.
Thanks
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
nothing in the syslog prior to this indicates any issues. All running fine.
Yes we have an automation tool.
Yes, I will place the CKPT1 on the CF.
Thanks
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
g hung in a two
> SYSPLEX LPAR causing sympathy sickness.
>
> In both cases the indication is $HASP263 message (Checkpoint lock), followed
> by *MASTER* pending on the JES2 CKPT volume.
>
> Finally IXC426D to partition the sick LPAR out.
>
> We do not have an SFM policy in
, I've had an issue like this when working for
an outsourcer, we had 16 system in a plex from a 9 engine CP to a UNI processor
in the same plex, and the sysplex designer had an SFM policy built that was not
designed correctly and all systems were weighted the same, the UNI processor
would
within the SYSPLEX/ RMF ENQ report shows nothing that would
indicate an ENQ on JES2 CKPT by some other ASID.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu<mai
SERV.UA.EDU
> Subject: Re: SYSPLEX Hung
>
> Yes. Shared DASD within the SYSPLEX/ RMF ENQ report shows nothing that would
> indicate an ENQ on JES2 CKPT by some other ASID.
>
> --
> For IBM-MAIN subscribe / s
Yes. Shared DASD within the SYSPLEX/ RMF ENQ report shows nothing that would
indicate an ENQ on JES2 CKPT by some other ASID.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists
The OP could also try D GRS,C on the surviving system.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Carmen Vitullo
Sent: Thursday, April 19, 2018 1:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYSPLEX Hung
not sure
not sure if this would help, since I suspect maybe JES2 was a victim, of a
deadly embrace. since you didn't get a chance to take a SADMP the RMF ENQ
report may help diagnose an ENQ, or RESERVE issue.
I'd like to also assume all shared DASD is within the same SYSPLEX?
Carmen Vitullo
OPS didn't.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
In JES MAS, yes. CKPT on DASD. Nothing but ckpt on each DASD.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Vitullo
- Original Message -
From: "Salah Balboul" <balbo...@att.net>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, April 19, 2018 9:48:11 AM
Subject: SYSPLEX Hung
Hi,
For the past week we've had 2 crashes due to one LPAR being hung in a two
SYSPLEX LPAR causing s
: SYSPLEX Hung
Hi,
For the past week we've had 2 crashes due to one LPAR being hung in a two
SYSPLEX LPAR causing sympathy sickness.
In both cases the indication is $HASP263 message (Checkpoint lock), followed by
*MASTER* pending on the JES2 CKPT volume.
Finally IXC426D to partition the sick
Have you taken a SAD of the failed system?
Mark Jacobs
Salah Balboul<mailto:balbo...@att.net>
April 19, 2018 at 10:48 AM
Hi,
For the past week we've had 2 crashes due to one LPAR being hung in a two
SYSPLEX LPAR causing sympathy sickness.
In both cases the indication is $HASP263 m
Hi,
For the past week we've had 2 crashes due to one LPAR being hung in a two
SYSPLEX LPAR causing sympathy sickness.
In both cases the indication is $HASP263 message (Checkpoint lock), followed by
*MASTER* pending on the JES2 CKPT volume.
Finally IXC426D to partition the sick LPAR out.
We
ttps://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
From: Jesse 1 Robinson <jesse1.robin...@sce.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 23/03/2018 16:20
Subject:Re: Sharing across two sysplex
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Scott Fagen
Sent: Tuesday, March 13, 2018 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Sharing across two sysplex
Caught this on the newsgroup, not the LISTSERV:
--
jean.b
Thanks David that makes sense, and that's what I'm leaning towards. I had to
make some concessions with some products, I was forced to create a symlink on
the sysplex root because of how the users accessed some ISV products, so my
symlink to a system specific filesystem for example '/web' links
Yea, it gets a little complicated for the non-sysres stuff. We are shared ZFS
across the sysplex. We do have a couple of one-off's in /usr/lpp/ as well.
So, a couple of observations I made. You have two types of filesystems. 1)
those that are shared across the sysplex, 2) those
I finally was able to migrate all HFS's to ZFS's, then design a shared ZFS
environment with a sysplex root, version root and system(s) root.
to facilitate this environment I IPL'd each LPAR from the same SYSRES and
shared parmlib using symbols for system specific parms.
What I'm wondering
Caught this on the newsgroup, not the LISTSERV:
--
jean.b...@ca-attica.fr
Hello. We are in the process to separate our current SYSPLEX in two :
1. for the production
2. for the dev/qualifications.
A. Can we use an unique TWS controller to Schedule jobs on two ?
B. Can we use RACF RRSF
I know this is not OP's first bronco ride in a sysplex rodeo, but I have a few
more suggestions.
-- Create a new unique name for the combined sysplex.
-- Pick one (least critical) system and start there as the first member of the
new sysplex.
-- Once the new sysplex is running
Hi Kees and Allan,
Thank you both for your suggestions. I greatly appreciate all the input I am
receiving as I get through the "Insomnia Cure"I mean the IBM Red Book on
Setting up a Sysplex. I will definitely include your input in my notes I am
making as I read through the boo
age-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Allan Staller
> Sent: 06 February, 2018 14:46
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Setting up a new parallel sysplex
>
> I would attempt to make any decisions regardi
ntroduced in earlier
releases of z/OS for inclusion.
HTH,
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Fred Glenlake
Sent: Monday, February 5, 2018 3:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Setting up a new parallel
suggest a sequence of events to
follow to get from "see spot run/bronzeplex" sysplex to full parallel sysplex
that would be greatly appreciated. Not messing up what is already there in
the current coupling datasets and defining new ones to house all the new
structures I would think w
301 - 400 of 858 matches
Mail list logo
