Discussion:
Task Flow Recorder for CICS
(too old to reply)
Cameron Conacher
2018-07-06 13:28:50 UTC
Permalink
Is anyone out there using IBM’s Task Flow Recorder for CICS?

Could you share anything? Experience. Initial costs. Licensing costs? Benefits? Limitations seen?

Thanks
.......Cameron

Sent from my iPhone
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Timothy Sipples
2018-07-09 07:04:29 UTC
Permalink
Post by Cameron Conacher
Is anyone out there using IBM’s Task Flow Recorder for CICS?
Are you referring to this product from AlgoriNet:

https://www.cicsrecorder.com/tfr

or something else?

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Cameron Conacher
2018-07-09 11:37:59 UTC
Permalink
Actually, I was referring to this product offering from IBM:
https://www-356.ibm.com/partnerworld/gsd/solutiondetails.do?&solution=54007

Well, I guess this an offering from an IBM Partner.

.......Cameron
Post by Timothy Sipples
Post by Cameron Conacher
Is anyone out there using IBM’s Task Flow Recorder for CICS?
https://www.cicsrecorder.com/tfr
or something else?
------------------------------------------------------------
--------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
ITschak Mugzach
2018-07-09 12:17:08 UTC
Permalink
You both referenced the same product. HAven't used it myself, but have some
clients that does and are (very) happy. I think the owner, Ishai, is
monitoring the list, but you can contact him directly at
***@yahoo.com.

ITschak
Post by Cameron Conacher
https://www-356.ibm.com/partnerworld/gsd/solutiondetails.do?&solution=54007
Well, I guess this an offering from an IBM Partner.
.......Cameron
Post by Timothy Sipples
Post by Cameron Conacher
Is anyone out there using IBM’s Task Flow Recorder for CICS?
https://www.cicsrecorder.com/tfr
or something else?
------------------------------------------------------------
--------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **| *

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Cameron Conacher
2018-07-09 14:09:46 UTC
Permalink
I have exchanged emails with Ishai.
Just curious if anyone has used it, and what their experiences were.
It looks very promising (IMHO).
Post by ITschak Mugzach
You both referenced the same product. HAven't used it myself, but have some
clients that does and are (very) happy. I think the owner, Ishai, is
monitoring the list, but you can contact him directly at
ITschak
Post by Cameron Conacher
https://www-356.ibm.com/partnerworld/gsd/solutiondetails.do?&solution=
54007
Post by Cameron Conacher
Well, I guess this an offering from an IBM Partner.
.......Cameron
Post by Timothy Sipples
Post by Cameron Conacher
Is anyone out there using IBM’s Task Flow Recorder for CICS?
https://www.cicsrecorder.com/tfr
or something else?
------------------------------------------------------------
--------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **| *
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Timothy Sipples
2018-07-10 04:30:31 UTC
Permalink
You might want to ask for reviews on the CICS-L mailing list if you haven't
already.

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Timothy Sipples
2018-07-10 04:57:03 UTC
Permalink
...for availability reasons one should avoid having CF
and z/OS LPAR on the same hardware, which means....
That's not phrased as IBM would phase it, and it's not correct as written.

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 with IBM's recommendations here.

David Raften has published a whitepaper (updated in May, 2018) that
explains the various CF configuration options. The direct link to the
current edition is here:

https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971usen-.pdf

If you're reading this post substantially later than July, 2018, then
please check first to see whether there's yet another updated edition.
David discusses what I just described, the "Logical Stand-Alone CF"
configuration, starting on page 9 of that whitepaper.

Just because something has merit doesn't automatically mean it has merit
for the next available increment of resources (budget, effort, etc.) I
always try to approach business risk reduction holistically, in end-to-end
business service terms starting with the most critical business services.
If adopting a stand-alone CF configuration is the highest, next best use of
available resources within that end-to-end service context, great. And
isn't it wonderful how much flexibility you have with these technologies,
to craft (and re-craft) the most appropriate configurations for the desired
business outcomes?

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-07-10 10:00:40 UTC
Permalink
Post by Timothy Sipples
...for availability reasons one should avoid having CF
and z/OS LPAR on the same hardware, which means....
That's not phrased as IBM would phase it, and it's not correct as written.
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 with IBM's recommendations here.
David Raften has published a whitepaper (updated in May, 2018) that
explains the various CF configuration options. The direct link to the
https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971usen-.pdf
[...]

I quickly browsed the document and found confirmation what I learned
several years ago.
That means:
Yes, you need either standalone CF (*see note) or CF structure
duplexing! This is required for *some* structures, but ...it is. David
Rften call it structures which /require failure independence/.

