IBM Unveils New IBM Z with Pervasive Encryption

Timothy Sipples

unread,

Jul 17, 2017, 12:38:04 AM7/17/17

to

IBM's press release is available here:

https://www.ibm.com/press/us/en/pressrelease/52805.wss

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sip...@sg.ibm.com

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

Timothy Sipples

unread,

Jul 17, 2017, 1:27:21 AM7/17/17

to

Timothy Sipples

unread,

Jul 17, 2017, 4:22:57 AM7/17/17

to

OK, I'll start offering some personal thoughts on today's major
announcements, and in no particular order. I'll start in what might be an
unexpected place: sub-capacity z/VM licensing. That announcement letter is
available here:

https://www.ibm.com/common/ssi/rep_ca/9/872/ENUSAP17-0259/ENUSAP17-0259.PDF

I'm quite happy with this announcement, fundamentally because it provides
you all with some interesting, useful flexibility in what you might call
the "hybrid cloud journey." IBM is now allowing sub-capacity licensing of
z/VM and of most IBM z/VM-related products and features. That's for all
operating systems that z/VM supports.

What this means in practice is that you can now configure your machine(s)
with "anchor tenant" LPARs -- LPARs running Linux, z/OS, and/or other
operating systems -- alongside z/VM LPARs. For example, let's suppose you
have z/VM and use it to run Linux guests on your machine. But, sadly, you
don't have z/VM for z/OS yet. Well, now you can license one additional
engine (CP) of z/VM and run z/OS within z/VM on that engine -- even within
a z/VM LPAR that spans CPs, zIIPs, and IFLs if you wish. So you can spin up
lots and lots of z/OS guests for development, testing, system programmer
fun, production, etc., etc. And you can do all that for not very much money
at all. In fact, it'll probably save you money since z/VM can overcommit
memory in many real world scenarios and since you can shrink (or cap) the
number of LPARs to some extent. With z/VM you don't have to "pin" system
memory as you do with LPARs. So you can do "some of all of the above": buy
lots more memory (it's a lot more affordable), allocate more memory to your
"anchor tenant" LPARs, and overcommit memory to some degree using z/VM.

For example, you might have a couple of big, beefy, analytics and database
workloads that make sense to run in LPARs. (Maybe they need a huge amount
of memory, another area where the new IBM z14 excels.) Then, for smaller
and more numerous Linux guests -- such as your developer cloud -- you have
one or a couple IFLs running z/VM. That's fine, you can do that. You have
sub-capacity licensing flexibility. You don't have to license every IFL
and/or every CP on your machine(s). Whatever makes technical sense you
should be able to do in a more financially attractive way.

To net it out, if you haven't adopted z/VM yet -- or if your adoption is
only for one operating system among the two or more than you run -- take a
serious look at licensing at least one z/VM engine (or one more engine).
It's a great deal.

More reactions to come....

Timothy Sipples

unread,

Jul 17, 2017, 6:46:46 AM7/17/17

to

I'd like to focus a bit on one of the many unique features in the new IBM
z14: "Pause-Less Garbage Collection." The IBM z14 is the first and only
server in the world with this interesting, useful capability that works to
maintain consistent, high Java performance. There's nothing else like it.
If you're at all serious about Java (and/or Java-dependent programs) and
its performance, then you need to get this new machine.

As background, Java run-time environments experience something called
"garbage collection." This blog article explains how garbage collection
works on every other server:

http://www.cubrid.org/blog/understanding-java-garbage-collection

As the article explains, when garbage collection occurs (as it must,
periodically, for any active Java run-time), it's literally a "Stop the
World" event. The entire run-time instance pauses all real work, the
garbage collection threads run to clean up, and then the real work threads
resume. As Java heap sizes grow ever larger with increasing program sizes
and information processing, "Stop the World" takes progressively longer.

If you look at a Java performance monitor on any other server running under
some amount of load, you should see a periodic "wiggle," with garbage
collection causing the wiggle. And that wiggle is a problem if you're
trying to deliver consistent performance, avoid timeouts, and otherwise
have smooth running, reliable Java servers. For example, if your mobile
user needs a query response within X milliseconds, consistently, every
time, other Java servers are likely going to have problems satisfying that
particular service level requirement. This performance problem can also
affect certain performance sensitive batch and mixed batch/online
workloads. Clustering is only a partial solution since it doesn't really
help the request that's "stuck" with a JVM that's garbage collecting. And
it's not only about Java code per se. Many programs that you don't
automatically associate with Java are, in fact, dependent on Java. And how
about high frequency trading, on Wall Street and on other major exchanges?
If that high frequency trading code has any path through a Java run-time,
that "Stop the World" garbage collection can cost a lot of money in lost
trading advantage.

As that blog article points out, developers and IT operators work very hard
(heroically, even) to try to manage around this problem as best they can.
IBM has provided excellent advice for many years, and the run-times are
very good indeed. But there was no perfect solution, especially as heap
sizes grow. Until now, with the IBM z14 and IBM Java Runtime Environments
for z/OS and for Linux on Z. With this combination you now have "Pause-Less
Garbage Collection." The wonderful IBM engineers and developers who
designed and implemented this exclusive feature take great pains to point
out that there is still a pause just before garbage collection threads do
their work, i.e. there are still some instructions that execute at that
precise moment. However, it's a very tiny, predictable, fixed pause --
much, much less of a pause. Moreover, that teeny tiny pause does not
increase in length as heap size increases, so it's future proof. The net
result is that those wobbles in your Java performance graphs either
disappear or at least become very, very hard to see -- and they remain
very, very hard to see as your Java environments grow. And that means you
really can meet or exceed the most demanding "within X milliseconds, every
time" service levels.

This stuff is completely new and unique. Pause-Less Garbage Collection uses
special new instructions in the IBM z14 processors that are available on
CPs and speciality engines (zIIPs and IFLs). These instructions, called the
"z14 Guarded Storage Facility," help support a locking mechanism that
underpins all this magic. I'm sure you'll get to read more about these
instructions in an upcoming edition of the Principles of Operation. And, as
soon as you get an IBM z14, your (and your vendors') Java and
Java-dependent code will enjoy Pause-Less Garbage Collection,
automatically. All you have to do is make sure that you have IBM's Java 1.8
at the appropriate published minimum service level, or higher. (I don't
have those precise service release level details available at this moment,
but my understanding is that you can get going from Day 1.) If you run
under z/VM then you'll also need z/VM Version 6.4 with the PTF for APAR
VM65987 to support Pause-Less Garbage Collection, planned to be available
on December 15, 2017.

More to come....

Peter Hunkeler

unread,

Jul 17, 2017, 7:15:55 AM7/17/17

to

From Timothy's post and the linked documents, I conclude that IBM re-branded its "z Systems" into "Z" (in uppercase). Will it soon be supported by a new operating system called Z/OS (don't confuse with z/OS)?

-- Peter Hunkeler

Parwez Hamid

unread,

Jul 17, 2017, 7:30:35 AM7/17/17

to

The new family name is IBM Z but the product names remain lowercase like z14, z/OS, z/VM, Linux on z Systems etc etc

Bill Wilkie

unread,

Jul 17, 2017, 8:51:41 AM7/17/17

to

I wrote to IBM years ago and complained that after downloading manuals, I had cut and paste the manual name, but could not include the "/" and it was very cumbersome. Glad to see they are changing it. I would also like to see the MANUAL number as part of the title so you can cut and paste the whole thing.

bill

________________________________
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Parwez Hamid <parwez...@HOTMAIL.COM>
Sent: Monday, July 17, 2017 11:30 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Re-branding again? Is "IBM z Systems" now "IBM Z" (watch the case)?

Tony Thigpen

unread,

Jul 17, 2017, 9:12:30 AM7/17/17

to

Tim,

I am not sure I have a good understanding of this.

Some background:

In our case, we have 7 physical z10 or higher machines. All the current
processors have 1 CPU, but we are looking at replacing 2 of the machines
with multi-processors. Most of the machines are running multiple z/OS
LPARs. A couple of machines are running z/VSE (some LPAR and some under
z/VM).

Currently, we have 2 z/VM 6.x licenses and 1 z/VM 5.4 license. (The 5.4
license is used for a small special-purpose function that did not
justify purchasing an additional 6.x license.)

I would love to have z/VM controlling more machines.

How can z/VM sub-capacity pricing help us?

Tony Thigpen

Tony Thigpen

unread,

Jul 17, 2017, 9:13:04 AM7/17/17

to

Tim,

I am not sure I have a good understanding of this.

Now, to your post. You actually hit a problem we have. We have a z/10
that is running 5 z/OS LPARs and memory allocation is not the best. You
indicate that running z/OS under VM might be the answer. But, a few
years ago, some testing made us discount z/VM for such. Maybe our
testing was faulty.

We had a customer running OS/390 (yes, that old) on a z/800. We have
since moved them to a z/10 which has worked well for over a year. During
the initial testing of OS/390 on the z/10, we thought we would need to
run it under z/VM. What we found was that simple backup processing (full
volume dumps to tape) took almost twice as long under z/VM than in a
native LPAR. A couple of posts on the z/VM list seem to tell us that
using guests (either z/OS or z/VSE) with less than 2 real CPUs would
affect I-O performance.

Maybe we misunderstood something. What are your thoughts on it?

Tony Thigpen

Timothy Sipples wrote on 07/17/2017 04:22 AM:

Phil Smith

unread,

Jul 17, 2017, 9:24:15 AM7/17/17

to

Bill Wilkie wrote:
>I wrote to IBM years ago and complained that after downloading manuals, I had cut and paste the manual name, but could not include the "/" and it was very cumbersome. Glad to see they are changing it. I would also like to see the MANUAL number as part of the title so you can cut and paste the whole thing.

No sign of a renaming of the OSes, so don't get too excited.

Peter Hunkeler wrote:
>From Timothy's post and the linked documents, I conclude that IBM re-branded its "z Systems" into "Z" (in uppercase). Will it soon be supported by a new operating system called Z/OS (don't confuse with z/OS)?

