Re: Introducing the New z13s: Tim's Hardware Highlights

[Anne & Lynn Wheeler]

edgould1...@comcast.net (Ed Gould) writes:
> Remember the *OLD* days there was a 16MB max on (even) an MP? Never
> mind the cost of $10K per meg (if memory serves me on a 168).
> Yes the newer machines have more memory but in reality you really
> don't get all that more functionality, and yes there are bells and
> whistles for the z genation.

Significant MVS bloat by 3033 was causing a number of problems ... real
storage requirements was banging hard at the 16mbyte limit. 16bit 370
PTE was 12bit (4kbyte) page number, 2defined bits and 2undefined/unused.
They took 2undefined/unused bits then used them to prefix the (real)
page number ... allowing 14bit page number or up to 64mbytes of real
pages ... allowing lots of application virtual pages to reside above the
16mbyte line.

os/360 significant pointer passing API paradigm was making 16mbyte
virtual address space limit a problem. Transition from SVS to MVS gave
each application its own 16mbyte virtual address space ... but pointer
passing API paradigm required 8mbyte image of the MVS kernel in each
application virtual address space. Then because subsystems services were
in their own virtual address space, pointer passing API required 1mbyte
CSA (in each virtual address space) for passing parameters. CSA size
requirements were proportional to subsystems and applications ... for
large 3033s was 5-6mbytes and threatening to become 8mbytes (leaving
none for applications). Subset of "access registers" was then
retrofitted to 3033 as dual-address mode (allowing subsystems to access
application virtual address space w/o needing CSA).

problem was that 4341 clusters had more processing power than 3033, more
aggregate memory and I/O throughput, much lower cost and significantly
less physical and environmental footprint. Folklore is that head of POK
felt so threatened that corporate was convinced to cut allocation of
critical 4341 manufacturing component in half.

4341 had significant improvement price/performance as well as physical
and environmental footprint resulted in corporations ordering hundreds
at a time for placing out in departmental areas ... sort of the leading
edge of distributed computing tsunami.

Before 4341s shipped, I got roped into benchmarking engineering 4341 for
national labs for big compute farm ... sort of the leading edge of the
coming supercomputer paradigm 

internet+distributed computing+compute farms ... evolves into cloud with
hundreds of thousands of systems and millions of processors in each
cloud megadatacenter (system costs have dropped to such a level
that power are starting to dominate cloud costs).

old email about air force data systems coming out to talk about 20
4341s, spring of 1979 (they had a few mainframes in their datacenter),
but by the time they got around to caming out fall of 1979, it had
jumped to 210 4341s.
http://www.garlic.com/~lynn/2001m.html#email790404
and
http://www.garlic.com/~lynn/2001m.html#email790404b

other 4341 related email
http://www.garlic.com/~lynn/lhwemail.html#4341

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

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[David L. Craig]

On 16Feb24:2100-0500, zMan wrote:
> 
> I remember $1/byte back in the 360 era. Amazing times.

Even more amazing: according to the https://www.minneapolisfed.org/
inflation calculator, that equates to about $7/byte in today's
dollar's purchasing power.
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Ted MacNEIL]

Those Christmas/Birthday cards that 'sing' when you open them contain, 
individually, more computing power than was on the face of the planet in 1950.

-teD
  Original Message  
From: zMan
Sent: Wednesday, February 24, 2016 21:00
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Introducing the New z13s: Tim's Hardware Highlights

Ed Gould wrote:
>Remember the *OLD* days there was a 16MB max on (even) an MP? Never mind
the cost of $10K per meg (if memory serves me on a 168).

Maybe at the end of the 370 era. Per http://www.jcmit.com/memoryprice.htm
it wasn't until 1979 or so that it got that cheap.

I remember $1/byte back in the 360 era. Amazing times. I've often noted
that my cellphone contains more memory than *existed on the planet* for
most of my career. Blows my ever lovin' mind!

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

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[zMan]

Ed Gould wrote:
>Remember the *OLD* days there was a 16MB max on (even) an MP? Never mind
the cost of $10K per meg (if memory serves me on a 168).

Maybe at the end of the 370 era. Per http://www.jcmit.com/memoryprice.htm
it wasn't until 1979 or so that it got that cheap.

I remember $1/byte back in the 360 era. Amazing times. I've often noted
that my cellphone contains more memory than *existed on the planet* for
most of my career. Blows my ever lovin' mind!

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Clark Morris]

On 23 Feb 2016 20:46:21 -0800, in bit.listserv.ibm-main you wrote:

>Ed Gould wrote:
>>Seriously the issue is absence of debugging tools to find the leak
>>seems like it would be simpler to have them.
>
>Who said they didn't? They had quite excellent problem determination tools
>(plural).
>
>Keep in mind the mission-critical application was in production. Neither
>planned nor unplanned downtime was/is tolerable. They had to keep the
>business service available while troubleshooting and then fixing the
>problem. They did, and the platform made possible their Apollo 13-like
>triumph. Failure would have been quite expensive.
>
>Clark Morris wrote:
>>The joy can be understanding why the bug, fixing it so that you don't
>>cause the application equivalent of the PE chain, running all the
>>tests and then going through change management. Setting up the
>>appropriate tests alone can be time consuming.
>
>Quite correct, I agree.
>
>Radoslaw Skorupka wrote:
>>Price is also a problem
>
>Yes, I suppose the price of the levee that would have saved New Orleans was
>"a problem." The price of Hurricane Katrina was much higher.
>
>Even so, I assume you'll be pleased IBM has majorly reduced the price of
>memory, even while it's the only memory in the industry with RAIM
>protections, to pick one among several unique characteristics. Enjoy.
>
>It's *always* about value for money, whether mainframes or moon rockets.
>This isn't a complicated concept. Now raise your hand if you want the
>lowest priced heart surgeon, operating room, and artificial valve. :-)

It depends.  What makes the more expensive ones worth the money and do
I need those things in my case?  

Clark Morris
>
>
>Timothy Sipples
>IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
>E-Mail: sipp...@sg.ibm.com
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Timothy Sipples]

Ed Gould wrote:
>Seriously the issue is absence of debugging tools to find the leak
>seems like it would be simpler to have them.

Who said they didn't? They had quite excellent problem determination tools
(plural).

Keep in mind the mission-critical application was in production. Neither
planned nor unplanned downtime was/is tolerable. They had to keep the
business service available while troubleshooting and then fixing the
problem. They did, and the platform made possible their Apollo 13-like
triumph. Failure would have been quite expensive.

Clark Morris wrote:
>The joy can be understanding why the bug, fixing it so that you don't
>cause the application equivalent of the PE chain, running all the
>tests and then going through change management. Setting up the
>appropriate tests alone can be time consuming.

Quite correct, I agree.

Radoslaw Skorupka wrote:
>Price is also a problem

Yes, I suppose the price of the levee that would have saved New Orleans was
"a problem." The price of Hurricane Katrina was much higher.

Even so, I assume you'll be pleased IBM has majorly reduced the price of
memory, even while it's the only memory in the industry with RAIM
protections, to pick one among several unique characteristics. Enjoy.