Note: Standalone CF should be understood here as LOGICAL stand alone CF.
IBM-MIAN do not allo pictures, so I'll try to describe it:
SYSPLEX PROD:
z/OS 1 in CPC A, z/OS 2 in CPC B, and CF2 in CPC B or A. And CF1 in CPC C.
Three CPCs.
However CPC C may be used for other purpose, i.e. for test LPARs.
Anything but z/OS image belonging to the sysplex PROD.

There is also two-CPC configuration
z/OS 1 + CF1 in CPC A, z/OS 2 + CF2 in CPC B and *some structures are
duplexed*.
What I heard unofficially from IBM-ers is such configuration is "budget"
read: when you cannot afford good one.
And the link between CFs should be really local (short).


Note2: it is also possible to build a configuration without dedicated
(logical stand alone) CF and without duplexing. Your choice.
However it is NOT resistant to all possible (single) failures. Yes, it
is still better than parallel sysplex with single CF, but still
vulnerable to some failures.
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2018-07-10 23:15:28 UTC
Permalink
It's easy to diss a solution as 'budget' when it saves someone *else* money. The notion that a third CEC for standalone CF is substantially better than ICF is illusory. If you truly believe that one extra CEC is necessary, then you really need two extra CECs for CF because there are times when you have to take one of them down. Maybe for repair, maybe for upgrade. So you still need a backup.

OTOH, 'logical standalone'--interesting term--with an ICF in each z/OS CEC is a sufficient solution. We've run this way for years and survived two separate hard-down CEC failures with zero recovery agony. My recommendation is to run two CECs, one substantial box to run application hosts, and a minimal 'penalty box' just for ICFs plus a few high-cost products that bill significantly less on a small CEC. With proper structure duplexing, you have extraordinary redundancy at a reasonable cost.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of R.S.
Sent: Tuesday, July 10, 2018 3:00 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Sysplex between two hardware
Post by Timothy Sipples
...for availability reasons one should avoid having CF and z/OS LPAR
on the same hardware, which means....
That's not phrased as IBM would phase it, and it's not correct as written.
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 with IBM's recommendations here.
David Raften has published a whitepaper (updated in May, 2018) that
explains the various CF configuration options. The direct link to the
https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971u
sen-.pdf
[...]

I quickly browsed the document and found confirmation what I learned several years ago.
That means:
Yes, you need either standalone CF (*see note) or CF structure duplexing! This is required for *some* structures, but ...it is. David Rften call it structures which /require failure independence/.

Note: Standalone CF should be understood here as LOGICAL stand alone CF.
IBM-MIAN do not allo pictures, so I'll try to describe it:
SYSPLEX PROD:
z/OS 1 in CPC A, z/OS 2 in CPC B, and CF2 in CPC B or A. And CF1 in CPC C.
Three CPCs.
However CPC C may be used for other purpose, i.e. for test LPARs.
Anything but z/OS image belonging to the sysplex PROD.

There is also two-CPC configuration
z/OS 1 + CF1 in CPC A, z/OS 2 + CF2 in CPC B and *some structures are duplexed*.
What I heard unofficially from IBM-ers is such configuration is "budget"
read: when you cannot afford good one.
And the link between CFs should be really local (short).