Indeed. I spotted this in this month's IBM Systems Mag, including that it's a (r), was surprised.

Guess I need to update my "z/What?<http://ourdigitalmags.com/publication/?i=318194&article_id=2525479&view=articleBrowser&ver=html5#{%22issue_id%22:318194,%22numpages%22:1,%22view%22:%22articleBrowser%22,%22article_id%22:%222525479%22}>" article already!

One thing that maybe makes sense: the former AS/400/iSeries/System i renamed itself to "IBM i" a while ago. So "IBM Z" would fit with that...other than, of course, the uppercase-ness.
--

...phsiii

R.S.

unread,

Jul 17, 2017, 9:55:23 AM7/17/17

to

I'm not marketing specialist, so just my €0.02
IMHO names like System z or System p or System i are not good. For us
it's clear what is "z", but for uneducated people it looks like typo,
just unnecessary character in the sentence.
Here in Poland people still tend to use RS/6000 (with silent slash -
just R-S-six-thousand) or AS/400 or mainframe.
Names like "gismo", "turbolaser", "HGW300" are much easier to catch-eye
or search or google, and cannot be ignored as a typo.

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2017-07-17 o 15:23, Phil Smith pisze:

> .
>

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

--
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: kon...@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.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.

Phil Smith

unread,

Jul 17, 2017, 10:06:53 AM7/17/17

