SYSPLEX distance

Discussion:

SYSPLEX distance

(too old to reply)

AlanWatthey , GMAIL

2018-01-03 06:17:37 UTC

I have had a strange request from management as to how far apart we can move
our production systems. I know there are limitations on how far the (in
this case) two systems (and two coupling facilities) can be apart and I've
dug up an old IBM Redbook on the issue where they did tests with a sysplex
at 0, 20, 40, 60 and 80 kms apart. Physical limitations (eg. FICON) don't
seem to be an issue. We are a CICS and DB2 shop so the manual certainly
addressed issues that we might see but it is dated 2008 so has anything
changed since then? CICS and DB2 have moved on a long way in that time.

I was thinking of saying up to 10km but this is really a finger in the air
value. Maybe it's only 5 and maybe its 20 or 30. Can we just throw CPU and
memory at it as I would think we would have a lot more transactions running
at the same time with some (but not all apparently) having extra delays
incurred? The transaction increases suggested in that manual are
milleseconds and these days (with all the distributed systems involved) the
users are happy to get 10 second response times. Admitted this can involve
many, many transactions behind the scenes from the application servers to
populate their crowded browser screens. Gone are the days of data-entry
pools and sub-second responses.

What I was wondering is there anyone out there with real life experience on
this kind of activity. How far apart do people run their sysplex systems?
What gotchas sprang up to relieve them of their sanity? Any pointers would
be gratefully appreciated.

Regards,

Alan Watthey