It's *always* about value for money, whether mainframes or moon rockets.
This isn't a complicated concept. Now raise your hand if you want the
lowest priced heart surgeon, operating room, and artificial valve. :-)


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

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Ed Gould]

On Feb 22, 2016, at 2:05 PM, R.S. wrote:


W dniu 2016-02-18 o 10:30, Timothy Sipples pisze:


- 
SNIP

memory than the biggest available mainframe did
until 2015.
Well, it was a *shame* for mainframe. Both: memory limit and the  
price of memory.
At the time you mention PC server vendors (including IBM system x)  
offered configurations up to 12TB of memory (non-RAIM protected). 4  
times more!. I haven't checked current p/Series aka System p  
limits, but it was always higher than for mainframe, at least from  
the times of z990.
So, during the years mainframe was the platform with the *lowest*  
memory limit ...and it stiil is, even z13 (without "s"). And I do  
not have to update  information about PC servers, because those  
outdated machines had more than mainframe today.
Price is also a problem - price of GB was always the higher among  
the plaftorms (some exceptions could be possible). Not to mention  
it can be purchased from different vendors.


So, if your workload need big memory choose... yes, I have big  
problem to justify such workload on mainframe.


-- -- 
SNIP---


Remember the *OLD* days there was a 16MB max on (even) an MP? Never  
mind the cost of $10K per meg (if memory serves me on a 168).
Yes the newer machines have more memory but in reality you really  
don't get all that more functionality, and yes there are bells and  
whistles for the z genation.

There are still so many limitations on Z/os that one wonders why?

Ed

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[R.S.]

W dniu 2016-02-18 o 10:30, Timothy Sipples pisze:

1. Memory! [...]
Just to underscore how revolutionary 4 TB of main memory is in the z13s,
the zEC12 -- the largest model mainframe introduced in 2012 -- supported
"only" 3 TB of main memory. This supposed "mid-range" z13s mainframe
supports 33% more main memory than the biggest available mainframe did
until 2015.
Well, it was a *shame* for mainframe. Both: memory limit and the price 
of memory.
At the time you mention PC server vendors (including IBM system x) 
offered configurations up to 12TB of memory (non-RAIM protected). 4 
times more!. I haven't checked current p/Series aka System p limits, but 
it was always higher than for mainframe, at least from the times of z990.
So, during the years mainframe was the platform with the *lowest* memory 
limit ...and it stiil is, even z13 (without "s"). And I do not have to 
update  information about PC servers, because those outdated machines 
had more than mainframe today.
Price is also a problem - price of GB was always the higher among the 
plaftorms (some exceptions could be possible). Not to mention it can be 
purchased from different vendors.


So, if your workload need big memory choose... yes, I have big problem 
to justify such workload on mainframe.


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc 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: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Clark Morris]

On 22 Feb 2016 10:14:18 -0800, in bit.listserv.ibm-main you wrote:

>All for the cost of a new Mainframe?
>Seriously the issue is absence of debugging tools to find the leak  
>seems like it would be simpler to have them.

The joy can be understanding why the bug, fixing it so that you don't
cause the application equivalent of the PE chain, running all the
tests and then going through change management.  Setting up the
appropriate tests alone can be time consuming.

Clark Morris
>
>Ed
>
>On Feb 22, 2016, at 2:40 AM, Timothy Sipples wrote:
>
>> For the record, the memory leak in the specific situation I  
>> described was
>> due to a customer's in-house written application code. That's what  
>> I wrote
>> originally, but I'd like to repeat that point since there seems to  
>> be some
>> misunderstanding.
>>
>> I think it's a fantastic story, one of the hallmark aspects of  
>> mainframe
>> computing: its greater tolerance for human errors while still  
>> delivering
>> perfect service outcomes. It's really the only way to deliver  
>> extremely
>> high SLAs. You must anticipate myriad human errors for they are  
>> reality.
>> Aircraft safety engineering shares that same basic principle, to pick
>> another example.
>>
>> -- 
>> --
>> Timothy Sipples
>> IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
>> E-Mail: sipp...@sg.ibm.com
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Ed Gould]

All for the cost of a new Mainframe?
Seriously the issue is absence of debugging tools to find the leak  
seems like it would be simpler to have them.


Ed

On Feb 22, 2016, at 2:40 AM, Timothy Sipples wrote:

For the record, the memory leak in the specific situation I  
described was
due to a customer's in-house written application code. That's what  
I wrote
originally, but I'd like to repeat that point since there seems to  
be some

misunderstanding.

I think it's a fantastic story, one of the hallmark aspects of  
mainframe
computing: its greater tolerance for human errors while still  
delivering
perfect service outcomes. It's really the only way to deliver  
extremely
high SLAs. You must anticipate myriad human errors for they are  
reality.

Aircraft safety engineering shares that same basic principle, to pick
another example.

-- 
--

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

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


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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Timothy Sipples]

For the record, the memory leak in the specific situation I described was
due to a customer's in-house written application code. That's what I wrote
originally, but I'd like to repeat that point since there seems to be some
misunderstanding.

I think it's a fantastic story, one of the hallmark aspects of mainframe
computing: its greater tolerance for human errors while still delivering
perfect service outcomes. It's really the only way to deliver extremely
high SLAs. You must anticipate myriad human errors for they are reality.
Aircraft safety engineering shares that same basic principle, to pick
another example.


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

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Rob Schramm]

Never meant to suggest that going backwards was the direction I desired.
Simply stating that having a few weird features can be a good thing when
struck with a production issue, service level agreements and (insert "other
institution specific intractable" here).

Ideally, it would be great to have programmers never introduce a problem
that isn't easy to fix.  It would also be nice if IBM didn't "toss a
grenade into the water" on occasion.

Rob Schramm

On Sat, Feb 20, 2016, 5:11 PM Ed Gould  wrote:

> On Feb 20, 2016, at 11:25 AM, Rob Schramm wrote:
>
> > But isn't it the point?  We would all prefer to live in a world
> > where bad
> > coding doesn't happen.  I would venture a guess that most have been
> > in a
> > situation that called for a bad temporary solution until a fix
> > could be
> > found.  In which case the expertise of the system programmer comes
> > into
> > play and says "while I wouldn't recommend running in this
> > configuration for
> > long, we can do X to keep things going in production.". Even with
> > some of
> > the functions that seem outlandish (highly dependent on your point of
> > view), there is at least one person on IBM-Main that has had to use it
> > either because of inherent design constraints or to get thru a bad
> > situation.  One more " trick " to add to the sysprogs bag-of-tricks.
> >
> > As for the name.. They should have called it a z131z and made a
> > palindrome.  Agreed that z13ses is just bad.  But we should agree to
> > something... since it is here to stay.
> >
> > Rob Schramm
>
> Rob:
> I think that we pay IBM the big bucks  to produce code that is
> reliable (IBM blew it with DFP in the early stages) so the mega ptf
> tapes more or less disappeared because the customers were complaining
> at both GUIDE and SHARE about it and IBM finally started to put their
> act together . There was *NEVER* talk about upgrading the processor
> just so IBM could do it correctly. *IF* IBM would have taken that
> position I think some other vendor would have finally got their toe
> hold in the ground. IBM got their act together and the mega PTF tapes
> disappeared. So you want to go back to the "good" old days and with
> mega PTF's ? I for one don't want to.
>
> BTW I am still pissed at IBM treatment of JAVA and their total
> replacement of the product instead of just putting out fixes for one
> or two  (or even) three csects.
>
> Ed
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm
The Art of Mainframe, Inc

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Ed Gould]