to

R.S. wrote:
>I'm not marketing specialist, so just my €0.02
IMHO names like System z or System p or System i are not good. For us it's clear what is "z", but for uneducated people it looks like typo, just unnecessary character in the sentence.
Here in Poland people still tend to use RS/6000 (with silent slash - just R-S-six-thousand) or AS/400 or mainframe.
Names like "gismo", "turbolaser", "HGW300" are much easier to catch-eye or search or google, and cannot be ignored as a typo.

Absolutely. “IBM i” is quite possibly the stupidest name ever from a branding perspective, as it’s *not searchable*: when you look for it, you find “When I was at IBM, I used to…” and the like. “z Systems” and “System z” weren’t great, but were better than “IBM i”. Agreed that “IBM Z” looks sort of like a typo; “zSeries” was better, even if folks tended to get it wrong: Zseries, z-series, z/series, etc.

Branding is always hard; in the era of Google, there’s this additional difficulty of making it findable. Hence all the ostensibly stupid names like “Flickr”—those are easy to search!

R.S.

unread,

Jul 17, 2017, 10:18:26 AM7/17/17

to

Timothy,
Just to make sure I understood it:
Let's assume I have z/VM licensed for 2 processors and machine
5CP+2IFL+2ICF+2zIIP, and another machine 1CP. Before the announcement I
was able to legally run z/VM on IFLs on primary machine or on 1CP on
secondary machine (but not concurrently: primary machine ex-or another).
After the change I can define z/VM LPAR on 1CP+1IFL - is it true?
What about ICF engines?
What about zIIP engines?