From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of IBM-MAIN automatic digest system
Sent: 03 January 2018 8:00 am
To: IBM-***@LISTSERV.UA.EDU
Subject: IBM-MAIN Digest - 1 Jan 2018 to 2 Jan 2018 (#2018-2)

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

Mike Schwab

2018-01-03 08:50:35 UTC

Permalink

https://www.ibm.com/it-infrastructure/z/technologies/gdps

https://www.infoworld.com/article/2614033/disaster-recovery/data-centers-under-water--what--me-worry-.html

Post by AlanWatthey , GMAIL
I have had a strange request from management as to how far apart we can move
our production systems. I know there are limitations on how far the (in
this case) two systems (and two coupling facilities) can be apart and I've
dug up an old IBM Redbook on the issue where they did tests with a sysplex
at 0, 20, 40, 60 and 80 kms apart. Physical limitations (eg. FICON) don't
seem to be an issue. We are a CICS and DB2 shop so the manual certainly
addressed issues that we might see but it is dated 2008 so has anything
changed since then? CICS and DB2 have moved on a long way in that time.
I was thinking of saying up to 10km but this is really a finger in the air
value. Maybe it's only 5 and maybe its 20 or 30. Can we just throw CPU and
memory at it as I would think we would have a lot more transactions running
at the same time with some (but not all apparently) having extra delays
incurred? The transaction increases suggested in that manual are
milleseconds and these days (with all the distributed systems involved) the
users are happy to get 10 second response times. Admitted this can involve
many, many transactions behind the scenes from the application servers to
populate their crowded browser screens. Gone are the days of data-entry
pools and sub-second responses.
What I was wondering is there anyone out there with real life experience on
this kind of activity. How far apart do people run their sysplex systems?
What gotchas sprang up to relieve them of their sanity? Any pointers would
be gratefully appreciated.
Regards,
Alan Watthey
Behalf Of IBM-MAIN automatic digest system
Sent: 03 January 2018 8:00 am
Subject: IBM-MAIN Digest - 1 Jan 2018 to 2 Jan 2018 (#2018-2)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Edward Gould

2018-01-03 21:30:01 UTC

Permalink

https://www.ibm.com/it-infrastructure/z/technologies/gdps <https://www.ibm.com/it-infrastructure/z/technologies/gdps>
https://www.infoworld.com/article/2614033/disaster-recovery/data-centers-under-water--what--me-worry-.html <https://www.infoworld.com/article/2614033/disaster-recovery/data-centers-under-water--what--me-worry-.html>

Mike,

Thank you a LOT for this! Management will be getting a copy today.

Ed

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

Mike Schwab

2018-01-03 21:41:42 UTC

Permalink

It says global, but limited intercontinental links limit you to one continent.

Post by Edward Gould

Mike,
Thank you a LOT for this! Management will be getting a copy today.
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Edward Gould

2018-01-04 00:52:27 UTC

Permalink

Post by Mike Schwab
It says global, but limited intercontinental links limit you to one continent.

Mike,

At one previous employers place wanted to span Continents (US and India) I believe. I am not sure how much of this actually happened as I left in the thinking process.

I do vaguely remember that they had issues just going from Chicago to the west coast. There were technical issues I believe (but was not privy to them).

I am *still* unclear as to how cryptography works in any sysplex whether it be local or remote. Is there a red piece on this somewhere?

Ed

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

Mike Schwab

2018-01-04 01:53:45 UTC

Permalink

Searched for ibm zos cryptography. First 10 results seemed useful. A
share expo, some intros, some PDF manuals.
https://www.google.com/search?q=ibm+zos+cryptography

Post by Edward Gould

Post by Mike Schwab
It says global, but limited intercontinental links limit you to one continent.

Mike,
At one previous employers place wanted to span Continents (US and India) I believe. I am not sure how much of this actually happened as I left in the thinking process.
I do vaguely remember that they had issues just going from Chicago to the west coast. There were technical issues I believe (but was not privy to them).
I am *still* unclear as to how cryptography works in any sysplex whether it be local or remote. Is there a red piece on this somewhere?
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Edward Gould

2018-01-04 05:41:03 UTC

Permalink

Post by Mike Schwab
Searched for ibm zos cryptography. First 10 results seemed useful. A
share expo, some intros, some PDF manuals.
https://www.google.com/search?q=ibm+zos+cryptography

(off list)
I glanced through the google list and a couple of entries. Maybe I am to too thick.

I still have yet to figure out how if one system writes the dataset and another system goes to read it how will it know the key that was used during dataset creation. It becomes increasingly complex with GDPS, no?
Ed

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

Parwez Hamid

2018-01-03 09:46:27 UTC

Permalink

Some additional sources of info:

System z Parallel Sysplex Best Practices: http://www.redbooks.ibm.com/redpieces/abstracts/sg247817.html

Parallel Sysplex on IBM Z: https://www.ibm.com/it-infrastructure/z/technologies/parallel-sysplex

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

mario bezzi

2018-01-03 10:20:14 UTC

Permalink

Alan,

after the redbook the team and I have been involved in many projects to
distribute workloads across distance.

The main issue is the secondary effect of distance, which depends on how
your applications are written. In my experience this is mainly related
to data access and serialization. I have large customers happily running
at 30+ km distance, and others who gave up at 5 km because of their
applications' locking rates, which makes their applications very
sensitive to distance.

A review of your current transactions' response times by component could
tell you if there are serious inhibitors, but in most cases these only
show up when going over distance. That's why we always recommend testing
as there is no accurate way to predict the impact of distance on
response times.

Attention must be paid to batch processing, which benefits less from
caching mechanisms provided by middleware. Is your batch window
constrained? Do you plan to run batch across sites or locally in the
site which will host primary DASD and CFs? Batch can be a more sensitive
workload than online.

Finally, and I try to address this before starting any technological
discussion: What are you trying to achieve by going over distance? Most
customers I worked with equate multi-site parallel sysplex with even
workload distribution to non stop operation. This may be or may not be
true, and depending on your actual needs a slightly different
configuration might do with less performance impact.

Asynchronous CF locking is the major enhancement in the area of
performance over distance. It was made available ealry last year,
requires DB2 v12, z/OS Version 2 Release 2 + APAR OA47796 and CFCC lvl
21 with Service Level 02.16 or later.

Hope this helps,
mario

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

Dana Mitchell

2018-01-03 15:12:11 UTC

Permalink

Also keep in mind if you are reading old Redbooks if they reference Sysplex timers. The change from Sysplex Timer to STP changed timer signalling from discrete ETR links to using CF links for timing signals. This may have influence on distances and latency planning.
Dana

Post by AlanWatthey , GMAIL
I've
dug up an old IBM Redbook on the issue where they did tests with a sysplex
at 0, 20, 40, 60 and 80 kms apart. Physical limitations (eg. FICON) don't
seem to be an issue. We are a CICS and DB2 shop so the manual certainly
addressed issues that we might see but it is dated 2008 so has anything
changed since then?

Timothy Sipples

2018-01-04 05:40:33 UTC

Permalink

Please make sure you take one recent (late 2016) innovation into
consideration: Asynchronous CF Lock Duplexing. My understanding is that
this recently introduced Coupling Facility feature offers performance
improvements in many scenarios, including some distance "stretched"
Parallel Sysplexes. IBM published some related performance test data only
last year (2017). If you're looking at older references, you might be
missing a lot.

It could be helpful to understand the motivation(s) behind the question. As
a notable example, does somebody want to create (or maintain) a
"BronzePlex" to satisfy Parallel Sysplex aggregation rules? (Those rules
are becoming less relevant now, at least, but that's a separate point.) As
another example, if the focus is on protecting and preserving data, then it
might make sense to stretch the storage but not the Sysplex.

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA
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-01-04 06:00:18 UTC

Permalink

We're also interested in any solution NOT requiring z/OS.

I understand IBM is working on data teleportation, or what some people call
the "psychic engine." This technology will be able to read the "minds" of
server systems without server involvement....

....OK, my point is that what you're describing is not actually
possible. :-) z/OS will have to be involved, at least to transmit the data,
dump the data to tape, place the data on a volume for zdsfs access, print
the data onto optically scannable paper (!), something. Given that z/OS
must be involved, some ways are smarter than others.

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA
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

John McKown

2018-01-04 13:15:12 UTC

Permalink

Post by Timothy Sipples

We're also interested in any solution NOT requiring z/OS.

I understand IBM is working on data teleportation, or what some people call
the "psychic engine." This technology will be able to read the "minds" of
server systems without server involvement....

Hum, is this some sort of stealth announcement. Can I expect this feature
to be implemented on the latest z42q ("42" for "the answer to life ..." and
"q" for quantum) machine?

Post by Timothy Sipples
....OK, my point is that what you're describing is not actually
possible. :-) z/OS will have to be involved, at least to transmit the data,
dump the data to tape, place the data on a volume for zdsfs access, print
the data onto optically scannable paper (!), something. Given that z/OS
must be involved, some ways are smarter than others.

What Frank wants is to process z/OS data from a _third_ party on an
Intel(?) platform using the Java language on that platform. He does not
want to transfer the third party z/OS data to their z/OS at all. This
third party data is not textual, but includes text data (encoded in CP-037
or maybe IBM-1047) along with binary integers (fullword & halfword?) and
maybe some packed decimal as well. Hopefully this data would _NOT_ include
HFP floating point since that would be a real PITA to use on an Intel (or
any other non-IBMZ) platform.

I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Kirk Wolf

2018-01-04 13:29:07 UTC

Permalink

The com.ibm.jzos.fields package supports binary, packed, zoned, and HFP
data and will run on non-z/OS Java platforms.
When running on z/OS, some of the converters will use "data access
acceleration" primitives to speed things up, but otherwise the code is just
Java.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

Post by John McKown
What Frank wants is to process z/OS data from a _third_ party on an
Intel(?) platform using the Java language on that platform. He does not
want to transfer the third party z/OS data to their z/OS at all. This
third party data is not textual, but includes text data (encoded in CP-037
or maybe IBM-1047) along with binary integers (fullword & halfword?) and
maybe some packed decimal as well. Hopefully this data would _NOT_ include
HFP floating point since that would be a real PITA to use on an Intel (or
any other non-IBMZ) platform.
I have a theory that it's impossible to prove anything, but I can't prove
it.
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

John McKown

2018-01-04 14:07:23 UTC

Permalink

Post by Kirk Wolf
The com.ibm.jzos.fields package supports binary, packed, zoned, and HFP
data and will run on non-z/OS Java platforms.
When running on z/OS, some of the converters will use "data access
acceleration" primitives to speed things up, but otherwise the code is just
Java.

Yes. And I've used that facility myself to process z/OS SMF data on an
Linux/Intel system. It works fairly well (considering my Linux system at
work is on a "retired" Dual Pentium D machine!). I think that Frank's
problem with all of this is fear of the IBM lawyers and whether he is
authorized to use this software on a non-z/OS (Windows?) system. I think
that it is rather obvious that _I_, on a company machine, have a licensed
to download the z/OS Java code to my _company owned_ PC in order to write
Java code which will be used to process _company_ data.

In general, even without using the com.bim.jzos.* jar files, it is not what
I'd call "difficult" to process z/OS (EBCDIC text and binary data) using
Java on an ASCII platform. It is just "fiddly". Using the JZOS jar and the
Java Record Generator reduces the "fiddliness" of doing it. I used these
facilities back in 2009 to create a set of Java program to process a lot of
the SMF record types. The hardest part was writing up the HLASM invocation
of the SMF macros to generate the ADATA needed to feed into the Java Record
Generator. And I have no doubt that Dovetailed's "fingerprints" are all
over it because I remember when JZOS was a Dovetailed Technologies
"product" and not part of the IBM JDK.

Post by Kirk Wolf
Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Kirk Wolf

2018-01-04 15:42:07 UTC

Permalink

NB: I do not speak for IBM on licensing issues on this. at all.

The JZOS Record Generator is not part of the z/OS SDK, but it does include
the runtime classes (com.ibm.jzos.fields).
It is available free to z/OS users. See:
https://www.ibm.com/support/knowledgecenter/SSMQ4D_3.0.0/documentation/welcome.html

Licensing issues aside, the record generator package includes everything
you need to generate Java recording mapping classes AND run them.

Some licensing use cases:

1) licensed z/OS customer installs JZOS Record Generator on a workstation
for use in an IDE.
2) licensed z/OS customer installs JZOS Record Generator on a workstation
or server in their environment and run the Java classes included in it for
something other than "development".
3) licensed z/OS customer distributes the JZOS Record Generator to another
organization who is not licensed to use it.