On Feb 20, 2016, at 11:25 AM, Rob Schramm wrote:

But isn't it the point?  We would all prefer to live in a world  
where bad
coding doesn't happen.  I would venture a guess that most have been  
in a
situation that called for a bad temporary solution until a fix  
could be
found.  In which case the expertise of the system programmer comes  
into
play and says "while I wouldn't recommend running in this  
configuration for
long, we can do X to keep things going in production.". Even with  
some of

the functions that seem outlandish (highly dependent on your point of
view), there is at least one person on IBM-Main that has had to use it
either because of inherent design constraints or to get thru a bad
situation.  One more " trick " to add to the sysprogs bag-of-tricks.

As for the name.. They should have called it a z131z and made a
palindrome.  Agreed that z13ses is just bad.  But we should agree to
something... since it is here to stay.

Rob Schramm


Rob:
I think that we pay IBM the big bucks  to produce code that is  
reliable (IBM blew it with DFP in the early stages) so the mega ptf  
tapes more or less disappeared because the customers were complaining  
at both GUIDE and SHARE about it and IBM finally started to put their  
act together . There was *NEVER* talk about upgrading the processor  
just so IBM could do it correctly. *IF* IBM would have taken that  
position I think some other vendor would have finally got their toe  
hold in the ground. IBM got their act together and the mega PTF tapes  
disappeared. So you want to go back to the "good" old days and with  
mega PTF's ? I for one don't want to.


BTW I am still pissed at IBM treatment of JAVA and their total  
replacement of the product instead of just putting out fixes for one  
or two  (or even) three csects.


Ed

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Rob Schramm]

But isn't it the point?  We would all prefer to live in a world where bad
coding doesn't happen.  I would venture a guess that most have been in a
situation that called for a bad temporary solution until a fix could be
found.  In which case the expertise of the system programmer comes into
play and says "while I wouldn't recommend running in this configuration for
long, we can do X to keep things going in production.". Even with some of
the functions that seem outlandish (highly dependent on your point of
view), there is at least one person on IBM-Main that has had to use it
either because of inherent design constraints or to get thru a bad
situation.  One more " trick " to add to the sysprogs bag-of-tricks.

As for the name.. They should have called it a z131z and made a
palindrome.  Agreed that z13ses is just bad.  But we should agree to
something... since it is here to stay.

Rob Schramm

On Fri, Feb 19, 2016, 11:30 PM Ed Gould  wrote:

> On Feb 19, 2016, at 6:09 PM, Clark Morris wrote:
> >> -
> >> SNIP-
> >> -
> >
> > Ed, they did fix the bug but it took several weeks to do it.  With
> > memory they were able to stay afloat while the repair was being done.
> >
> > Clark Morris
>
> Its great that they did however selling a machine based a code bug
> (as Timothy seems to try to do all to often on here) is bad for IBM
> and bad for us.
>
> Ed
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm
The Art of Mainframe, Inc

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Ed Gould]

On Feb 19, 2016, at 6:09 PM, Clark Morris wrote:
- 
SNIP- 
-


Ed, they did fix the bug but it took several weeks to do it.  With
memory they were able to stay afloat while the repair was being done.

Clark Morris


Its great that they did however selling a machine based a code bug  
(as Timothy seems to try to do all to often on here) is bad for IBM  
and bad for us.


Ed

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Clark Morris]

On 19 Feb 2016 12:27:09 -0800, in bit.listserv.ibm-main you wrote:

>On Feb 19, 2016, at 12:15 AM, Timothy Sipples wrote:
>
>> Andrew Rowley wrote:
>>> I will make the same comment I made last time this topic came up -
>>> avoiding garbage collection is not usually a wise goal.
>>
>> It depends on the workload(s). The point I made is that with the  
>> z13 and
>> z13s you have more such options, when/as they make sense.
>>
>> To pick an example, I recall dealing with a Java workload that had an
>> unresolved memory leak. Such is life sometimes. Nobody is perfect,  
>> and one
>> should plan for human fallibility. The application development team  
>> did a
>> superb job to resolve the problem, eventually successfully, but it  
>> took
>> several weeks to nail it down and get the fix tested and into  
>> production.
>> In the meantime, on the production side, the operators ran the
>> mission-critical application in a minimum of two servants, with HTTP
>> session persistence and big heaps (lots of memory) to keep them  
>> afloat for
>> as long as possible ("hours"). Then, even with the unresolved leak,  
>> they
>> could maintain continuous service for their users. Much like the  
>> coach of a
>> basketball team, they "benched" each player (servant) on a  
>> scheduled basis
>> before the player got exhausted (couldn't garbage collect). They  
>> decided
>> when the best times were to recycle opportunistically. This heroic
>> production operator save meant that end users didn't have any service
>> interruptions. They had no idea there was an ongoing, nail biting  
>> drama --
>> everything ran smoothly. That's just one example among many of the
>> advantages of having lots of memory or at least a bit more than  
>> "enough."
>> In their case throwing some more memory at the problem literally  
>> meant not
>> busting their Service Level Agreement (SLA) on an extremely important
>> application.
>>
>> My hats off to those teams. Bravo, disaster well averted.
>
>Sorry Timothy. An unresolved memory leak is bad no matter what and  
>buying a bigger machine for bad coding. Its not cost effective in any  
>sense of the word.
>Fix the damn BUG! Get the team to fix their code and stop patting  
>them on the back as obviously they still have issues.

Ed, they did fix the bug but it took several weeks to do it.  With
memory they were able to stay afloat while the repair was being done.

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

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Ed Gould]

On Feb 19, 2016, at 12:15 AM, Timothy Sipples wrote:


Andrew Rowley wrote:

I will make the same comment I made last time this topic came up -
avoiding garbage collection is not usually a wise goal.


It depends on the workload(s). The point I made is that with the  
z13 and

z13s you have more such options, when/as they make sense.

To pick an example, I recall dealing with a Java workload that had an
unresolved memory leak. Such is life sometimes. Nobody is perfect,  
and one
should plan for human fallibility. The application development team  
did a
superb job to resolve the problem, eventually successfully, but it  
took
several weeks to nail it down and get the fix tested and into  
production.