Note2: it is also possible to build a configuration without dedicated
(logical stand alone) CF and without duplexing. Your choice.
However it is NOT resistant to all possible (single) failures. Yes, it
is still better than parallel sysplex with single CF, but still
vulnerable to some failures.
--
Radoslaw Skorupka
Lodz, Poland


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-07-11 09:25:06 UTC
Permalink
Maybe it's illusory, but that is in David Raften document.
Obviously it's cheaper to have 2 CPCs than 3, but it is also cheaper to
have 1 CPC than 2.
The white paper clearly describes some structures as demanding duplexing
or third CPC with failure-isolated CF.
--
Radoslaw Skorupka
Lodz, Poland
Post by Jesse 1 Robinson
It's easy to diss a solution as 'budget' when it saves someone *else* money. The notion that a third CEC for standalone CF is substantially better than ICF is illusory. If you truly believe that one extra CEC is necessary, then you really need two extra CECs for CF because there are times when you have to take one of them down. Maybe for repair, maybe for upgrade. So you still need a backup.
OTOH, 'logical standalone'--interesting term--with an ICF in each z/OS CEC is a sufficient solution. We've run this way for years and survived two separate hard-down CEC failures with zero recovery agony. My recommendation is to run two CECs, one substantial box to run application hosts, and a minimal 'penalty box' just for ICFs plus a few high-cost products that bill significantly less on a small CEC. With proper structure duplexing, you have extraordinary redundancy at a reasonable cost.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
-----Original Message-----
Sent: Tuesday, July 10, 2018 3:00 AM
Subject: (External):Re: Sysplex between two hardware
Post by Timothy Sipples
...for availability reasons one should avoid having CF and z/OS LPAR
on the same hardware, which means....
That's not phrased as IBM would phase it, and it's not correct as written.
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 with IBM's recommendations here.
David Raften has published a whitepaper (updated in May, 2018) that
explains the various CF configuration options. The direct link to the
https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971u
sen-.pdf
[...]
I quickly browsed the document and found confirmation what I learned several years ago.
Yes, you need either standalone CF (*see note) or CF structure duplexing! This is required for *some* structures, but ...it is. David Rften call it structures which /require failure independence/.
Note: Standalone CF should be understood here as LOGICAL stand alone CF.
z/OS 1 in CPC A, z/OS 2 in CPC B, and CF2 in CPC B or A. And CF1 in CPC C.
Three CPCs.
However CPC C may be used for other purpose, i.e. for test LPARs.
Anything but z/OS image belonging to the sysplex PROD.
There is also two-CPC configuration
z/OS 1 + CF1 in CPC A, z/OS 2 + CF2 in CPC B and *some structures are duplexed*.
What I heard unofficially from IBM-ers is such configuration is "budget"
read: when you cannot afford good one.
And the link between CFs should be really local (short).
Note2: it is also possible to build a configuration without dedicated
(logical stand alone) CF and without duplexing. Your choice.
However it is NOT resistant to all possible (single) failures. Yes, it
is still better than parallel sysplex with single CF, but still
vulnerable to some failures.
======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Richards, Robert B.
2018-07-11 09:35:08 UTC
Permalink
Just make sure that if you have a standalone CPC with CFs for that purpose that its engines are as fast as your other CPCs engines. I got into a performance problem 15 years ago when a 9674 was kept around longer that it should have been. You are only as fast as your slowest <insert appropriate component here>.

Bob

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of R.S.
Sent: Wednesday, July 11, 2018 5:25 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Sysplex between two hardware

Maybe it's illusory, but that is in David Raften document.
Obviously it's cheaper to have 2 CPCs than 3, but it is also cheaper to
have 1 CPC than 2.
The white paper clearly describes some structures as demanding duplexing
or third CPC with failure-isolated CF.
--
Radoslaw Skorupka
Lodz, Poland
Post by Jesse 1 Robinson
It's easy to diss a solution as 'budget' when it saves someone *else* money. The notion that a third CEC for standalone CF is substantially better than ICF is illusory. If you truly believe that one extra CEC is necessary, then you really need two extra CECs for CF because there are times when you have to take one of them down. Maybe for repair, maybe for upgrade. So you still need a backup.
OTOH, 'logical standalone'--interesting term--with an ICF in each z/OS CEC is a sufficient solution. We've run this way for years and survived two separate hard-down CEC failures with zero recovery agony. My recommendation is to run two CECs, one substantial box to run application hosts, and a minimal 'penalty box' just for ICFs plus a few high-cost products that bill significantly less on a small CEC. With proper structure duplexing, you have extraordinary redundancy at a reasonable cost.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
-----Original Message-----
Sent: Tuesday, July 10, 2018 3:00 AM
Subject: (External):Re: Sysplex between two hardware
Post by Timothy Sipples
...for availability reasons one should avoid having CF and z/OS LPAR
on the same hardware, which means....
That's not phrased as IBM would phase it, and it's not correct as written.
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 with IBM's recommendations here.
David Raften has published a whitepaper (updated in May, 2018) that
explains the various CF configuration options. The direct link to the
https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971u
sen-.pdf
[...]
I quickly browsed the document and found confirmation what I learned several years ago.
Yes, you need either standalone CF (*see note) or CF structure duplexing! This is required for *some* structures, but ...it is. David Rften call it structures which /require failure independence/.
Note: Standalone CF should be understood here as LOGICAL stand alone CF.
z/OS 1 in CPC A, z/OS 2 in CPC B, and CF2 in CPC B or A. And CF1 in CPC C.
Three CPCs.
However CPC C may be used for other purpose, i.e. for test LPARs.
Anything but z/OS image belonging to the sysplex PROD.
There is also two-CPC configuration
z/OS 1 + CF1 in CPC A, z/OS 2 + CF2 in CPC B and *some structures are duplexed*.
What I heard unofficially from IBM-ers is such configuration is "budget"
read: when you cannot afford good one.
And the link between CFs should be really local (short).
Note2: it is also possible to build a configuration without dedicated
(logical stand alone) CF and without duplexing. Your choice.
However it is NOT resistant to all possible (single) failures. Yes, it
is still better than parallel sysplex with single CF, but still
vulnerable to some failures.
======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-07-11 10:31:36 UTC
Permalink
Yes, that's true.
Fortunately ICF as other specialty engines always run at full speed.
That's also reason why one should not use older machines for CF.