Regards

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2017-07-17 o 10:22, Timothy Sipples pisze:

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

--
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: kon...@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.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.

Paul Gilmartin

unread,

Jul 17, 2017, 11:07:27 AM7/17/17

to

On 2017-07-17, at 08:03, Phil Smith wrote:
> ...

> Absolutely. “IBM i” is quite possibly the stupidest name ever from a branding perspective, as it’s *not searchable*: when you look for it, you find “When I was at IBM, I used to…” and the like. “z Systems” and “System z” weren’t great, but were better than “IBM i”. Agreed that “IBM Z” looks sort of like a typo; “zSeries” was better, even if folks tended to get it wrong: Zseries, z-series, z/series, etc.
>

"C" is a prime offender. Perhaps they'll learn; it's another case
of designers not being users (cf. KC). Even as the "uname -s" command
had to retreat to "OS/390" from "z/OS", presumably because the latter
broke existing GNU autoconfigure art.

I hope they don't conflate "zFS" with ZFS". But try searching for the former.

> Branding is always hard; in the era of Google, there’s this additional difficulty of making it findable. Hence all the ostensibly stupid names like “Flickr”—those are easy to search!

-- gil

Timothy Sipples

unread,

Jul 17, 2017, 11:24:09 AM7/17/17

to

IBM has posted its Large Systems Performance Reference (LSPR) tables for
the new IBM z14. The z/OS 2.2 tables (including for the IBM z13s and for
prior models) are available here:

https://www.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprITRzOSv2r2?OpenDocument

z/VM 6.4 ITR ratio tables are available here:

https://www.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprITRzVMv6r4?OpenDocument

And SLES 12 SP1 Linux ITR ratio tables are available here:

https://www.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprITRzLinuxSles12Sp1?OpenDocument

According to the first tables, a single IBM z14 machine running z/OS ranges
from 256 PCIs and 32 z14 MSUs (Machine Type 3906, Capacity Model 401) to
146,462 PCIs and 17,170 z14 MSUs (Capacity Model 7H0, with 170 general
purpose engines). The IBM z13 started at almost exactly the same
capacity/thoughput but reached "only" to 111,556 PCIs and 13,078 z13 MSUs.

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sip...@sg.ibm.com

Timothy Sipples

unread,

Jul 17, 2017, 12:09:24 PM7/17/17

to

Radoslaw Skorupka wrote:
>Just to make sure I understood it:
>Let's assume I have z/VM licensed for 2 processors and machine
>5CP+2IFL+2ICF+2zIIP, and another machine 1CP. Before the announcement I
>was able to legally run z/VM on IFLs on primary machine or on 1CP on
>secondary machine (but not concurrently: primary machine ex-or another).

Correct.

>After the change I can define z/VM LPAR on 1CP+1IFL - is it true?

Yes, that's right. Or you can run z/VM on one engine (CP or IFL) on the
first machine and also run z/VM on the one CP on the other machine, at the
same time. You can change your mind about which two engines. And change
your mind again. If you're licensed for two z/VM engines, you're licensed
for two engines.

If your enterprise runs z/VM on two engines, then you need 20 "Value Units"
of z/VM and any associated products. You can find the conversion table from
engines to Value Units in Value Unit Exhibit 021 (VUE021) here:

https://www.ibm.com/systems/z/resources/swprice/zipla/vue.html

As IBM's announcement letter explains, you're obliged to collect and to
retain sub-capacity usage data when you run z/VM in sub-capacity fashion,
but that's straightforward to do and shouldn't be surprising. z/VM 6.3 is
the minimum release level that supports sub-capacity licensing.