In the meantime, on the production side, the operators ran the
mission-critical application in a minimum of two servants, with HTTP
session persistence and big heaps (lots of memory) to keep them  
afloat for
as long as possible ("hours"). Then, even with the unresolved leak,  
they
could maintain continuous service for their users. Much like the  
coach of a
basketball team, they "benched" each player (servant) on a  
scheduled basis
before the player got exhausted (couldn't garbage collect). They  
decided

when the best times were to recycle opportunistically. This heroic
production operator save meant that end users didn't have any service
interruptions. They had no idea there was an ongoing, nail biting  
drama --

everything ran smoothly. That's just one example among many of the
advantages of having lots of memory or at least a bit more than  
"enough."
In their case throwing some more memory at the problem literally  
meant not

busting their Service Level Agreement (SLA) on an extremely important
application.

My hats off to those teams. Bravo, disaster well averted.


Sorry Timothy. An unresolved memory leak is bad no matter what and  
buying a bigger machine for bad coding. Its not cost effective in any  
sense of the word.
Fix the damn BUG! Get the team to fix their code and stop patting  
them on the back as obviously they still have issues.


Ed

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Tony Harminc]

On 18 February 2016 at 18:50, Mark Post  wrote:
>> Just a comment, the name z13s did not appear to me to be a name of a new
>> system, but rather just the plural of z13, i.e. "Look at those z13s run!".
>> Took me a while to figure out this was in fact a new name and a new offering.
>>
>> Perhaps I'm the only one...
>
> I don't think any marketeer has ever been accused of being "too smart."

The naming problem goes back to the first z Series machine. In the USA
it was the eServer ZEE Series 900, and in the rest of the world the
ZED Series. Surely even the thickest US marketeer was aware of the
uniquely US pronunciation of the letter z. Well, maybe not...

Tony H.

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Dana Mitchell]

2965 or  2965s? 


On Thu, 18 Feb 2016 20:57:57 -0500, Ken Smith  wrote:

>Maybe right:
>
>z13 is a single z13
>z13's is more than one z13
>z13s is a single z13s
>z13s' is more than one z13s
>z13* or z13x is one or more z13*'s or z13x's
>
>where x or * is any char including null
>

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Mike Schwab]

Type then correct.  Sometimes settings don't stick unless there is
existing text having the attributes.

On Fri, Feb 19, 2016 at 2:56 AM, Martin Packer <martin_pac...@uk.ibm.com> wrote:
> And if you think that's bad try making your favourite slide or email
> editor keep the "z" lower case. Permanent nightmare. :-)
>
> Cheers, Martin
>
> Martin Packer,
> zChampion, Principal Systems Investigator,
> Worldwide Cloud & Systems Performance, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>
>
>
> From:   "Joel C. Ewing" <jcew...@acm.org>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   19/02/2016 02:33
> Subject:Re: Introducing the New z13s: Tim's Hardware Highlights
> Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
>
>
> The recognized punctuation rules are no longer black and white where z13
> and z13s are involved.  The rule of always using an apostrophe for
> plurals of "non-words" is no longer universal:
>
> One rule is apostrophe "s" is used for plural for "words" that are not
> normally a noun; but z13 in our context is normally a noun, so by that
> standard the plural could be just z13s.
>
> When multi-digit numbers are made into a plural, it is now acceptable to
> use just "s" for plural, as in both 1990's and 1990s being in common use
> for multiple years in that decade -- again by that standard, z13s could
> be a plural of z13.
>
> And of course, if you want a possessive form, like "the z13's frame",
> then the apostrophe is required, which is very confusing if you also
> demand the apostrophe for a plural.
>
> All in all, "z13s" as a distinct machine type introduces ambiguity that
> could easily have been avoided.  It was not an astute choice.
> Joel C. Ewing
>
> On 02/18/2016 07:57 PM, Ken Smith wrote:
>> Maybe right:
>>
>> z13 is a single z13
>> z13's is more than one z13
>> z13s is a single z13s
>> z13s' is more than one z13s
>> z13* or z13x is one or more z13*'s or z13x's
>>
>> where x or * is any char including null
>>
>> Ken
>>
>> On Thu, Feb 18, 2016 at 7:50 PM, Ed Gould <edgould1...@comcast.net>
> wrote:
>>
>>> On Feb 18, 2016, at 3:30 AM, Timothy Sipples wrote:
>>>
> -SNIP-
>>>
>>>> 4. IBM has greatly relaxed the data center environmental requirements
> for
>>>> this model, expanding the temperature and humidity envelopes. It's
> much
>>>> more realistic now to install the z13s in nontraditional data centers,
> or
>>>> even places that aren't really data centers. Platforms that move, for
>>>> example, or out in remote facilities. (In technobabble it's an ASHRAE
>>>> class
>>>> A3 system now instead of class A2.)
>>>>
>>>
>>> SNIP---
>>> Timothy,
>>>
>>> Thanks for the update
>>> -WAR STORY TIME
>>> I worked at one place that used a ware house type environment to do DR.
>>> That is they bought a new machine in their DC and disassembled the old
>>> machine and put it in the ware house.
>>> Some how they expected the old machine could do DR. Periodically they
>>> would send a sysprog off to the DR site to power up and run a few job.
>>> The sysprog was fairly good he could use a screwdriver like no other
>>> sysprog and could basically get the machine up and limping to do those
> few
>>> jobs.
>>> That is until they bought a new machine that couldn't IPL the latest
> and
>>> greatest MVS. Also DB2 wouldn't even work.
>>> They ordered the new machine with their heads in the clouds as they
> were
>>> so cheap they didn't even want to pay for the latest COBOL.
>>> They screamed and moaned about having to put out a few dollars a month
> for
>>> COBOL and LE.
>>> When reminded that the old COBOL was Y2K compliant that pretty well
> shut
>>> them up.
>>> I was never so happy to leave place everything that cost $$ was met
> with a
>>> NO.
>>> They were also unhappy that their homegrown security system would not
> work
>>> anymore and they had to go to RACF.
>>> IDIOTS they got what they deserved.
>>>
>>> Ed
>>>
>

Re: Introducing the New z13s: Tim's Hardware Highlights

[Scott Chapman]

On Fri, 19 Feb 2016 18:16:53 +1100, Andrew Rowley 
 wrote:

>Memory leaks are not a usual case, but I would suggest you will still
>want to garbage collect.
>
>I'm not arguing against large memory - I am all in favour of as much as
>you can afford. It's just the suggestion that avoiding Java GC is a good
>idea.
>
>I believe that Java is one of the keys to the future of z/OS.
>Suggestions like "allocate enough memory that you don't have to GC"
>contribute to the view that Java is a memory hog and performs poorly.
>That is damaging to Java on z/OS and as a result damaging to z/OS as a
>whole.

I agree--and echo Martin's point make sure that GC isn't getting in your way 
and echo your point that small working sets can be advantageous. 

But I'm also for loosening up IEFUSI limits. If somebody is trying to force all 
of their Java batch to run in 32MB heaps, well... my guess would be that 
loosening that up to 64-128MB could make a significant change. And when you 
have 64GB, you have lots of room to run a lot of Java batch with 128MB heaps. 
Unfortunately it's not possible to predict optimal heap requirements: you have 
to actually test. But my recommendation (for batch) is give 'em 128MB to start 
and only investigate in detail if you really need to. I would not be in favor 
of starting every Java batch job off at a GB or more of heap--my guess is that 
I could put that memory to better use as DB2 buffer pools or something like 
that. 

I'm also all for Java on z/OS. Just make sure you have a zIIP (or preferably 
more) to support it.