The IBM documentation seems to say that (1) is OK.
(3) is obviously not OK.

The outstanding question IMO is (2). If the download site was available
today I would try to read the license agreement :-)
There was a previous version of the JZOS Record Generator that was
available on alphaWorks and developerWorks. I believe that the license
agreement there does allow (2).

So I would contact IBM and see if they will answer the question.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

Post by John McKown

just

Post by Kirk Wolf
Java.

Yes. And I've used that facility myself to process z/OS SMF data on an
Linux/Intel system. It works fairly well (considering my Linux system at
work is on a "retired" Dual Pentium D machine!). I think that Frank's
problem with all of this is fear of the IBM lawyers and whether he is
authorized to use this software on a non-z/OS (Windows?) system. I think
that it is rather obvious that _I_, on a company machine, have a licensed
to download the z/OS Java code to my _company owned_ PC in order to write
Java code which will be used to process _company_ data.
In general, even without using the com.bim.jzos.* jar files, it is not what
I'd call "difficult" to process z/OS (EBCDIC text and binary data) using
Java on an ASCII platform. It is just "fiddly". Using the JZOS jar and the
Java Record Generator reduces the "fiddliness" of doing it. I used these
facilities back in 2009 to create a set of Java program to process a lot of
the SMF record types. The hardest part was writing up the HLASM invocation
of the SMF macros to generate the ADATA needed to feed into the Java Record
Generator. And I have no doubt that Dovetailed's "fingerprints" are all
over it because I remember when JZOS was a Dovetailed Technologies
"product" and not part of the IBM JDK.

Post by Kirk Wolf
Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
I have a theory that it's impossible to prove anything, but I can't prove
it.
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

p***@gmail.com

2018-01-04 17:46:18 UTC

Permalink

IBM Record Generator for Java V3 is now a supported IBM program product for users of z/OS 2.1 or later, meaning PMRs can be raised against it. However things have changed slightly from V2 as V3 now only provides the packages com.ibm.recordgen.* and not com.ibm.jzos.fields.

The IBM Record Generator JAR itself is licensed using the standard IBM terms for "Redistributables" with the aim of supporting distributed development and build.

In addition to run the generators or to execute the mapping classes on a distributed platform you will now also need to download the JZOS toolkit API (ibmjzos.jar) which is provided with the Java SDK on z/OS. To support this mode of operation this JAR is also licensed as a "Redistributables" in the latest fixpacks of the following Java service releases 8.0.4, 7.1.4, 7.0.10

In addition Eclipse developers using the latest z/OS Explorer or IDZ can add the JZOS toolkit API JAR to a project build path using the "Add Library" wizard without having to download it.