The capacity/throughput of an engine still doesn't matter for z/VM
licensing purposes. For example, if you have an IBM z13s Capacity Model
B01, that machine has one CP. If you run z/VM on that one CP, you count it
as one engine. If you have an IBM z13s Capacity Model X01, that's a higher
capacity/throughput CP. However, it's still one engine, and it's still
counted as one engine for z/VM licensing. Thus, if you have a choice (maybe
not), and if you're running z/VM on one or more CPs, you probably should
pick your "tallest" (highest capacity/throughput) CPs.

>What about ICF engines?
>What about zIIP engines?

No change. These speciality engines for z/OS didn't require additional
software licenses and still don't. You could/can freely add them to your
z/OS environment(s) (with or without z/VM) as you wish and with no software
licensing implications.

Permitted workloads do not change either. IFLs are still for Linux (and for
OpenSolaris, as a historical curiosity anyway), with or without z/VM.(*)
Other, "classic" z/VM workloads still require running z/VM on CPs, even if
z/VM is *technically* able to execute on IFLs. However, all these types of
workloads (Linux and non-Linux) can benefit from sub-capacity z/VM
licensing.

Please consult the announcement letter for the official line, but the above
is my understanding. It's all positive news.

(*) That includes workloads that run on z/VM itself, including CMS
workloads, as long as they're related to Linux. To pick an example, you can
run the IBM Directory Server (LDAP) included with z/VM, with Linux guests
connecting to that LDAP server as much as you like, all on IFLs. You just
need to make sure you have enough licenses for the IFL(s) where you run
z/VM.

Frank Swarbrick

unread,

Jul 17, 2017, 2:17:30 PM7/17/17

to

How about IBM Zed?

________________________________
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Phil Smith <ph...@VOLTAGE.COM>
Sent: Monday, July 17, 2017 8:03 AM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Re-branding again? Is "IBM z Systems" now "IBM Z" (watch the case)?

Clark Morris

unread,

Jul 17, 2017, 3:21:43 PM7/17/17

to

[Default] On 16 Jul 2017 21:36:43 -0700, in bit.listserv.ibm-main

sip...@SG.IBM.COM (Timothy Sipples) wrote:

>IBM's press release is available here:
>
>https://www.ibm.com/press/us/en/pressrelease/52805.wss
>

Ater reading the release one strong message I got was that shops
should get off JES3. It was lagging in implementation of new features
back in the late 1980s and it costs more. JES2 is now supporting JES3
JECL. Is there any reason to stay on JES3 other than the pain of
conversion?

Clark Morris

Gibney, Dave

unread,

Jul 17, 2017, 4:18:04 PM7/17/17

to

As an aside, I spent several years with a uni-processor (z800). There are significant benefits to having at least 2 processors. The benefits of fewer/faster processors go hockey stick when fewer becomes 1.

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of Tony Thigpen
> Sent: Monday, July 17, 2017 6:12 AM
> To: IBM-...@LISTSERV.UA.EDU

> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ibm.com_commo
> > n_ssi_rep-5Fca_9_872_ENUSAP17-2D0259_ENUSAP17-
> 2D0259.PDF&d=DwIC-g&c=C3
> > yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=d
> > xfnJju1NqTSbmP8qHBAUlAuSHLg2tFkipCHoSkEjGQ&s=8LL-mC1cl-
> uPvDSnsDYrEYeNB
> > wQnXXoIVb4LSeNhbi8&e=

R.S.

unread,

Jul 17, 2017, 4:41:33 PM7/17/17

to

W dniu 2017-07-17 o 22:17, Gibney, Dave pisze:

> As an aside, I spent several years with a uni-processor (z800). There are significant benefits to having at least 2 processors. The benefits of fewer/faster processors go hockey stick when fewer becomes 1.

Amen to that!
The less processors the better, but not less than two!
I was working on 9672 RA4. R16 and z800-001. Multiple LPARs, including
two productions.

--
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: kon...@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.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.

Anne & Lynn Wheeler

unread,

Jul 17, 2017, 5:20:29 PM7/17/17

to

gib...@WSU.EDU (Gibney, Dave) writes:
> As an aside, I spent several years with a uni-processor (z800). There
> are significant benefits to having at least 2 processors. The benefits
> of fewer/faster processors go hockey stick when fewer becomes 1.