Scott

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Scott Chapman]

On Fri, 19 Feb 2016 08:56:17 +, Martin Packer  
wrote:

>And if you think that's bad try making your favourite slide or email
>editor keep the "z" lower case. Permanent nightmare. :-)

Amen. But the Ctrl-z every time after you type it reinforces what platform 
you're writing about. :)

Scott

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[David L. Craig]

On 16Feb19:0411-0500, Aled Hughes wrote:

> Just to be the awkward one here: the use of 's for
> plural is grammatically incorrect, personally I don't
> care if it is universally accepted - it is wrong and
> should be avoided. It is on a par with the misuse
> of examples such as 'their' when meaning 'there'
> and 'here, here' when 'hear, hear' is meant. I know
> language evolves, but grammar does not.
> 
> We need Mr Gilmore here! 

He might point out the general rule for pluralizing words that
end in "s" is to append "es"; e.g, boss -> bosses.
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Aled Hughes]

Just to be the awkward one here: the use of 's for plural is grammatically 
incorrect, personally I don't care if it is universally accepted - it is wrong 
and should be avoided. It is on a par with the misuse of examples such as 
'their' when meaning 'there' and 'here, here' when 'hear, hear' is meant. I 
know language evolves, but grammar does not. 


We need Mr Gilmore here! 






-Original Message-
From: Joel C. Ewing <jcew...@acm.org>
To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU>
Sent: Fri, 19 Feb 2016 2:33
Subject: Re: Introducing the New z13s: Tim's Hardware Highlights

The recognized punctuation rules are no longer black and white where z13
and z13s are involved.  The rule of always using an apostrophe for
plurals of "non-words" is no longer universal:

One rule is apostrophe "s" is used for plural for "words" that are not
normally a noun; but z13 in our context is normally a noun, so by that
standard the plural could be just z13s.

When multi-digit numbers are made into a plural, it is now acceptable to
use just "s" for plural, as in both 1990's and 1990s being in common use
for multiple years in that decade -- again by that standard, z13s could
be a plural of z13.

And of course, if you want a possessive form, like "the z13's frame",
then the apostrophe is required, which is very confusing if you also
demand the apostrophe for a plural.

All in all, "z13s" as a distinct machine type introduces ambiguity that
could easily have been avoided.  It was not an astute choice.
Joel C. Ewing
 
On 02/18/2016 07:57 PM, Ken Smith wrote:
> Maybe right:
>
> z13 is a single z13
> z13's is more than one z13
> z13s is a single z13s
> z13s' is more than one z13s
> z13* or z13x is one or more z13*'s or z13x's
>
> where x or * is any char including null
>
> Ken
>
> On Thu, Feb 18, 2016 at 7:50 PM, Ed Gould <edgould1...@comcast.net> wrote:
>
>> On Feb 18, 2016, at 3:30 AM, Timothy Sipples wrote:
>> -SNIP-
>>
>>> 4. IBM has greatly relaxed the data center environmental requirements for
>>> this model, expanding the temperature and humidity envelopes. It's much
>>> more realistic now to install the z13s in nontraditional data centers, or
>>> even places that aren't really data centers. Platforms that move, for
>>> example, or out in remote facilities. (In technobabble it's an ASHRAE
>>> class
>>> A3 system now instead of class A2.)
>>>
>>
>> SNIP---
>> Timothy,
>>
>> Thanks for the update
>> -WAR STORY TIME
>> I worked at one place that used a ware house type environment to do DR.
>> That is they bought a new machine in their DC and disassembled the old
>> machine and put it in the ware house.
>> Some how they expected the old machine could do DR. Periodically they
>> would send a sysprog off to the DR site to power up and run a few job.
>> The sysprog was fairly good he could use a screwdriver like no other
>> sysprog and could basically get the machine up and limping to do those few
>> jobs.
>> That is until they bought a new machine that couldn't IPL the latest and
>> greatest MVS. Also DB2 wouldn't even work.
>> They ordered the new machine with their heads in the clouds as they were
>> so cheap they didn't even want to pay for the latest COBOL.
>> They screamed and moaned about having to put out a few dollars a month for
>> COBOL and LE.
>> When reminded that the old COBOL was Y2K compliant that pretty well shut
>> them up.
>> I was never so happy to leave place everything that cost $$ was met with a
>> NO.
>> They were also unhappy that their homegrown security system would not work
>> anymore and they had to go to RACF.
>> IDIOTS they got what they deserved.
>>
>> Ed
>>
>> ...


-- 
Joel C. Ewing,Bentonville, AR jcew...@acm.org   

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



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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Martin Packer]

And if you think that's bad try making your favourite slide or email 
editor keep the "z" lower case. Permanent nightmare. :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   "Joel C. Ewing" <jcew...@acm.org>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   19/02/2016 02:33
Subject:    Re: Introducing the New z13s: Tim's Hardware Highlights
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



The recognized punctuation rules are no longer black and white where z13
and z13s are involved.  The rule of always using an apostrophe for
plurals of "non-words" is no longer universal:

One rule is apostrophe "s" is used for plural for "words" that are not
normally a noun; but z13 in our context is normally a noun, so by that
standard the plural could be just z13s.

When multi-digit numbers are made into a plural, it is now acceptable to
use just "s" for plural, as in both 1990's and 1990s being in common use
for multiple years in that decade -- again by that standard, z13s could
be a plural of z13.

And of course, if you want a possessive form, like "the z13's frame",
then the apostrophe is required, which is very confusing if you also
demand the apostrophe for a plural.

All in all, "z13s" as a distinct machine type introduces ambiguity that
could easily have been avoided.  It was not an astute choice.
Joel C. Ewing
 
On 02/18/2016 07:57 PM, Ken Smith wrote:
> Maybe right:
>
> z13 is a single z13
> z13's is more than one z13
> z13s is a single z13s
> z13s' is more than one z13s
> z13* or z13x is one or more z13*'s or z13x's
>
> where x or * is any char including null
>
> Ken
>
> On Thu, Feb 18, 2016 at 7:50 PM, Ed Gould <edgould1...@comcast.net> 
wrote:
>
>> On Feb 18, 2016, at 3:30 AM, Timothy Sipples wrote:
>> 
-SNIP-
>>
>>> 4. IBM has greatly relaxed the data center environmental requirements 
for
>>> this model, expanding the temperature and humidity envelopes. It's 
much
>>> more realistic now to install the z13s in nontraditional data centers, 
or
>>> even places that aren't really data centers. Platforms that move, for
>>> example, or out in remote facilities. (In technobabble it's an ASHRAE
>>> class
>>> A3 system now instead of class A2.)
>>>
>>
>> SNIP---
>> Timothy,
>>
>> Thanks for the update
>> -WAR STORY TIME
>> I worked at one place that used a ware house type environment to do DR.
>> That is they bought a new machine in their DC and disassembled the old
>> machine and put it in the ware house.
>> Some how they expected the old machine could do DR. Periodically they
>> would send a sysprog off to the DR site to power up and run a few job.
>> The sysprog was fairly good he could use a screwdriver like no other
>> sysprog and could basically get the machine up and limping to do those 
few
>> jobs.
>> That is until they bought a new machine that couldn't IPL the latest 
and
>> greatest MVS. Also DB2 wouldn't even work.
>> They ordered the new machine with their heads in the clouds as they 
were
>> so cheap they didn't even want to pay for the latest COBOL.
>> They screamed and moaned about having to put out a few dollars a month 
for
>> COBOL and LE.
>> When reminded that the old COBOL was Y2K compliant that pretty well 
shut
>> them up.
>> I was never so happy to leave place everything that cost $$ was met 
with a
>> NO.
>> They were also unhappy that their homegrown security system would not 
work
>> anymore and they had to go to RACF.
>> IDIOTS they got what they deserved.
>>
>> Ed
>>
>> ...


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Timothy Sipples]