Hopefully this helps to answer the questions

Phil Wakelin, IBM Hursley UK.

Frank Swarbrick

2018-01-04 20:43:11 UTC

Permalink

The data is generated on the vendors mainframe and transmitted to us. From the time we get it we'd like to be able to "process" the data (most likely placing it in an Oracle database) without the need for z/OS on our side.

________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Timothy Sipples <***@SG.IBM.COM>
Sent: Wednesday, January 3, 2018 11:01 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: JZOS on open systems question

We're also interested in any solution NOT requiring z/OS.

Frank Swarbrick

2018-01-04 20:49:46 UTC

Permalink

I wasn't concerned about legal issues at all. I was (until now!) only wondering if the JZOS facilities that allow this actually require a z/OS environment to even work. Though now that I think about it, perhaps we could use JZOS to translate the vendor data to data that is easier to deal with off-mainframe, and then give the code to the vendor to run for us and send us our data. Since we both have z/OS there shouldn't be a licensing issue. Something else to consider, certainly. And really, if we went that way we could probably just use COBOL.

Things to ponder. Hopefully we can just convince the vendor to do what we need for a reasonable cost and not worry about any of this backdoor stuff.
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Frank Swarbrick <***@OUTLOOK.COM>
Sent: Thursday, January 4, 2018 1:44 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: JZOS on open systems question

The data is generated on the vendors mainframe and transmitted to us. From the time we get it we'd like to be able to "process" the data (most likely placing it in an Oracle database) without the need for z/OS on our side.

________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Timothy Sipples <***@SG.IBM.COM>
Sent: Wednesday, January 3, 2018 11:01 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: JZOS on open systems question

We're also interested in any solution NOT requiring z/OS.

Timothy Sipples

2018-01-05 05:55:18 UTC

Permalink

Yes, please contact "your friendly IBM representative" before you attempt
to run JZOS (or any portion thereof) on something other than a licensed
z/OS instance. That goes for anything and everything that's part of z/OS,
or any other licensed software product for that matter. Unless there's
something in IBM's writing that clearly says otherwise,(*) my advice would
be to assume anything and everything in z/OS is z/OS, you must license
z/OS, and you run that component on z/OS.

The same would be true of, for example, Microsoft Notepad (NOTEPAD.EXE)
that is part of Microsoft Windows. You cannot assume that you can just grab
NOTEPAD.EXE and go run it on your Macintosh (for example) without a license
from Microsoft, *regardless of technical ability*. NOTEPAD.EXE is part of
their licensed, copyrighted software product.

I'm aware of a party that ripped a piece of OS/390 and then used it
somewhere else, without an OS/390 license, without asking IBM for
permission. IBM was not amused. :-( There was a price; it was paid. I dare
say none of our employers (or the companies we run, if applicable) would be
happy in comparable circumstances, no matter whether the product is
physical or information-based.

Basic, basic stuff here.

(*) As an example of "otherwise," when you license MQ for z/OS, Version 8
or higher (or with the "Client Attach Feature" in prior releases), you are
also licensed for MQ clients (most at least) at no additional charge, in
any number, and even beyond your own enterprise, so long as those MQ
clients only connect to your licensed MQ servers. But that doesn't mean
(for example) you can grab a chunk of the MQ client code and embed it in
your mobile app that then connects to some Vendor X's server that isn't
licensed MQ from IBM. You must check and follow the license. As another
example, the license might say, "Sure, you can use this software, but you
must publish the following notice in your distribution." So you must do
that...or don't use any of that software, or ask the licensor for specific
permission to do something else. Take a look at your Apple iOS device (if
you have one), if you'd like a little light reading: Settings -> General ->
About -> Legal -> Legal Notices.

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA
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

phil_wakelin@uk.ibm.com

2018-01-05 10:18:57 UTC

Permalink

All standard IBM IPLA licensees can be found on-line here http://www.ibm.com/software/sla/sladb.nsf/search/

The IBM Record Generator for Java v3 is Program Number 5655-CI2, so just plug that in to read the relevant license.

Note the previous JZOS Record Generator V2 was not warranted or licensed as an IBM Program Product, so the V3 productisation should resolve this issue.

Phil Wakelin, IBM Hursley UK

Kirk Wolf

2018-01-05 15:13:49 UTC

Permalink

If only we had a "friendly IBM representative" on the list :-)

The IBM JZOS Record Generator download site is actually up today (it wasn't
yesterday), so you can download it yourself:

https://www.ibm.com/support/knowledgecenter/SSMQ4D_3.0.0/documentation/welcome.html

Check with your attorney or IBM, but I am pleasantly surprised by the
license terms, which I had not read until today. My reading is that (1),
(2), and (3) are all OK subject to the terms of "Redistributables" below.

This should be a very useful tool for enterprises that want to use Java to
process records mapped by COBOL copy books or Assembler DSECTS, whether you
run the app on z/OS or on another platform. Try it out and see for
yourself.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> The doc doesn't mention it, but you can download the ADATA files to
your workstation and run the generator local to generate the Java record
mapping classes rather than running the generator of the mainframe.

======= redist.txt =================
This REDIST document is relevant to the following Program:

Program Name (Program Number/LI Number): IBM Record Generator for Java V3
(5655-CI2/L-APIG-AN3FEN)

Redistributables

All files and/or modules installed under the following directories may be
redistributed by Licensee in accordance with the provisions of the
'Redistributables' section of the Program's License Information (LI)
document number (listed above):

IBM Record Generator for Java:
- ibm-recgen.jar

Licensed users who choose to distribute any associated files assume
responsibility for the support and maintenance of such files.

========LA_en========================
....
Redistributables