I remember in the 90s when they complained NT would regularly do that
... and "fix" was at least 2 processors. I felt really smug that my vm
mainframe resource manager/scheduler would never do that ... dating back
to when I first wrote it as undergraduate in the 60s for cp67. ... some
past posts
http://www.garlic.com/~lynn/subtopic.html#fairshare

--
virtualization experience starting Jan1968, online at home since Mar1970

Edward Gould

unread,

Jul 18, 2017, 12:30:11 AM7/18/17

to

> On Jul 17, 2017, at 2:21 PM, Clark Morris <cfmp...@NS.SYMPATICO.CA> wrote:
>
> [Default] On 16 Jul 2017 21:36:43 -0700, in bit.listserv.ibm-main
> sip...@SG.IBM.COM (Timothy Sipples) wrote:
>
>> IBM's press release is available here:
>>
>> https://www.ibm.com/press/us/en/pressrelease/52805.wss
>>
>
> Ater reading the release one strong message I got was that shops
> should get off JES3. It was lagging in implementation of new features
> back in the late 1980s and it costs more. JES2 is now supporting JES3
> JECL. Is there any reason to stay on JES3 other than the pain of
> conversion?
>
> Clark Morris

Clark:

I can think of 2 JES3 shops. One went bankrupt the other is a large OIL company. They left Chicago and I don’t know where they went. One of the contributor’s here used to work for the OIL company. I met his cohort 30 years ago, when I was forced into a meeting. All I remember was his name was John. I believe they heavily modified JES3. I do not remember details as it was really long time ago. *IF* I remember correctly almost any shop that had JES3 modified it in some way. I am not talking EXITS.

Ed

Steve Horein

unread,

Jul 18, 2017, 6:53:44 AM7/18/17

to

On Mon, Jul 17, 2017 at 11:19 PM, Edward Gould <edgou...@comcast.net>
wrote:

> > On Jul 17, 2017, at 2:21 PM, Clark Morris <cfmp...@NS.SYMPATICO.CA>
> wrote:
> >
> > [Default] On 16 Jul 2017 21:36:43 -0700, in bit.listserv.ibm-main
> > sip...@SG.IBM.COM (Timothy Sipples) wrote:
> >
> >> IBM's press release is available here:
> >>
> >> https://www.ibm.com/press/us/en/pressrelease/52805.wss
> >>
> >
> > Ater reading the release one strong message I got was that shops
> > should get off JES3. It was lagging in implementation of new features
> > back in the late 1980s and it costs more. JES2 is now supporting JES3
> > JECL. Is there any reason to stay on JES3 other than the pain of
> > conversion?
> >
> > Clark Morris
>
> Clark:
>
> I can think of 2 JES3 shops. One went bankrupt the other is a large OIL
> company. They left Chicago and I don’t know where they went. One of the
> contributor’s here used to work for the OIL company. I met his cohort 30
> years ago, when I was forced into a meeting. All I remember was his name
> was John. I believe they heavily modified JES3. I do not remember details
> as it was really long time ago. *IF* I remember correctly almost any shop
> that had JES3 modified it in some way. I am not talking EXITS.
>
> Ed
>
>

I know of at least 4, one of which I currently work for.
I don't directly support the product, but work with putting automation
around it, so I don't know details or scope of how modified it is.
My impression is that it's not heavily modified. I don't necessarily look
forward to conversion, but if there is (eventually) no choice...

Dyck, Lionel B. , TRA

unread,

Jul 18, 2017, 7:12:52 AM7/18/17

to

I would be interested in how IBM intends to support High Watermark Setup (HWS) for Tape - is it their intention to sell more tape drives (real or virtual)? The JES2 implementation of dependent job control (DJC) uses a very different set of control statements than what JES3 has had for decades so I don't see an easy migration for shops with DJC either. Disk readers I can see moving into an automation product. And there are other significant differences which IBM is demonstrating they could give a #@$&! about which all are used to make the JES3 customer productive on the IBM platform.

Just my $0.02 and do not reflect the opinions of my employer or management

--------------------------------------------------------------------------
Lionel B. Dyck