Introducing the New z13s: Tim's Hardware Highlights
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 and report back -- but at least the journey is well underway. Oracle has announced that the next version of their Java Runtime Environment (JRE) won't include a browser plug-in, so this change is inevitable. Of course you still need to make sure whatever client you're using for remote HMC access is well secured and that you follow good HMC-related security practices. 7. You can now have up to 40 Logical Partitions (LPARs) on the z13s, up from 30 on the zBC12. And there's a new administrative mode in PR/SM called "Dynamic Partition Manager" that makes it quicker and
Re: Introducing the New z13s: Tim's Hardware Highlights
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
Re: Introducing the New z13s: Tim's Hardware Highlights
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 1
Re: Introducing the New z13s: Tim's Hardware Highlights
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
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
>>> 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
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
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
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
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
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
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 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
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
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
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
You want to garbage collect so long as it doesn't: Cause too much cost. Get in the way. I'm not overly familiar with modern designs but they are aiming at getting both of the above right. 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: Andrew Rowley To: IBM-MAIN@LISTSERV.UA.EDU Date: 19/02/2016 07:17 Subject:Re: Introducing the New z13s: Tim's Hardware Highlights Sent by:IBM Mainframe Discussion List 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 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
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" 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 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 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
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 To: IBM-MAIN 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 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
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
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
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
For confusion's sake, the 2000s have three meanings. The two hundredth one decade since CE: 200x, The twenty first century since CE:20xx, and the third millennium since CE: 2xxx. On Thu, Feb 18, 2016 at 8:33 PM, Joel C. Ewing wrote: > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Introducing the New z13s: Tim's Hardware Highlights
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 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" > 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 > > > > 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. >>> >&
Re: Introducing the New z13s: Tim's Hardware Highlights
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
On Fri, 19 Feb 2016 10:07:50 -0600, Mike Schwab wrote: >The twenty first century since CE:20xx, The 21st century is from 2001 through 2100 >and the third millennium since CE: 2xxx. The third millennium is the years from 2001-3000. -- Tom Marchant -- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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&software costs have dropped to such a level that power&cooling 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