Frank Swarbrick wrote:
>Perhaps I'm the only one...

Maybe not literally the only person, but

I would point out that the largest technology company in the world in terms
of market capitalization, Apple, is now selling the iPhone 6s and 6s Plus.
Apple also still sells the iPhone 5s, and Apple only very recently withdrew
the iPhone 4s from its remaining markets (from India, for example).

Here are some other mobile phone examples: Huawei G610s, G620s, U5900s,
P1s, and 5s; Xolo Q510s, Q520s, Q600s, Q610s, Q700s, Q710s, Q900s, Q1000s,
A510s, A700s, and A1000s; Ericsson T10s, T18s, T20s, T28s, T29s, A1013s,
and R310s; LG GM650s; Pantech PG-1000s; Sony Xperia Z1s; HTC Desire 626s,
One M8s, and One M9s. Some of you may have Hewlett-Packard 6s, 8s, 9s, 10s,
35s, 39gs, and 40gs calculators. In the automotive world, BMW has or had
the 318is, 320is, 335is, and 535is models, as examples, and there are
plenty of "s" trim levels available from other manufacturers. There are
also many human model names that end in s. According to the U.S. Social
Security Administration, James, Charles, Alexis, and Nicholas have ranked
in the top five most popular baby names in at least certain years in that
country. And Francis might be a particularly familiar name.

OK, you get the idea. IBM z13s is a perfectly fine name and an even
better machine.


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

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Marc Wambeke]

Well, at least I'm glad some agree about the poor naming of the new system. 

But I'm actually responding to your remark, Timothy, that you can get a 
reduction of 13% on your MLC bill when compared to a zBC12 when you're under 30 
MSU. I don't think that's the case. AEWLC was first introduced with the z114. 
And with the zBC12, there was a reduction on that original pricing of about 5% 
on average.
Now with the z13s, there's a reduction starting at 13%, but this is in relation 
to the original z114 pricing and not in relation to the zBC12. On average, 
coming from a zBC12, you'll have a reduction of about 5%.
Correct me if I'm wrong !

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Andrew Rowley]

On 19/02/2016 05:15 PM, Timothy Sipples wrote:

Andrew Rowley wrote:

I will make the same comment I made last time this topic came up -
avoiding garbage collection is not usually a wise goal.

It depends on the workload(s). The point I made is that with the z13 and
z13s you have more such options, when/as they make sense.

To pick an example, I recall dealing with a Java workload that had an
unresolved memory leak.


Memory leaks are not a usual case, but I would suggest you will still 
want to garbage collect.


I'm not arguing against large memory - I am all in favour of as much as 
you can afford. It's just the suggestion that avoiding Java GC is a good 
idea.


I believe that Java is one of the keys to the future of z/OS. 
Suggestions like "allocate enough memory that you don't have to GC" 
contribute to the view that Java is a memory hog and performs poorly. 
That is damaging to Java on z/OS and as a result damaging to z/OS as a 
whole.


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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Timothy Sipples]

Andrew Rowley wrote:
>I will make the same comment I made last time this topic came up -
>avoiding garbage collection is not usually a wise goal.

It depends on the workload(s). The point I made is that with the z13 and
z13s you have more such options, when/as they make sense.

To pick an example, I recall dealing with a Java workload that had an
unresolved memory leak. Such is life sometimes. Nobody is perfect, and one
should plan for human fallibility. The application development team did a
superb job to resolve the problem, eventually successfully, but it took
several weeks to nail it down and get the fix tested and into production.
In the meantime, on the production side, the operators ran the
mission-critical application in a minimum of two servants, with HTTP
session persistence and big heaps (lots of memory) to keep them afloat for
as long as possible ("hours"). Then, even with the unresolved leak, they
could maintain continuous service for their users. Much like the coach of a
basketball team, they "benched" each player (servant) on a scheduled basis
before the player got exhausted (couldn't garbage collect). They decided
when the best times were to recycle opportunistically. This heroic
production operator save meant that end users didn't have any service
interruptions. They had no idea there was an ongoing, nail biting drama --
everything ran smoothly. That's just one example among many of the
advantages of having lots of memory or at least a bit more than "enough."
In their case throwing some more memory at the problem literally meant not
busting their Service Level Agreement (SLA) on an extremely important
application.

My hats off to those teams. Bravo, disaster well averted.


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

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Paul Gilmartin]

On Thu, 18 Feb 2016 20:57:57 -0500, Ken Smith wrote:

>Maybe right:
>
>z13 is a single z13
>z13's is more than one z13
>z13s is a single z13s
>z13s' is more than one z13s
>z13* or z13x is one or more z13*'s or z13x's
>
>where x or * is any char including null
> 
Hmmm ...

Actress Nominative singular
Actress's   Possessive singular
Actresses   Nominative plural
Actresses'  Possessive plural

But, as Joel says, the rules are not universally understood.
And the distinction between word and non-word is further
confusing.

I agree with Mark: the choice was ill-considered.

-- gil

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Andrew Rowley]

On 18/02/2016 20:30, Timothy Sipples wrote:

Huge memory makes it possible to run completely new classes of workloads,
for example ... Java heaps that never garbage collect during a batch run



I will make the same comment I made last time this topic came up - 
avoiding garbage collection is not usually a wise goal.


Reasons garbage collection is a good thing:

1) Processor cache. IBM has been making a big thing of processor cache, 
with type 113 records and RNI classification of workloads, for good 
reason. Compared to processor cache, memory is VERY slow. I don't recall 
the figures (if IBM even publishes them) but the general consensus is 
that main storage is to processor cache what disk is to main storage. 
You do NOT want your data in main storage if it could be in cache.


Garbage collection moves active data together in the address space. This 
is very good for processor cache - it makes it more likely that data 
will all be in a cache closer to the processor. By eliminating dead 
object space, Java might even utilize cache better than languages like C++.


On the other hand if you give Java a huge heap to avoid garbage 
collection, you run the real risk that active data ends up spread thinly 
across several GB of address space. This is almost the pathological 
worst case for processor cache usage.