If the Program includes components that are Redistributable, they will be
identified in the REDIST file that accompanies the Program. In addition to
the license rights granted in the Agreement, Licensee may distribute the
Redistributables subject to the following terms:
1) Redistribution must be in object code form only and must conform to all
directions, instruction and specifications in the Program's accompanying
REDIST or documentation;
2) If the Program's accompanying documentation expressly allows Licensee to
modify the Redistributables, such modification must conform to all
directions, instruction and specifications in that documentation and these
modifications, if any, must be treated as Redistributables;
3) Redistributables may be distributed only as part of Licensee's
application that was developed using the Program ("Licensee's Application")
and only to support Licensee's customers in connection with their use of
Licensee's Application. Licensee's Application must constitute significant
value add such that the Redistributables are not a substantial motivation
for the acquisition by end users of Licensee's software product;
4) If the Redistributables include a Java Runtime Environment, Licensee
must also include other non-Java Redistributables with Licensee's
Application, unless the Application is designed to run only on general
computer devices (for example, laptops, desktops and servers) and not on
handheld or other pervasive devices (i.e., devices that contain a
microprocessor but do not have computing as their primary purpose);
5) Licensee may not remove any copyright or notice files contained in the
Redistributables;
6) Licensee must hold IBM, its suppliers or distributors harmless from and
against any claim arising out of the use or distribution of Licensee's
Application;
7) Licensee may not use the same path name as the original Redistributable
files/modules;
8) Licensee may not use IBM's, its suppliers or distributors names or
trademarks in connection with the marketing of Licensee's Application
without IBM's or that supplier's or distributor's prior written consent;
9) IBM, its suppliers and distributors provide the Redistributables and
related documentation without obligation of support and "AS IS", WITH NO
WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTY OF
TITLE, NON-INFRINGEMENT OR NON-INTERFERENCE AND THE IMPLIED WARRANTIES AND
CONDITIONS OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE;
10) Licensee is responsible for all technical assistance for Licensee's
Application and any modifications to the Redistributables; and
11) Licensee's license agreement with the end user of Licensee's
Application must notify the end user that the Redistributables or their
modifications may not be i) used for any purpose other than to enable
Licensee's Application, ii) copied (except for backup purposes), iii)
further distributed or transferred without Licensee's Application or iv)
reverse assembled, reverse compiled, or otherwise translated except as
specifically permitted by law and without the possibility of a contractual
waiver. Furthermore, Licensee's license agreement must be at least as
protective of IBM as the terms of this Agreement.
.....
=============================

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

Edward Finnell

2018-01-05 17:42:40 UTC

Permalink

Don't know what the rules are or if they're still valid. I broached this with local branch in the nineties and the answer was 'We can only observe'. They would drop by and comment occasionally but never would reply 'on-list'.

In a message dated 1/5/2018 9:15:20 AM Central Standard Time, ***@DOVETAIL.COM writes:

If only we had a "friendly IBM representative" on the list :-)

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

Tony Harminc

2018-01-05 18:08:12 UTC

Permalink

On 5 January 2018 at 00:56, Timothy Sipples <***@sg.ibm.com> wrote:
...