BTW: Third CPC need not be very expensive. I'm neither IBM sales guy,
nor "standalone CF evnagelist", but when you buy two CPCs with CP
engines you pay for MIPS then for the frame. In such deal, adding
another CPC with zero MIPS can be quite inexpensive when compared to
"regular" CPC.

And regarding level of redundancy: it's obvious when you use spare wheel
you don't have spare. It's the same with CF. AFAIK you can 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
Post by Richards, Robert B.
Just make sure that if you have a standalone CPC with CFs for that purpose that its engines are as fast as your other CPCs engines. I got into a performance problem 15 years ago when a 9674 was kept around longer that it should have been. You are only as fast as your slowest <insert appropriate component here>.
Bob
-----Original Message-----
Sent: Wednesday, July 11, 2018 5:25 AM
Subject: Re: Sysplex between two hardware
Maybe it's illusory, but that is in David Raften document.
Obviously it's cheaper to have 2 CPCs than 3, but it is also cheaper to
have 1 CPC than 2.
The white paper clearly describes some structures as demanding duplexing
or third CPC with failure-isolated CF.
======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Timothy Sipples
2018-07-11 07:41:18 UTC
Permalink
Post by Jesse 1 Robinson
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 adopt it in order to reduce or eliminate most
planned and unplanned outages (for the part of their business services
relying on IBM Z resources). The single machine z/OS Parallel Sysplex is a
terrific value and quite easy to implement. For some odd reason there's a
misconception that if you want to upgrade from PLEXCFG=XCFLOCAL or
PLEXCFG=MONOPLEX that you must add another machine. No, that's not correct.

Moreover, you can run terrifically useful z/OS features such as VSAM RLS
and Transactional VSAM even in a PLEXCFG=MONOPLEX mode with one z/OS LPAR
(or one z/OS guest in z/VM). That's another popular misconception.

Within z/OS Parallel Sysplex configurations you get to decide which
subsystems and applications to protect, and how. As one example, you might
decide to implement MQ shared queues but otherwise not do much else.
Messages can then still be received and queued for processing, even when
the only instance of a particular application (or whole LPAR) is offline
for maintenance or some other purpose. If "Yes, I've got your message, and
I'll get to it soon" is good enough to meet the business requirements
between 3:00 a.m. and 4:00 a.m. every third Sunday of the month, or
whatever, FINE!

There are all kinds of really interesting configuration choices available
to cater to particular business service objectives, and it's wonderful to
have the flexibility. It's important to have some basic familiarity with
these various options if you have a role in advising on configurations.

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-07-11 09:31:15 UTC
Permalink
Post by Timothy Sipples
Post by Jesse 1 Robinson
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 adopt it in order to reduce or eliminate most
planned and unplanned outages (for the part of their business services
relying on IBM Z resources). The single machine z/OS Parallel Sysplex is a
terrific value and quite easy to implement. For some odd reason there's a
misconception that if you want to upgrade from PLEXCFG=XCFLOCAL or
PLEXCFG=MONOPLEX that you must add another machine. No, that's not correct.
Moreover, you can run terrifically useful z/OS features such as VSAM RLS
and Transactional VSAM even in a PLEXCFG=MONOPLEX mode with one z/OS LPAR
(or one z/OS guest in z/VM). That's another popular misconception.
Within z/OS Parallel Sysplex configurations you get to decide which
subsystems and applications to protect, and how. As one example, you might
decide to implement MQ shared queues but otherwise not do much else.
Messages can then still be received and queued for processing, even when
the only instance of a particular application (or whole LPAR) is offline
for maintenance or some other purpose. If "Yes, I've got your message, and
I'll get to it soon" is good enough to meet the business requirements
between 3:00 a.m. and 4:00 a.m. every third Sunday of the month, or
whatever, FINE!
There are all kinds of really interesting configuration choices available
to cater to particular business service objectives, and it's wonderful to
have the flexibility. It's important to have some basic familiarity with
these various options if you have a role in advising on configurations.
Timothy,
It's 90% off-topic, but 99% right.  The missing 1% is about XCFLOCAL and
MONOPLEX mess. What misconception do you mean?
Monoplex does not require (does not use) CF at all. It is not the same
thing as single-image parallel sysplex, which require CF. Failure
isolation is another issue.  RLS require Parallel Sysplex, but not
everyone need it.


Regards
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...