2) 64 bit performance. (This one is subject to IIRC and is probably much 
less significant than #1). 64 bit Java is slightly slower than 32 bit 
EXCEPT THAT if the heap is less than a certain size (2GB?) it can 
perform some optimizations so that performance is the same as 32 bit. Go 
over that boundary and you lose some performance.


3) It's pretty hard to guarantee than you will never invoke GC. The 
longer you have been without it the worse it will be. You will at least 
suffer the cache penaties, and you might even have to page in parts of 
the address space. Then everyone wonders what happened, someone points 
at GC and the conclusion is that GC mustn't be allowed to happen - when 
really the problem was the lack of GC up to that point.


GC can be a problem for interactive workloads where response time is 
critical. In that case deterministic memory managment e.g. C++ might be 
better. However, batch jobs are about the least likely workload to 
suffer ill effects from regular "stop the world" GC.


Andrew Rowley


--
Andrew Rowley
Black Hill Software
+61 413 302 386

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Joel C. Ewing]

The recognized punctuation rules are no longer black and white where z13
and z13s are involved.  The rule of always using an apostrophe for
plurals of "non-words" is no longer universal:

One rule is apostrophe "s" is used for plural for "words" that are not
normally a noun; but z13 in our context is normally a noun, so by that
standard the plural could be just z13s.

When multi-digit numbers are made into a plural, it is now acceptable to
use just "s" for plural, as in both 1990's and 1990s being in common use
for multiple years in that decade -- again by that standard, z13s could
be a plural of z13.

And of course, if you want a possessive form, like "the z13's frame",
then the apostrophe is required, which is very confusing if you also
demand the apostrophe for a plural.

All in all, "z13s" as a distinct machine type introduces ambiguity that
could easily have been avoided.  It was not an astute choice.
Joel C. Ewing
 
On 02/18/2016 07:57 PM, Ken Smith wrote:
> Maybe right:
>
> z13 is a single z13
> z13's is more than one z13
> z13s is a single z13s
> z13s' is more than one z13s
> z13* or z13x is one or more z13*'s or z13x's
>
> where x or * is any char including null
>
> Ken
>
> On Thu, Feb 18, 2016 at 7:50 PM, Ed Gould  wrote:
>
>> On Feb 18, 2016, at 3:30 AM, Timothy Sipples wrote:
>> -SNIP-
>>
>>> 4. IBM has greatly relaxed the data center environmental requirements for
>>> this model, expanding the temperature and humidity envelopes. It's much
>>> more realistic now to install the z13s in nontraditional data centers, or
>>> even places that aren't really data centers. Platforms that move, for
>>> example, or out in remote facilities. (In technobabble it's an ASHRAE
>>> class
>>> A3 system now instead of class A2.)
>>>
>>
>> SNIP---
>> Timothy,
>>
>> Thanks for the update
>> -WAR STORY TIME
>> I worked at one place that used a ware house type environment to do DR.
>> That is they bought a new machine in their DC and disassembled the old
>> machine and put it in the ware house.
>> Some how they expected the old machine could do DR. Periodically they
>> would send a sysprog off to the DR site to power up and run a few job.
>> The sysprog was fairly good he could use a screwdriver like no other
>> sysprog and could basically get the machine up and limping to do those few
>> jobs.
>> That is until they bought a new machine that couldn't IPL the latest and
>> greatest MVS. Also DB2 wouldn't even work.
>> They ordered the new machine with their heads in the clouds as they were
>> so cheap they didn't even want to pay for the latest COBOL.
>> They screamed and moaned about having to put out a few dollars a month for
>> COBOL and LE.
>> When reminded that the old COBOL was Y2K compliant that pretty well shut
>> them up.
>> I was never so happy to leave place everything that cost $$ was met with a
>> NO.
>> They were also unhappy that their homegrown security system would not work
>> anymore and they had to go to RACF.
>> IDIOTS they got what they deserved.
>>
>> Ed
>>
>> ...


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Ken Smith]

Maybe right:

z13 is a single z13
z13's is more than one z13
z13s is a single z13s
z13s' is more than one z13s
z13* or z13x is one or more z13*'s or z13x's

where x or * is any char including null

Ken

On Thu, Feb 18, 2016 at 7:50 PM, Ed Gould  wrote:

> On Feb 18, 2016, at 3:30 AM, Timothy Sipples wrote:
> -SNIP-
>
>>
>> 4. IBM has greatly relaxed the data center environmental requirements for
>> this model, expanding the temperature and humidity envelopes. It's much
>> more realistic now to install the z13s in nontraditional data centers, or
>> even places that aren't really data centers. Platforms that move, for
>> example, or out in remote facilities. (In technobabble it's an ASHRAE
>> class
>> A3 system now instead of class A2.)
>>
>
>
> SNIP---
>>
>
> Timothy,
>
> Thanks for the update
> -WAR STORY TIME
> I worked at one place that used a ware house type environment to do DR.
> That is they bought a new machine in their DC and disassembled the old
> machine and put it in the ware house.
> Some how they expected the old machine could do DR. Periodically they
> would send a sysprog off to the DR site to power up and run a few job.
> The sysprog was fairly good he could use a screwdriver like no other
> sysprog and could basically get the machine up and limping to do those few
> jobs.
> That is until they bought a new machine that couldn't IPL the latest and
> greatest MVS. Also DB2 wouldn't even work.
> They ordered the new machine with their heads in the clouds as they were
> so cheap they didn't even want to pay for the latest COBOL.
> They screamed and moaned about having to put out a few dollars a month for
> COBOL and LE.
> When reminded that the old COBOL was Y2K compliant that pretty well shut
> them up.
> I was never so happy to leave place everything that cost $$ was met with a
> NO.
> They were also unhappy that their homegrown security system would not work
> anymore and they had to go to RACF.
> IDIOTS they got what they deserved.
>
> Ed
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Ed Gould]

On Feb 18, 2016, at 3:30 AM, Timothy Sipples wrote:
- 
SNIP-


4. IBM has greatly relaxed the data center environmental  
requirements for
this model, expanding the temperature and humidity envelopes. It's  
much
more realistic now to install the z13s in nontraditional data  
centers, or

even places that aren't really data centers. Platforms that move, for
example, or out in remote facilities. (In technobabble it's an  
ASHRAE class

A3 system now instead of class A2.)




SNIP---


Timothy,

Thanks for the update
-WAR STORY TIME
I worked at one place that used a ware house type environment to do DR.
That is they bought a new machine in their DC and disassembled the  
old machine and put it in the ware house.
Some how they expected the old machine could do DR. Periodically they  
would send a sysprog off to the DR site to power up and run a few job.
The sysprog was fairly good he could use a screwdriver like no other  
sysprog and could basically get the machine up and limping to do  
those few jobs.
That is until they bought a new machine that couldn't IPL the latest  
and greatest MVS. Also DB2 wouldn't even work.
They ordered the new machine with their heads in the clouds as they  
were so cheap they didn't even want to pay for the latest COBOL.
They screamed and moaned about having to put out a few dollars a  
month for COBOL and LE.
When reminded that the old COBOL was Y2K compliant that pretty well  
shut them up.
I was never so happy to leave place everything that cost $$ was met  
with a NO.
They were also unhappy that their homegrown security system would not  
work anymore and they had to go to RACF.

IDIOTS they got what they deserved.

Ed

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[zMan]