Post by Timothy Sipples
I'm aware of a party that ripped a piece of OS/390 and then used it
somewhere else, without an OS/390 license, without asking IBM for
permission. IBM was not amused. :-( There was a price; it was paid. I dare
say none of our employers (or the companies we run, if applicable) would be
happy in comparable circumstances, no matter whether the product is
physical or information-based.
Basic, basic stuff here.

I'm not sure what you mean by "physical or information-based". Are you
contrasting hardware with software? Are you suggesting that IBM
hardware may not be used with non-IBM systems unless explicitly
permitted, and that the default is "no"?

I have an IBM-branded mouse that I bought many years ago for use with
my then IBM Thinkpad. Today I still use that mouse, but with an HP
laptop. Should I be concerned?

Tony H.

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

Steve Smith

2018-01-05 19:05:11 UTC

Permalink

He "suggested" you should be concerned if you stole it. No need to go
off imagining nefarious secret machinations.

sas

Post by Tony Harminc
I'm not sure what you mean by "physical or information-based". Are you
contrasting hardware with software? Are you suggesting that IBM
hardware may not be used with non-IBM systems unless explicitly
permitted, and that the default is "no"?
I have an IBM-branded mouse that I bought many years ago for use with
my then IBM Thinkpad. Today I still use that mouse, but with an HP
laptop. Should I be concerned?
Tony H.

Timothy Sipples

2018-01-05 06:45:06 UTC

Permalink

Here are the latest advisories from IBM, published/updated within the past
couple hours as I write this:

https://www.ibm.com/blogs/psirt/potential-cpu-security-issue/

https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA
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

Dana Mitchell

2018-01-05 14:17:53 UTC

Permalink

The applicable IBM zSeries Security Notice says:

Ecosystem components not affected
z Systems prior to z196
All models of Hardware Master Console (HMC)
All models of Service Element (SE)

But:
Further mitigation details for z/OS will be released as they become available.

Dana

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

Paul Gilmartin

2018-01-05 16:14:08 UTC

Permalink

Post by Timothy Sipples
Here are the latest advisories from IBM, published/updated within the past
https://www.ibm.com/blogs/psirt/potential-cpu-security-issue/

Where I read:
...
Per our business as usual process, all information for IBM Z clients can be found at the IBM Z Portal.

IBM Storage appliances are not impacted by this vulnerability.
...
This feels like the exception that proves the rule: anything not clearly mentioned
as not impacted is potentially impacted.

Post by Timothy Sipples
https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/

-- gil

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

Edward Gould

2018-01-05 18:45:11 UTC

Permalink

Post by Paul Gilmartin
...
Per our business as usual process, all information for IBM Z clients can be found at the IBM Z Portal.
IBM Storage appliances are not impacted by this vulnerability.
...
This feels like the exception that proves the rule: anything not clearly mentioned
as not impacted is potentially impacted.

https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/ <https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/>

— gil

Gill:

Thanks for re-enforcing my take on it. While I will admit I was groggy when I read it, I dropped it off the radar as I thought it was double speak taken to the nth degree.

Ed

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

AlanWatthey , GMAIL

2018-01-07 07:42:15 UTC

Permalink

Thanks to everyone for their insights and pointers on this matter. It is
obviously going to be very complicated to predict what might happen if we
increase from our current 0.3km to something like (say) 20km.

The IBM Redbook I mentioned suggests an IBM service to analyse some data
(presumably SMF) that can give some information. If that were to highlight
our particularly bad transactions it would be very useful. I suspect we
have some badly written ones that would be particularly susceptible to
longer CF response times. Does anyone know if this service still exists and
where one might find it?

I'll see if I can find the 2017 information Timothy mentioned below as this
is new to me (any pointers - here, offline or Sametime as appropriate). The
Asynchronous CF feature was mentioned in an earlier response but we will
have to upgrade our software to get there. However, that was already in the
planning.

I have no idea where the question originally came from but maybe they feel
that with the two sites so close together, if they lose one system then they
could very easily lose the other as well. This would affect our Business
Continuity (Metro Mirror). Our DR site (Global Mirror) is safe being much
further away but of course would realistically take at least an hour (on a
good day and with a following wind) to get the end users connected in to.

Regards,
Alan Watthey

-----Original Message-----
From: Timothy Sipples [mailto:***@SG.IBM.COM]
Sent: 04 January 2018 8:42 am
Subject: Re: SYSPLEX distance

Please make sure you take one recent (late 2016) innovation into
consideration: Asynchronous CF Lock Duplexing. My understanding is that
this recently introduced Coupling Facility feature offers performance
improvements in many scenarios, including some distance "stretched"
Parallel Sysplexes. IBM published some related performance test data only
last year (2017). If you're looking at older references, you might be
missing a lot.

It could be helpful to understand the motivation(s) behind the question. As
a notable example, does somebody want to create (or maintain) a
"BronzePlex" to satisfy Parallel Sysplex aggregation rules? (Those rules
are becoming less relevant now, at least, but that's a separate point.) As
another example, if the focus is on protecting and preserving data, then it
might make sense to stretch the storage but not the Sysplex.

----------------------------------------------------------------------------
----------------------------
Timothy Sipples

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

Vernooij, Kees - KLM , ITOPT1

2018-01-11 08:01:57 UTC

Permalink

If this helps:
We run a parallel sysplex with sites at 16 - 18 km (2 separate routes with some difference in distance) with active systems and CFs at both sites, without problems.
Most Sync CF Requests to the Remote CFs are converted to Async.
To minimize the Async/Remote CF delays, we configure structures over the CFs in such a way that the most busy or most important structures are in the busiest or the most important site.
We do not use System Managed Coupling Facility Structure Duplexing. All our applications are able to recover their structures well.
SMCFSD's inter-CF communication would add a number of elongated delays to each CF update request. The advantage of SMCFSD is that each site has a copy of the structure and intelligence can chose the nearest (=fastest) CF for read requests.

Kees.

Post by AlanWatthey , GMAIL
-----Original Message-----
Behalf Of Alan(GMAIL)Watthey
Sent: 07 January, 2018 8:43
Subject: Re: SYSPLEX distance
Thanks to everyone for their insights and pointers on this matter. It is
obviously going to be very complicated to predict what might happen if we
increase from our current 0.3km to something like (say) 20km.
The IBM Redbook I mentioned suggests an IBM service to analyse some data
(presumably SMF) that can give some information. If that were to highlight
our particularly bad transactions it would be very useful. I suspect we
have some badly written ones that would be particularly susceptible to
longer CF response times. Does anyone know if this service still exists and
where one might find it?
I'll see if I can find the 2017 information Timothy mentioned below as this
is new to me (any pointers - here, offline or Sametime as appropriate).
The
Asynchronous CF feature was mentioned in an earlier response but we will
have to upgrade our software to get there. However, that was already in the
planning.
I have no idea where the question originally came from but maybe they feel
that with the two sites so close together, if they lose one system then they
could very easily lose the other as well. This would affect our Business
Continuity (Metro Mirror). Our DR site (Global Mirror) is safe being much
further away but of course would realistically take at least an hour (on a
good day and with a following wind) to get the end users connected in to.
Regards,
Alan Watthey
-----Original Message-----
Sent: 04 January 2018 8:42 am
Subject: Re: SYSPLEX distance
Please make sure you take one recent (late 2016) innovation into
consideration: Asynchronous CF Lock Duplexing. My understanding is that
this recently introduced Coupling Facility feature offers performance
improvements in many scenarios, including some distance "stretched"
Parallel Sysplexes. IBM published some related performance test data only
last year (2017). If you're looking at older references, you might be
missing a lot.
It could be helpful to understand the motivation(s) behind the question. As
a notable example, does somebody want to create (or maintain) a
"BronzePlex" to satisfy Parallel Sysplex aggregation rules? (Those rules
are becoming less relevant now, at least, but that's a separate point.) As
another example, if the focus is on protecting and preserving data, then it
might make sense to stretch the storage but not the Sysplex.
------------------------------------------------------------------------
----
----------------------------
Timothy Sipples
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************

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

Jesse 1 Robinson

2018-01-07 17:11:40 UTC

Permalink

Our DR site is >100KM from our production site. In the early days of serious mirroring for DR (mid/late 90s), running a single sysplex across that distance was out of the question. It wasn't just a timing issue--although that was enough reason not to try--but network technology of the day was too flaky to run a single sysplex reliably. Connectivity is far better today, but I would not bet day-to-day production continuity on it.

I think you would find a lot of complexity in trying to run a single sysplex. In particular, how would you handle mirrored DASD? The remote sysplex member would surely have to use the same physical DASD as the local member(s). If the local glass house failed, the DASD would presumably be unusable for the remote member. You would then have to re-IPL with the mirrored copy, so there would be an outage of uncertain duration. In our case, the goal is to be up and running within four hours, which includes time for applications to recover and verify the environment. That's a lot longer than your hypothetical one hour, but even with a remote member up and running, how long would take to switch over to it?

I don't know where you're located, but we live in earthquake country where disruption can be widespread. The more you need significant separation for contingency, the less opportunity you have for running a single sysplex.

.
.
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 Alan(GMAIL)Watthey
Sent: Saturday, January 06, 2018 11:43 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: SYSPLEX distance

Thanks to everyone for their insights and pointers on this matter. It is obviously going to be very complicated to predict what might happen if we increase from our current 0.3km to something like (say) 20km.

The IBM Redbook I mentioned suggests an IBM service to analyse some data (presumably SMF) that can give some information. If that were to highlight our particularly bad transactions it would be very useful. I suspect we have some badly written ones that would be particularly susceptible to longer CF response times. Does anyone know if this service still exists and where one might find it?

I'll see if I can find the 2017 information Timothy mentioned below as this is new to me (any pointers - here, offline or Sametime as appropriate). The Asynchronous CF feature was mentioned in an earlier response but we will have to upgrade our software to get there. However, that was already in the planning.

I have no idea where the question originally came from but maybe they feel that with the two sites so close together, if they lose one system then they could very easily lose the other as well. This would affect our Business Continuity (Metro Mirror). Our DR site (Global Mirror) is safe being much further away but of course would realistically take at least an hour (on a good day and with a following wind) to get the end users connected in to.

Regards,
Alan Watthey

-----Original Message-----
From: Timothy Sipples [mailto:***@SG.IBM.COM]
Sent: 04 January 2018 8:42 am
Subject: Re: SYSPLEX distance

Please make sure you take one recent (late 2016) innovation into
consideration: Asynchronous CF Lock Duplexing. My understanding is that this recently introduced Coupling Facility feature offers performance improvements in many scenarios, including some distance "stretched"
Parallel Sysplexes. IBM published some related performance test data only last year (2017). If you're looking at older references, you might be missing a lot.

It could be helpful to understand the motivation(s) behind the question. As a notable example, does somebody want to create (or maintain) a "BronzePlex" to satisfy Parallel Sysplex aggregation rules? (Those rules are becoming less relevant now, at least, but that's a separate point.) As another example, if the focus is on protecting and preserving data, then it might make sense to stretch the storage but not the Sysplex.

----------------------------------------------------------------------------
----------------------------
Timothy Sipples

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

Rob Schramm

2018-01-10 16:07:28 UTC

Permalink

I was part of a group that ran a parallel sysplex that was 13 miles apart.
The time it takes the light to travel adds up. This was back in 2007. It
worked. It ran that way for at least a few years. It was not a GDPS
setup. I think it was EMC disk at the time.

Rob Schramm

Post by Jesse 1 Robinson
Our DR site is >100KM from our production site. In the early days of
serious mirroring for DR (mid/late 90s), running a single sysplex across
that distance was out of the question. It wasn't just a timing
issue--although that was enough reason not to try--but network technology
of the day was too flaky to run a single sysplex reliably. Connectivity is
far better today, but I would not bet day-to-day production continuity on
it.
I think you would find a lot of complexity in trying to run a single
sysplex. In particular, how would you handle mirrored DASD? The remote
sysplex member would surely have to use the same physical DASD as the local
member(s). If the local glass house failed, the DASD would presumably be
unusable for the remote member. You would then have to re-IPL with the
mirrored copy, so there would be an outage of uncertain duration. In our
case, the goal is to be up and running within four hours, which includes
time for applications to recover and verify the environment. That's a lot
longer than your hypothetical one hour, but even with a remote member up
and running, how long would take to switch over to it?
I don't know where you're located, but we live in earthquake country where
disruption can be widespread. The more you need significant separation for
contingency, the less opportunity you have for running a single sysplex.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 <(323)%20715-0595> Mobile
626-543-6132 <(626)%20543-6132> Office ⇐=== NEW
-----Original Message-----
Behalf Of Alan(GMAIL)Watthey
Sent: Saturday, January 06, 2018 11:43 PM
Subject: (External):Re: SYSPLEX distance
Thanks to everyone for their insights and pointers on this matter. It is
obviously going to be very complicated to predict what might happen if we
increase from our current 0.3km to something like (say) 20km.
The IBM Redbook I mentioned suggests an IBM service to analyse some data
(presumably SMF) that can give some information. If that were to highlight
our particularly bad transactions it would be very useful. I suspect we
have some badly written ones that would be particularly susceptible to
longer CF response times. Does anyone know if this service still exists
and where one might find it?
I'll see if I can find the 2017 information Timothy mentioned below as
this is new to me (any pointers - here, offline or Sametime as
appropriate). The Asynchronous CF feature was mentioned in an earlier
response but we will have to upgrade our software to get there. However,
that was already in the planning.
I have no idea where the question originally came from but maybe they feel
that with the two sites so close together, if they lose one system then
they could very easily lose the other as well. This would affect our
Business Continuity (Metro Mirror). Our DR site (Global Mirror) is safe
being much further away but of course would realistically take at least an
hour (on a good day and with a following wind) to get the end users
connected in to.
Regards,
Alan Watthey
-----Original Message-----
Sent: 04 January 2018 8:42 am
Subject: Re: SYSPLEX distance
Please make sure you take one recent (late 2016) innovation into
consideration: Asynchronous CF Lock Duplexing. My understanding is that
this recently introduced Coupling Facility feature offers performance
improvements in many scenarios, including some distance "stretched"
Parallel Sysplexes. IBM published some related performance test data only
last year (2017). If you're looking at older references, you might be
missing a lot.
It could be helpful to understand the motivation(s) behind the question.
As a notable example, does somebody want to create (or maintain) a
"BronzePlex" to satisfy Parallel Sysplex aggregation rules? (Those rules
are becoming less relevant now, at least, but that's a separate point.) As
another example, if the focus is on protecting and preserving data, then it
might make sense to stretch the storage but not the Sysplex.
----------------------------------------------------------------------------
----------------------------
Timothy Sipples
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

--
Rob Schramm

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

Jesse 1 Robinson

2018-01-10 17:46:21 UTC

Permalink

My reservation about running a sysplex over a network (as opposed to direct link cables) is not merely latency. We went with XRC for DR because it's asynchronous and therefore fairly tolerant of network delays. For me the real problem is that an entire extended sysplex may be at risk in case of network disconnection. In the early days for us (late 90s) we experienced fairly frequent network interruptions that caused mirroring to suspend. There was no impact on the production sysplex itself, and mirroring could be resumed with minimum effort. Losing XCF connection to a sysplex member would be a whole nother level of impact that I've never been willing to sign up for even though our network today is far more reliable than it was 20 years ago. Likewise connection to common sysplex DASD would be subject to the same level of uncertainty.

.
.
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 Rob Schramm
Sent: Wednesday, January 10, 2018 8:09 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: SYSPLEX distance

I was part of a group that ran a parallel sysplex that was 13 miles apart.
The time it takes the light to travel adds up. This was back in 2007. It
worked. It ran that way for at least a few years. It was not a GDPS setup. I think it was EMC disk at the time.

Rob Schramm

Post by Jesse 1 Robinson
Our DR site is >100KM from our production site. In the early days of
serious mirroring for DR (mid/late 90s), running a single sysplex
across that distance was out of the question. It wasn't just a timing
issue--although that was enough reason not to try--but network
technology of the day was too flaky to run a single sysplex reliably.
Connectivity is far better today, but I would not bet day-to-day
production continuity on it.
I think you would find a lot of complexity in trying to run a single
sysplex. In particular, how would you handle mirrored DASD? The remote
sysplex member would surely have to use the same physical DASD as the
local member(s). If the local glass house failed, the DASD would
presumably be unusable for the remote member. You would then have to
re-IPL with the mirrored copy, so there would be an outage of
uncertain duration. In our case, the goal is to be up and running
within four hours, which includes time for applications to recover and
verify the environment. That's a lot longer than your hypothetical one
hour, but even with a remote member up and running, how long would take to switch over to it?
I don't know where you're located, but we live in earthquake country
where disruption can be widespread. The more you need significant
separation for contingency, the less opportunity you have for running a single sysplex.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 <(323)%20715-0595> Mobile
-----Original Message-----
On Behalf Of Alan(GMAIL)Watthey
Sent: Saturday, January 06, 2018 11:43 PM
Subject: (External):Re: SYSPLEX distance
Thanks to everyone for their insights and pointers on this matter. It
is obviously going to be very complicated to predict what might happen
if we increase from our current 0.3km to something like (say) 20km.
The IBM Redbook I mentioned suggests an IBM service to analyse some
data (presumably SMF) that can give some information. If that were to
highlight our particularly bad transactions it would be very useful.
I suspect we have some badly written ones that would be particularly
susceptible to longer CF response times. Does anyone know if this
service still exists and where one might find it?
I'll see if I can find the 2017 information Timothy mentioned below as
this is new to me (any pointers - here, offline or Sametime as
appropriate). The Asynchronous CF feature was mentioned in an earlier
response but we will have to upgrade our software to get there.
However, that was already in the planning.
I have no idea where the question originally came from but maybe they
feel that with the two sites so close together, if they lose one
system then they could very easily lose the other as well. This would
affect our Business Continuity (Metro Mirror). Our DR site (Global
Mirror) is safe being much further away but of course would
realistically take at least an hour (on a good day and with a
following wind) to get the end users connected in to.
Regards,
Alan Watthey
-----Original Message-----
Sent: 04 January 2018 8:42 am
Subject: Re: SYSPLEX distance
Please make sure you take one recent (late 2016) innovation into
consideration: Asynchronous CF Lock Duplexing. My understanding is
that this recently introduced Coupling Facility feature offers
performance improvements in many scenarios, including some distance "stretched"
Parallel Sysplexes. IBM published some related performance test data
only last year (2017). If you're looking at older references, you
might be missing a lot.
It could be helpful to understand the motivation(s) behind the question.
As a notable example, does somebody want to create (or maintain) a
"BronzePlex" to satisfy Parallel Sysplex aggregation rules? (Those
rules are becoming less relevant now, at least, but that's a separate
point.) As another example, if the focus is on protecting and
preserving data, then it might make sense to stretch the storage but not the Sysplex.
----------------------------------------------------------------------
------
----------------------------
Timothy Sipples

Rob Schramm

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