OK, not being negative, but this is just the BC version of a z13, right?
With some minor other stuff? Not unimpressive, but not quite the revolution
that the announcement tries to make it sound like.

Or am I missing something?

On Thu, Feb 18, 2016 at 6:50 PM, Mark Post  wrote:

> >>> On 2/18/2016 at 06:20 PM, Frank Swarbrick 
> wrote:
>
> > Just a comment, the name z13s did not appear to me to be a name of a new
> > system, but rather just the plural of z13, i.e. "Look at those z13s
> run!".
> > Took me a while to figure out this was in fact a new name and a new
> offering.
> >
> > Perhaps I'm the only one...
>
> I don't think any marketeer has ever been accused of being "too smart."
>
>
> Mark Post
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Mark Post]

>>> On 2/18/2016 at 06:20 PM, Frank Swarbrick  
>>> wrote:

> Just a comment, the name z13s did not appear to me to be a name of a new 
> system, but rather just the plural of z13, i.e. "Look at those z13s run!".  
> Took me a while to figure out this was in fact a new name and a new offering.
> 
> Perhaps I'm the only one...

I don't think any marketeer has ever been accused of being "too smart."


Mark Post

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Tom Brennan]

You're not the only one.  It's just asking for trouble.
"I need you to IPL all the z13s this weekend, but not the z13s."
??

Frank Swarbrick wrote:

Just a comment, the name z13s did not appear to me to be a name of a new system, but 
rather just the plural of z13, i.e. "Look at those z13s run!".  Took me a while 
to figure out this was in fact a new name and a new offering.

Perhaps I'm the only one...



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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Tony Harminc]

On 18 February 2016 at 18:20, Frank Swarbrick
 wrote:
> Just a comment, the name z13s did not appear to me to be a name of a new 
> system, but rather just the plural of z13, i.e. "Look at those z13s run!".  
> Took me a while to figure out this was in fact a new name and a new offering.

But I assume a z13s is still a z13 for the purposes of the statement
"z13 is the last IBM processor that will support ESA/390 mode"...

> Perhaps I'm the only one...

No.

Tony H.

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

Re: Introducing the New z13s: Tim's Hardware Highlights

[Frank Swarbrick]

Just a comment, the name z13s did not appear to me to be a name of a new 
system, but rather just the plural of z13, i.e. "Look at those z13s run!".  
Took me a while to figure out this was in fact a new name and a new offering.

Perhaps I'm the only one...

> Date: Thu, 18 Feb 2016 17:30:16 +0800
> From: sipp...@sg.ibm.com
> Subject: Introducing the New z13s: Tim's Hardware Highlights
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> IBM is now taking orders for the new IBM z13s machines, and shipments
> should start next month (March, 2016). Here is my undoubtedly incomplete
> list of this new mainframe model's technical highlights, the ones I
> personally find most interesting and exciting in the system itself.
> (Operating systems and software are at least as important, but I'm not
> focusing on those important areas in this list.) Please note that the IBM
> z13 machines also pick up improvements and enhancements. If something is
> listed below it most likely also applies to the z13, excepting obviously
> model-specific characteristics as clock speeds, capacity models, etc.
> 
> Here we go, in no particular order
> 
> 1. Memory! A single z13s can now support up to 4 TB of customer usable,
> RAIM-protected main memory. As Paris Hilton says, "That's huge." Also
> exciting is that you will never have to suffer with less than 64 GB of main
> memory (customer usable, RAIM-protected) because that's now the minimum per
> z13s machine, also a factor of 8 increase from the previous model -- and
> now both the z13s and z13 have the same minimum memory specification.
> Memory is also much more affordable, especially if you order lots of it in
> one go. Please do. It's darn useful and saves you real money.
> 
> Just to underscore how revolutionary 4 TB of main memory is in the z13s,
> the zEC12 -- the largest model mainframe introduced in 2012 -- supported
> "only" 3 TB of main memory. This supposed "mid-range" z13s mainframe
> supports 33% more main memory than the biggest available mainframe did
> until 2015. "That's huge." Even the minimum physical N10 model z13s
> configuration supports up to 1 TB of main memory. That's still huge.
> 
> Huge memory makes it possible to run completely new classes of workloads,
> for example enormous virtualized server landscapes, massive in-memory DB2
> tables, Java heaps that never garbage collect during a batch run, and big
> Blockchain public ledgers.
> 
> 2. There's a new type of cross-LPAR in memory network connectivity
> available specifically for TCP sockets called "Shared Memory
> Communications-Direct Memory Access" or SMC-D for short. (I would have just
> called it "Super HiperSockets" or something like that, but I didn't get a
> vote and wasn't asked. SMC-D it is.) HiperSockets are great and still
> supported, and indeed you'll still use them in conjunction with SMC-D, but
> SMC-D is even faster and reduces processing requirements even more. SMC-D
> is designed for TCP socket connections between z/OS LPARs (minimum z/OS
> 2.2). It's part of every system at no additional charge. No application
> changes are required.
> 
> 3. For z/OS, z/VSE, and z/TPF, subcapacity models are available ranging
> from 80 to 7123 PCIs (A01 to Z06 models), not counting specialty engine
> capacities and assist processors. A Z01 capacity model (single general
> purpose core) has a PCI rating of 1430. That's just a whisker shy of the
> zEC12 (1514), with the standard caveats about cross-model comparisons. The
> Z06 capacity model of the zBC12 had a PCI rating of 4958 as another point
> of comparison. By any measure the z13s is an extremely powerful system. The
> processor clock speed is 4.3 GHz continuous, up from 4.2 GHz in the zBC12.
> 
> 4. IBM has greatly relaxed the data center environmental requirements for
> this model, expanding the temperature and humidity envelopes. It's much
> more realistic now to install the z13s in nontraditional data centers, or
> even places that aren't really data centers. Platforms that move, for
> example, or out in remote facilities. (In technobabble it's an ASHRAE class
> A3 system now instead of class A2.)
> 
> 5. Both the Hardware Management Console (HMC) and Trusted Key Entry (TKE)
> are now available in "1U" rack mountable versions. It's not that you
> couldn't rack mount the previous HMC and TKE -- you could, many do. But now
> they only take up 1U of rack space each, and they're specifically designed
> for rack mounting. The traditional HMC and TKE are still available (and
> will be, as far as I know), so you can choose whichever you prefer. I
> prefer the new 1U form factors.
> 
> 6. In the latest HMC driver level (2.13.1, the minimum to support the z13s)
> IBM has eliminated the Java plug-in requirement at least for several HMC
> functions. You should no longer need to wrestle with making Java applet
> support work in your Web browser. I don't know if IBM has completely
> eliminated the Java plug-in requirement yet -- perhaps somebody could check
> that 

Re: Introducing the New z13s: Tim's Hardware Highlights

[Parwez Hamid]

I will add a complete list of all the new functions/features later on. In the 
meantime, the following ITSO Redbooks are available. Note these are the 'draft' 
versions and subject to change(s).

IBM z13s Technical Guide (SG24-8294-00)
IBM z13 Technical Guide (SG24-8251-01)
IBM z13 and z13s Technical Intrdoduction (SG24-8250-01)

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