Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On 7 Aug 2023, at 2:46 pm, Timothy Sipples wrote: > > David Crayford wrote: >> Maybe wait until there is actually some tangible AI libraries such as >> TensorFlow, PyTorch and SnapML before blowing trumpets. > > Huh? You *can* run these libraries on z/OS, on zIIPs even. They run on the > z/OS Container Extensions (zCX) or on OpenShift for z/OS, as you prefer. IBM > documents this deployment pattern here (TensorFlow and SnapML examples): > > https://ibm.github.io/ai-on-z-101/tensorflow/ > https://ibm.github.io/ai-on-z-101/snapml/ > Absolutely! The issue is that zCX is not a mature technology. zCX on OpenShift has serious performance issues. It current hogs 5 zIIPS running idle (only running OCP). Of course, it will improve just like DB2, Java etc but it’s not ready for prime time yet. > Are you asking specifically for z/OS UNIX System Services-based > implementations? Of course. Considering the zDDN library is available on z/OS I expected the Python libraries to be available at the same time as Linux on Z. > If so, have you asked IBM in an official way? Yes. It’s in the pipeline but we can’t give you a date :) A bit like Java 17. And that’s a bigger problem because Spring Boot moves to a Java 17 as the baseline in December 2023 which is making a lot of vendors slightly nervous. Although as CICS uses SB I have high hopes. > > — > Timothy Sipples > Senior Architect > Digital Assets, Industry Solutions, and Cybersecurity > IBM zSystems/LinuxONE, Asia-Pacific > 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
Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
David Crayford wrote: >Maybe wait until there is actually some tangible AI libraries such as >TensorFlow, PyTorch and SnapML before blowing trumpets. Huh? You *can* run these libraries on z/OS, on zIIPs even. They run on the z/OS Container Extensions (zCX) or on OpenShift for z/OS, as you prefer. IBM documents this deployment pattern here (TensorFlow and SnapML examples): https://ibm.github.io/ai-on-z-101/tensorflow/ https://ibm.github.io/ai-on-z-101/snapml/ Are you asking specifically for z/OS UNIX System Services-based implementations? If so, have you asked IBM in an official way? — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/LinuxONE, Asia-Pacific 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> for some reason, I cannot convince anyone else to use it. My guess is inertia. At least they admit that it has been around for a long time. Please tell me that they do! From: IBM Mainframe Discussion List on behalf of Jack Zukt Sent: Saturday, August 5, 2023 5:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives I have been using ISPF workplace extensively for years now but, for some reason, I cannot convince anyone else to use it. It is very useful when you have to work with different systems that use different conventions for the same type of files, like SMF, SMPE, DCOLLECT reports, SYSLOG, to name a few. You can create lists with the same name on each system so you will not have to remember which is the dataset name on that particular system. It is a very useful feature, for a few of us at least. Best wishes Jack On Fri, Aug 4, 2023, 19:16 Schmitt, Michael wrote: > You, sir, win the 100 points I have been waiting to award anyone who can > figure out how to effectively use the ISPF Workplace. > > Now explain it to the rest of us. 😉 > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Tom Marchant > Sent: Friday, August 4, 2023 12:36 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: > How it runs and why it survives > > I use data set lists in the ISPF workplace (option 11) for similar reasons. > I have rarely used 3.4 for decades. > > -- > Tom Marchant > > On Fri, 4 Aug 2023 13:14:54 -0400, Bob Bridges > wrote: > > >No, sorry, what I really mean is that instead of going to ISPF option 2 > and typing in a DSN, I generally type "tso ed " on the ISPF command > line. Same for VW and BR, and a few other REXX execs. > > > >The ED, BR and VW commands run the DSN I give it through RENDSN, a > routine that checks the string against a list I maintain. So if I say "tso > ed jg", it'll look up JG and return the name of whatever PDS I'm using at > the current installation for general JCL. The RENDSN list has a few dozen > DSNs in it that I use often enough to bother recording them; that way I > don't have to remember the name of the production CFILE, or where the > SuperSession parms are stored, or whether at this client the common REXX > library for the security team is this or that. So most of my most commonly > used "DSNs" are really two- or three-char shortcuts. Saves me some > thinking and a lot of typing. > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I have been using ISPF workplace extensively for years now but, for some reason, I cannot convince anyone else to use it. It is very useful when you have to work with different systems that use different conventions for the same type of files, like SMF, SMPE, DCOLLECT reports, SYSLOG, to name a few. You can create lists with the same name on each system so you will not have to remember which is the dataset name on that particular system. It is a very useful feature, for a few of us at least. Best wishes Jack On Fri, Aug 4, 2023, 19:16 Schmitt, Michael wrote: > You, sir, win the 100 points I have been waiting to award anyone who can > figure out how to effectively use the ISPF Workplace. > > Now explain it to the rest of us. 😉 > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Tom Marchant > Sent: Friday, August 4, 2023 12:36 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: > How it runs and why it survives > > I use data set lists in the ISPF workplace (option 11) for similar reasons. > I have rarely used 3.4 for decades. > > -- > Tom Marchant > > On Fri, 4 Aug 2023 13:14:54 -0400, Bob Bridges > wrote: > > >No, sorry, what I really mean is that instead of going to ISPF option 2 > and typing in a DSN, I generally type "tso ed " on the ISPF command > line. Same for VW and BR, and a few other REXX execs. > > > >The ED, BR and VW commands run the DSN I give it through RENDSN, a > routine that checks the string against a list I maintain. So if I say "tso > ed jg", it'll look up JG and return the name of whatever PDS I'm using at > the current installation for general JCL. The RENDSN list has a few dozen > DSNs in it that I use often enough to bother recording them; that way I > don't have to remember the name of the production CFILE, or where the > SuperSession parms are stored, or whether at this client the common REXX > library for the security team is this or that. So most of my most commonly > used "DSNs" are really two- or three-char shortcuts. Saves me some > thinking and a lot of typing. > > -- > 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
You can do all of those things with the workplace. It has been available since ISPF 4.2 in 1995. If you don't have it on your primary option panel, you can access it with ISPFWORK from any panel. I have been using it for the last 25 years and haven't had the need to use 3.4 since then. The biggest difference between 11 and 3.4 is that, unless you have "Prefix Dsname Level" checked on 3.4, you don't need quotes around the DSNAME Level. With the Workplace, AFAIK, it always acts the way 3.4 does if you have "Prefix Dsname Level" selected. Also, the workplace always gives you enhanced member lists. The major thing that the workplace gives me is the ability to create arbitrary lists of DSNAME masks and have them all included. For example, if you create a list that includes 'foo.**.bar' 'bar.**' and issue DL against that list, you will get a data set list that includes all foo.**.bar data sets and all data sets beginning with bar. Having done that, I can issue SRCHFOR against them all, as just one example The list that I use the most has something like this: 'app1.release1.source 'app1.release1.maclib 'app1.release1.listing 'app1.release1.load 'app2.release2.source 'app2.release2.maclib 'app2.release2.listing 'app2.release2.load etc. for the products that I typically work with. The actual HLQ is not app1, etc, but something more descriptive of the product, so I couldn't use app*. You wouldn't have to reinvent anything, just learn something that is new to you In case you wondered, it has nothing to do with the ISPF Workstation Agent. I used to use that for z/OS <-> PC file transfer, but the WSA has been removed. It wasn't fast, but it was easy to use, at least for me. -- Tom Marchant On Fri, 4 Aug 2023 15:05:23 -0400, Bob Bridges wrote: >Hm, not use 3.4? I still have to go there pretty often, for tasks such as > >- When cleaning up DATASET-class permissions in the security system, I need to >know what datasets actually exist >- When deleting old user IDs, I want to pass any important datasets belonging >to the dearly departed to his old boss >- When I'm hunting for production job that might do a task I'm interested in >(although I guess I would mostly use 3.14 for that) >- While investigating a parmfile or procfile or other system dataset for the >first time > >Dunno that I could live without 3.4. Well, I ~could~, but I'd basically have >to reïnvent it is all. > >Option 11; not sure that's in the menu my current client provided to me. >Obviously I haven't been using it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
In fact I used to do that; I was an employee at a truck manufacturer for 14 year and had those commands, and a few others, in my command table. But by the time I started contracting in '96, I'd forgotten exactly where to get at the command table, and just got used to typing the TSO prefix. Now I do it without thinking. Every so often I think about looking it up and doing it again, but nah, if I type "tso" without thinking then it'd slow me down to try to remember ~not~ to do it. ...Although occasionally I type too fast and drop a letter. Maybe I should think again. And yes, I learned long ago that personal, idiosyncratic tools are personal and idiosyncratic. I would be delighted if everyone tried my tools and thought they were the best thing since sliced bread, but that happens only rarely. I did, once years ago, write a tool for a bunch of DYL users at my company. We were teaching them how to write their own inquiries using DYL-280II, instead of interrupting the developers with ad-hoc requests, and it was such a hit that we set up a special initiator for DYL jobs - two of them, in fact, I think - and the users sometimes had to wait two to four hours for their job to run, only to learn when it finally got to the head of the line that they'd forgotten to declare a variable or something. So I wrote a REXX, and named it DYLCHK, that "compiled" their code in the foreground and told them right away whether their code was syntactically correct. I left there in '96, and I heard later they're still using it. So I feel all validated. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Obedience is the road to freedom, humility the road to pleasure, unity the road to personality. -C S Lewis, "The Weight of Glory" */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Friday, August 4, 2023 15:14 You can easily add "ed" to the ISPF command table (I think it's table ISPCMDS) and drop the "TSO". Write an exec that TBADDs each command. Additionally, I find I need to refer back to the original screen. I start a new screen from the exec so both can be seen using swap. Having a command to display a reflist can also useful. Let your tools work for you instead of you working for your tools. If it works for you then use it but don't do it because we find it useful. > --- On Friday, August 4, 2023 at 10:15:01 AM PDT, Bob Bridges > wrote: > I generally type "tso ed " on the ISPF command line. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On Friday, August 4, 2023 at 11:16:00 AM PDT, Schmitt, Michael > wrote: > award anyone who can figure out how to effectively use the ISPF Workplace. Wasn't the goal of ISPF Workplace to keep Unix programmers engaged when working on z/OS? z/OS takes away the need for so many of their skills that they need to be distracted in some other way. z/OS people say just give me something useful and simple because I don't need thousands of commands. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On Friday, August 4, 2023 at 10:15:01 AM PDT, Bob Bridges > wrote: > I generally type "tso ed " on the ISPF command line. You can easily add "ed" to the ISPF command table (I think it's table ISPCMDS) and drop the "TSO". Write an exec that TBADDs each command. Additionally, I find I need to refer back to the original screen. I start a new screen from the exec so both can be seen using swap. Having a command to display a reflist can also useful. Let your tools work for you instead of you working for your tools. If it works for you then use it but don't do it because we find it useful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Hm, not use 3.4? I still have to go there pretty often, for tasks such as - When cleaning up DATASET-class permissions in the security system, I need to know what datasets actually exist - When deleting old user IDs, I want to pass any important datasets belonging to the dearly departed to his old boss - When I'm hunting for production job that might do a task I'm interested in (although I guess I would mostly use 3.14 for that) - While investigating a parmfile or procfile or other system dataset for the first time Dunno that I could live without 3.4. Well, I ~could~, but I'd basically have to reïnvent it is all. Option 11; not sure that's in the menu my current client provided to me. Obviously I haven't been using it. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Lazlo's Chinese Relativity Axiom: No matter how great your triumphs or how tragic your defeats, approximately one billion Chinese couldn't care less. */ -----Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, August 4, 2023 13:36 I use data set lists in the ISPF workplace (option 11) for similar reasons. I have rarely used 3.4 for decades. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
You, sir, win the 100 points I have been waiting to award anyone who can figure out how to effectively use the ISPF Workplace. Now explain it to the rest of us. 😉 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, August 4, 2023 12:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives I use data set lists in the ISPF workplace (option 11) for similar reasons. I have rarely used 3.4 for decades. -- Tom Marchant On Fri, 4 Aug 2023 13:14:54 -0400, Bob Bridges wrote: >No, sorry, what I really mean is that instead of going to ISPF option 2 and >typing in a DSN, I generally type "tso ed " on the ISPF command line. >Same for VW and BR, and a few other REXX execs. > >The ED, BR and VW commands run the DSN I give it through RENDSN, a routine >that checks the string against a list I maintain. So if I say "tso ed jg", >it'll look up JG and return the name of whatever PDS I'm using at the current >installation for general JCL. The RENDSN list has a few dozen DSNs in it that >I use often enough to bother recording them; that way I don't have to remember >the name of the production CFILE, or where the SuperSession parms are stored, >or whether at this client the common REXX library for the security team is >this or that. So most of my most commonly used "DSNs" are really two- or >three-char shortcuts. Saves me some thinking and a lot of typing. -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I use data set lists in the ISPF workplace (option 11) for similar reasons. I have rarely used 3.4 for decades. -- Tom Marchant On Fri, 4 Aug 2023 13:14:54 -0400, Bob Bridges wrote: >No, sorry, what I really mean is that instead of going to ISPF option 2 and >typing in a DSN, I generally type "tso ed " on the ISPF command line. >Same for VW and BR, and a few other REXX execs. > >The ED, BR and VW commands run the DSN I give it through RENDSN, a routine >that checks the string against a list I maintain. So if I say "tso ed jg", >it'll look up JG and return the name of whatever PDS I'm using at the current >installation for general JCL. The RENDSN list has a few dozen DSNs in it that >I use often enough to bother recording them; that way I don't have to remember >the name of the production CFILE, or where the SuperSession parms are stored, >or whether at this client the common REXX library for the security team is >this or that. So most of my most commonly used "DSNs" are really two- or >three-char shortcuts. Saves me some thinking and a lot of typing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
No, sorry, what I really mean is that instead of going to ISPF option 2 and typing in a DSN, I generally type "tso ed " on the ISPF command line. Same for VW and BR, and a few other REXX execs. The ED, BR and VW commands run the DSN I give it through RENDSN, a routine that checks the string against a list I maintain. So if I say "tso ed jg", it'll look up JG and return the name of whatever PDS I'm using at the current installation for general JCL. The RENDSN list has a few dozen DSNs in it that I use often enough to bother recording them; that way I don't have to remember the name of the production CFILE, or where the SuperSession parms are stored, or whether at this client the common REXX library for the security team is this or that. So most of my most commonly used "DSNs" are really two- or three-char shortcuts. Saves me some thinking and a lot of typing. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* A few observations and much reasoning lead to error; many observations and a little reasoning to truth. -Alexis Carrel */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, August 4, 2023 12:53 ITYM ISPF commands. Or maybe FASTPATH commands. Surely you don't often use the TSO editor rather than the ISPF editor? --- On Fri, 4 Aug 2023 00:22:39 -0400, Bob Bridges wrote: >Come to think of it, I still use TSO commands more often than some of the ISPF >menu options - ED and VW and BR commands rather than options 1 and 2, for >instance. I'm just happier with a command interface than some menus. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
ITYM ISPF commands. Or maybe FASTPATH commands. Surely you don't often use the TSO editor rather than the ISPF editor? -- Tom Marchant On Fri, 4 Aug 2023 00:22:39 -0400, Bob Bridges wrote: >Come to think of it, I still use TSO commands more often than some of the ISPF >menu options - ED and VW and BR commands rather than options 1 and 2, for >instance. I'm just happier with a command interface than some menus. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Also ADP. From: IBM Mainframe Discussion List on behalf of Bob Bridges Sent: Friday, August 4, 2023 8:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives Right, I think it was "EDP" (electronic data processing) when I started. Or maybe even that wasn't the first one I was aware of; it's been a long time now. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Neither irony nor sarcasm is argument. -Samuel Butler */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Friday, August 4, 2023 07:14 Also 'Data Processing'; I vaguely recall that there were a few more terms. From: P H [04843e86df79-dmarc-requ...@listserv.ua.edu] Sent: Friday, August 4, 2023 5:23 AM > BTW: When I started my career during the early 70s, IT didn't exist. It was > 'computers' or 'computing'. -- 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: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Right, I think it was "EDP" (electronic data processing) when I started. Or maybe even that wasn't the first one I was aware of; it's been a long time now. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Neither irony nor sarcasm is argument. -Samuel Butler */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Friday, August 4, 2023 07:14 Also 'Data Processing'; I vaguely recall that there were a few more terms. From: P H [04843e86df79-dmarc-requ...@listserv.ua.edu] Sent: Friday, August 4, 2023 5:23 AM > BTW: When I started my career during the early 70s, IT didn't exist. It was > 'computers' or 'computing'. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Data Processing, most probably from DP division of IBM of that time. Sent from Outlook for Android<https://aka.ms/AAb9ysg> From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Friday, August 4, 2023 12:14:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives > The one I worked on at a sister (can I say this or should it be 'person' > organisation of CERN) had a grand total of 1 MB main memory! That sounds more appropriate for a 65 than a 195. > BTW: When I started my career during the early 70s, IT didn't exist. It was > 'computers' or 'computing'. Also 'Data Processing'; I vaguely recall that there were a few more terms. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of P H [04843e86df79-dmarc-requ...@listserv.ua.edu] Sent: Friday, August 4, 2023 5:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives In response to your comments and some made by others, my 2 cents worth. This discussion started talking about mainframes and 'split' into sub-threads questioning/focusing on IBM z e.g., z/Architecture, what has z ever done, any uniqueness/special features of z etc. In my response, I tried to answer some Qs and correcting some of the numbers which were being quoted. I did end by saying 'horses for courses'. No single system/platform is perfect. All have their uniqueness, strengths and weakness. Today, other platforms may have similar functions/features as z and some may be even better, the point is during the evolution of z under it's different marketing names (S/360, S/370, S/390, eServer, System z etc) z has evolved, adapted and embraced technologies which businesses require for modern workloads. z continues to evolve! z can't be everything to everyone. There are alternatives to 'mainframes' both from IBM (POWER) and others. Talking about weakness, as an example I did mention that my x86 also has limitations. I don't need a better machine, especially an overpriced Mac. Just like some customers think they don't need an overpriced z. With today’s mind set of 'good enough' computing i.e. if it doesn't work reboot, if what you have meets your needs, so be it. Just like your iPhone, my smartphone has most probably more power/memory than S370/195 of early 70s. The one I worked on at a sister (can I say this or should it be 'person' organisation of CERN) had a grand total of 1 MB main memory! However, I doubt our smartphones could process tons of data generated by accelerators causing collisions of energetic particles to investigate the structure of the atomic nucleus. Even during the 70's S370/195 did it very successfully i.e., process large amounts of data (strength of the I/O subsystem ??). Yes, there are other suppliers of MF like systems. Someone else on this thread mentioned that they saw a demo of one which had similar RAS capabilities as of z. I am familiar with that system. Great demo that lots customers rushed to introduce these into their IT infrastructure. One customer I know of, who soon after Y2K were encouraged by their 'consultants' to ditch their centralised IBM MF installed lots of these systems at all their distributed sites, 3 systems at each site (Dev/Test/Prod). In case of this customer the hype of the demo turned sour as the systems were more 'down' then 'up'. To overcome the RAS deficiencies the solution was to have 'spare' systems on site. No pun intended, needless to say these systems were sunset and almost 20 years later the customer is still using z. I am sure amongst this list, others will have examples of customers ditching other platforms including z for all sorts of reasons. We can debate for ever which system is better etc. At the end of day just put your money where your mouth is into what best suits your IT needs🙂 BTW: When I started my career during the early 70s, IT didn't exist. It was 'computers' or 'computing'. ____ From: IBM Mainframe Discussion List on behalf of David Crayford Sent: 04 August 2023 00:42 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives > On 3 Aug 2023, at 2:26 am, P H > <04843e86df79-dmarc-requ...@listserv.ua.edu> wrote: > > The numbers quoted by Tom: > > So I pointed out there's only 12 I/O drawers max on a z16 which is 12 x >
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
My mistake, the 370/195 had 2 MB, this customer's 360/75 had 1 MB Sent from Outlook for Android<https://aka.ms/AAb9ysg> ____ From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Friday, August 4, 2023 12:14:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives > The one I worked on at a sister (can I say this or should it be 'person' > organisation of CERN) had a grand total of 1 MB main memory! That sounds more appropriate for a 65 than a 195. > BTW: When I started my career during the early 70s, IT didn't exist. It was > 'computers' or 'computing'. Also 'Data Processing'; I vaguely recall that there were a few more terms. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of P H [04843e86df79-dmarc-requ...@listserv.ua.edu] Sent: Friday, August 4, 2023 5:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives In response to your comments and some made by others, my 2 cents worth. This discussion started talking about mainframes and 'split' into sub-threads questioning/focusing on IBM z e.g., z/Architecture, what has z ever done, any uniqueness/special features of z etc. In my response, I tried to answer some Qs and correcting some of the numbers which were being quoted. I did end by saying 'horses for courses'. No single system/platform is perfect. All have their uniqueness, strengths and weakness. Today, other platforms may have similar functions/features as z and some may be even better, the point is during the evolution of z under it's different marketing names (S/360, S/370, S/390, eServer, System z etc) z has evolved, adapted and embraced technologies which businesses require for modern workloads. z continues to evolve! z can't be everything to everyone. There are alternatives to 'mainframes' both from IBM (POWER) and others. Talking about weakness, as an example I did mention that my x86 also has limitations. I don't need a better machine, especially an overpriced Mac. Just like some customers think they don't need an overpriced z. With today’s mind set of 'good enough' computing i.e. if it doesn't work reboot, if what you have meets your needs, so be it. Just like your iPhone, my smartphone has most probably more power/memory than S370/195 of early 70s. The one I worked on at a sister (can I say this or should it be 'person' organisation of CERN) had a grand total of 1 MB main memory! However, I doubt our smartphones could process tons of data generated by accelerators causing collisions of energetic particles to investigate the structure of the atomic nucleus. Even during the 70's S370/195 did it very successfully i.e., process large amounts of data (strength of the I/O subsystem ??). Yes, there are other suppliers of MF like systems. Someone else on this thread mentioned that they saw a demo of one which had similar RAS capabilities as of z. I am familiar with that system. Great demo that lots customers rushed to introduce these into their IT infrastructure. One customer I know of, who soon after Y2K were encouraged by their 'consultants' to ditch their centralised IBM MF installed lots of these systems at all their distributed sites, 3 systems at each site (Dev/Test/Prod). In case of this customer the hype of the demo turned sour as the systems were more 'down' then 'up'. To overcome the RAS deficiencies the solution was to have 'spare' systems on site. No pun intended, needless to say these systems were sunset and almost 20 years later the customer is still using z. I am sure amongst this list, others will have examples of customers ditching other platforms including z for all sorts of reasons. We can debate for ever which system is better etc. At the end of day just put your money where your mouth is into what best suits your IT needs🙂 BTW: When I started my career during the early 70s, IT didn't exist. It was 'computers' or 'computing'. ________ From: IBM Mainframe Discussion List on behalf of David Crayford Sent: 04 August 2023 00:42 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives > On 3 Aug 2023, at 2:26 am, P H > <04843e86df79-dmarc-requ...@listserv.ua.edu> wrote: > > The numbers quoted by Tom: > > So I pointed out there's only 12 I/O drawers max on a z16 which is 12 x
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> The one I worked on at a sister (can I say this or should it be 'person' > organisation of CERN) had a grand total of 1 MB main memory! That sounds more appropriate for a 65 than a 195. > BTW: When I started my career during the early 70s, IT didn't exist. It was > 'computers' or 'computing'. Also 'Data Processing'; I vaguely recall that there were a few more terms. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ____ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of P H [04843e86df79-dmarc-requ...@listserv.ua.edu] Sent: Friday, August 4, 2023 5:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives In response to your comments and some made by others, my 2 cents worth. This discussion started talking about mainframes and 'split' into sub-threads questioning/focusing on IBM z e.g., z/Architecture, what has z ever done, any uniqueness/special features of z etc. In my response, I tried to answer some Qs and correcting some of the numbers which were being quoted. I did end by saying 'horses for courses'. No single system/platform is perfect. All have their uniqueness, strengths and weakness. Today, other platforms may have similar functions/features as z and some may be even better, the point is during the evolution of z under it's different marketing names (S/360, S/370, S/390, eServer, System z etc) z has evolved, adapted and embraced technologies which businesses require for modern workloads. z continues to evolve! z can't be everything to everyone. There are alternatives to 'mainframes' both from IBM (POWER) and others. Talking about weakness, as an example I did mention that my x86 also has limitations. I don't need a better machine, especially an overpriced Mac. Just like some customers think they don't need an overpriced z. With today’s mind set of 'good enough' computing i.e. if it doesn't work reboot, if what you have meets your needs, so be it. Just like your iPhone, my smartphone has most probably more power/memory than S370/195 of early 70s. The one I worked on at a sister (can I say this or should it be 'person' organisation of CERN) had a grand total of 1 MB main memory! However, I doubt our smartphones could process tons of data generated by accelerators causing collisions of energetic particles to investigate the structure of the atomic nucleus. Even during the 70's S370/195 did it very successfully i.e., process large amounts of data (strength of the I/O subsystem ??). Yes, there are other suppliers of MF like systems. Someone else on this thread mentioned that they saw a demo of one which had similar RAS capabilities as of z. I am familiar with that system. Great demo that lots customers rushed to introduce these into their IT infrastructure. One customer I know of, who soon after Y2K were encouraged by their 'consultants' to ditch their centralised IBM MF installed lots of these systems at all their distributed sites, 3 systems at each site (Dev/Test/Prod). In case of this customer the hype of the demo turned sour as the systems were more 'down' then 'up'. To overcome the RAS deficiencies the solution was to have 'spare' systems on site. No pun intended, needless to say these systems were sunset and almost 20 years later the customer is still using z. I am sure amongst this list, others will have examples of customers ditching other platforms including z for all sorts of reasons. We can debate for ever which system is better etc. At the end of day just put your money where your mouth is into what best suits your IT needs🙂 BTW: When I started my career during the early 70s, IT didn't exist. It was 'computers' or 'computing'. From: IBM Mainframe Discussion List on behalf of David Crayford Sent: 04 August 2023 00:42 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives > On 3 Aug 2023, at 2:26 am, P H > <04843e86df79-dmarc-requ...@listserv.ua.edu> wrote: > > The numbers quoted by Tom: > > So I pointed out there's only 12 I/O drawers max on a z16 which is 12 x > 16 = 192 slots or 384 ports max. He replied, but didn't seem to fully > accept that answer. > > are 100% correct. These numbers are the MAXIMUM. Depending on the > configuration, these could be a lot less e.g. the number of coupling links > could reduce the numbers. If z16 is ordered with BPA power supplies, the MAX > I/O drawers go down from 12 to 10. > > I have already mentioned things
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
In response to your comments and some made by others, my 2 cents worth. This discussion started talking about mainframes and 'split' into sub-threads questioning/focusing on IBM z e.g., z/Architecture, what has z ever done, any uniqueness/special features of z etc. In my response, I tried to answer some Qs and correcting some of the numbers which were being quoted. I did end by saying 'horses for courses'. No single system/platform is perfect. All have their uniqueness, strengths and weakness. Today, other platforms may have similar functions/features as z and some may be even better, the point is during the evolution of z under it's different marketing names (S/360, S/370, S/390, eServer, System z etc) z has evolved, adapted and embraced technologies which businesses require for modern workloads. z continues to evolve! z can't be everything to everyone. There are alternatives to 'mainframes' both from IBM (POWER) and others. Talking about weakness, as an example I did mention that my x86 also has limitations. I don't need a better machine, especially an overpriced Mac. Just like some customers think they don't need an overpriced z. With today’s mind set of 'good enough' computing i.e. if it doesn't work reboot, if what you have meets your needs, so be it. Just like your iPhone, my smartphone has most probably more power/memory than S370/195 of early 70s. The one I worked on at a sister (can I say this or should it be 'person' organisation of CERN) had a grand total of 1 MB main memory! However, I doubt our smartphones could process tons of data generated by accelerators causing collisions of energetic particles to investigate the structure of the atomic nucleus. Even during the 70's S370/195 did it very successfully i.e., process large amounts of data (strength of the I/O subsystem ??). Yes, there are other suppliers of MF like systems. Someone else on this thread mentioned that they saw a demo of one which had similar RAS capabilities as of z. I am familiar with that system. Great demo that lots customers rushed to introduce these into their IT infrastructure. One customer I know of, who soon after Y2K were encouraged by their 'consultants' to ditch their centralised IBM MF installed lots of these systems at all their distributed sites, 3 systems at each site (Dev/Test/Prod). In case of this customer the hype of the demo turned sour as the systems were more 'down' then 'up'. To overcome the RAS deficiencies the solution was to have 'spare' systems on site. No pun intended, needless to say these systems were sunset and almost 20 years later the customer is still using z. I am sure amongst this list, others will have examples of customers ditching other platforms including z for all sorts of reasons. We can debate for ever which system is better etc. At the end of day just put your money where your mouth is into what best suits your IT needs🙂 BTW: When I started my career during the early 70s, IT didn't exist. It was 'computers' or 'computing'. From: IBM Mainframe Discussion List on behalf of David Crayford Sent: 04 August 2023 00:42 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives > On 3 Aug 2023, at 2:26 am, P H > <04843e86df79-dmarc-requ...@listserv.ua.edu> wrote: > > The numbers quoted by Tom: > > So I pointed out there's only 12 I/O drawers max on a z16 which is 12 x > 16 = 192 slots or 384 ports max. He replied, but didn't seem to fully > accept that answer. > > are 100% correct. These numbers are the MAXIMUM. Depending on the > configuration, these could be a lot less e.g. the number of coupling links > could reduce the numbers. If z16 is ordered with BPA power supplies, the MAX > I/O drawers go down from 12 to 10. > > I have already mentioned things like cache, memory, I/O Subsystem, on chip > data compression/Crypto (z has been a leader for this)/Sort/AI capabilities. Maybe for crypto but certainly not for AI. My iPhone has a more sophisticated AI engine than the z16. Other platforms have integrated AI engines, AMD ZenDNN, Intel oneDNN etc. Both ship with open source libraries and toolkits sadly lacking for z/OS. I noticed that IBM have shipped patched Python packages for TensorFlow and SnapML that exploit Telum for Linux on Z. I suppose like everything, we’ll have to wait a while for z/OS. Java 11 still does not utilise zEDC compression on z/OS. Talking about compression and crypto, Intel have hardware accelerators as part of QAT, either PCIe cards or on-die. You could argue that the compression tech is better than zEDC as it supports more formats then just gzip. https://www.in
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On 4 Aug 2023, at 1:01 pm, Timothy Sipples wrote: > > David Crayford wrote: >> Other platforms have integrated AI engines, AMD ZenDNN, >> Intel oneDNN etc. Both ship with open source libraries and >> toolkits sadly lacking for z/OS. > > Did you miss zDNN? > Nope, I’m aware. Not quite as open source as the other toolkits but it’s good that IBM have embraced Github. > https://github.com/IBM/zDNN > https://www.ibm.com/docs/en/zos/2.5.0?topic=consider-z-deep-neural-network-library-zdnn > >> I noticed that IBM have shipped patched Python packages for >> TensorFlow and SnapML that exploit Telum for Linux on Z. >> I suppose like everything, we’ll have to wait a while for z/OS. > > Missed this one too? > > https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/evan-rivera/2023/02/24/python-ai-toolkit-for-ibm-zos I suspect you are not familiar with the Python AI Toolkit for z/OS. Apart from SciPy, NumPy and some stuff for Jupyter notebooks there is nothing related to AI in that bundle. It’s nothing more than a curated set of Python packages. Please correct me if I’m wrong. > > Quoting from the IBM Redpaper: > > "The Python AI Toolkit for IBM z/OS also benefits from the IBM zSystems > hardware investments that are lower in the stack. Acceleration from the IBM > Integrated Accelerator for AI provides benefits when running AI workloads > that are built on top of the Python AI Toolkit for IBM z/OS. With this > workload execution acceleration, enterprises can meet successfully some of > the most stringent service-level agreements (SLAs) when integrating AI into > business-critical workloads." > > https://www.redbooks.ibm.com/abstracts/redp5709.html Maybe wait until there is actually some tangible AI libraries such as TensorFlow, PyTorch and SnapML before blowing trumpets. > > — > Timothy Sipples > Senior Architect > Digital Assets, Industry Solutions, and Cybersecurity > IBM zSystems/LinuxONE, Asia-Pacific > 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On Thursday, August 3, 2023 at 10:47:52 AM PDT, Joel C. Ewing > wrote: > There is a synergy that exists between z-architecture hardware and z/OS > that has evolved over many decades. IBM designs with insight whereas other manufacturers implement. You would never install 1 giant disk on IBM z. Instead you install multiple smaller disks to avoid bottlenecks. There is nothing that stops other manufacturers from designing everything IBM has designed. IBM thinks about everything from RAS to performance. > The hardware is designed with redundancy to detect failures There is no doubt that IBM does an excellent job in RAS design. You get what you pay for. Don't expect to get a million $ computer for $5,000. > Undetected hardware errors don't happen. Undetected by nature goes unnoticed. It's extremely rare for IBM but People aren't perfect and solutions to a problem simply change the problem. > designed with the philosophy that software failures may occur within > parts of the operating system, either from a hardware failure or a > system software bug. System recovery routines exist to clean up after > such failures, limit what running address spaces are affected, and allow > production to continue in unaffected address spaces. While IBM goes to great strides for RAS, they have their limits. GDPS and automation costs extra. They exist purely for RAS. > An explicit part of the design philosophy is that applications running > in different address spaces are isolated: CICS and z/OS UNIX use an address space to run multiple applications (at least they used to). I suspect that programming languages have become so reliable that we simply don't experience many storage overlays caused by applications. On the other hand, UNIX and Linux processes are fully protected with each process having storage protected from other processes. > Another important feature of z/OS that requires some hardware > coordination is the System Measurement Facility that gathers measurement > of system activity and resource usage at a level to support performance > tuning or billing based on resource usage. SMF and RMF are simply free tools that provide basic information. Unix and Linux also provide a similar free tool for monitoring performance. On z/OS, you can upgrade to Omegamon, Intune and other tools for more in depth performance information. > if you could somehow succeed in running it under > Linux or on non-z hardware, it would lose the reliability, availability, > and serviceability it gets from that hardware/software synergy that > makes it an ideal production platform for critical workloads. What I'm saying is that we should expect some z/OS components (not all) to appear in IBM RHEL on IBM z machines. Don't expect CICS on RHEL for z but migrating GRS is minor considering that the hardware and instruction set are the same. You only need to change the z/OS specific code. GRS improves RAS because it's a superior implementation of Unix mutex and semaphore. Same for SYSPLEX, some of DFSMS, JES, SSI and more. To have the same synergy as z/OS, RHEL only needs the components that provide the synergy. I've never said that z/OS will be implemented in non-z hardware. I've said there is nothing stopping other companies from implementing these designs. They simply have no desire to use 2 PCIe ports for redundancy when 1 works most of the time. I've never said that IBM would integrate z/OS into Linux but said in theory they have prior experience in doing such things like this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
David Crayford wrote: >Other platforms have integrated AI engines, AMD ZenDNN, >Intel oneDNN etc. Both ship with open source libraries and >toolkits sadly lacking for z/OS. Did you miss zDNN? https://github.com/IBM/zDNN https://www.ibm.com/docs/en/zos/2.5.0?topic=consider-z-deep-neural-network-library-zdnn >I noticed that IBM have shipped patched Python packages for >TensorFlow and SnapML that exploit Telum for Linux on Z. >I suppose like everything, we’ll have to wait a while for z/OS. Missed this one too? https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/evan-rivera/2023/02/24/python-ai-toolkit-for-ibm-zos Quoting from the IBM Redpaper: "The Python AI Toolkit for IBM z/OS also benefits from the IBM zSystems hardware investments that are lower in the stack. Acceleration from the IBM Integrated Accelerator for AI provides benefits when running AI workloads that are built on top of the Python AI Toolkit for IBM z/OS. With this workload execution acceleration, enterprises can meet successfully some of the most stringent service-level agreements (SLAs) when integrating AI into business-critical workloads." https://www.redbooks.ibm.com/abstracts/redp5709.html — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/LinuxONE, Asia-Pacific 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I usually tell people that IBM invented really good hardware, and left it to others to make software that was decently user-friendly. The IBM Selectric was great, and that little red eraser they invented for cursor movement on the laptops was - well, I still prefer plugging in a real trackball, but it was high-quality. We still moon over the old 3270 keyboards. But I tried using their early word processor software; it was awful. And I can use RACF, but TSS is much easier to manage. Let the flames begin. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* An engineer thinks that equations approximate reality. A physicist thinks that reality approximates equations. A mathematician never makes the connection. */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Grant Taylor Sent: Thursday, August 3, 2023 21:24 I hope you mean "IBM /was/ the standard bearer in computer design". I even question that or that hope you mean close to 30 years ago. --- On 8/3/23 3:27 PM, Rahim Azizarab wrote: > IBM is the standard bearer in computer design even when it came to > laptops, just see how well IBM designed the Thinkpads. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Wow, the READY prompt! I used to be quite familiar with that, before ROSCOE and ISPF. I once wrote a CLIST that helped me navigate the OUTPUT command more easily, though I don't recall convincing anyone else it was better than the raw command. Come to think of it, I still use TSO commands more often than some of the ISPF menu options - ED and VW and BR commands rather than options 1 and 2, for instance. I'm just happier with a command interface than some menus. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* My father used to play with my brother and me in the yard. Mother would come out and say "You're tearing up the grass." "We're not raising grass," Dad would reply; "we're raising boys." -Harmon Killebrew */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Thursday, August 3, 2023 18:29 I seem to remember that action when working on a PDP11 using a VT100 terminal. It was as if the designers said, hey, you obviously want a CR in the middle of the line, so there you go. And to Linux users, TSO READY mode must look really odd when they find they can move the cursor to a previous command and press Enter, but nothing happens until they overtype at least one byte. We must look like nut cases sometimes :) --- On 8/3/2023 1:27 PM, Rahim Azizarab wrote: > One of its oddities was that if you typed a line and happened to have the > cursor before end of the line the right portion of the line was lost. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 8/3/23 3:27 PM, Rahim Azizarab wrote: IBM is the standard bearer in computer design even when it came to laptops, just see how well IBM designed the Thinkpads. I hope you mean "IBM /was/ the standard bearer in computer design". I even question that or that hope you mean close to 30 years ago. IBM was closely followed in the early days of the PC / AT / XT. But other companies pulled along side and started leading the pack. Notably Compaq servers in the late 386, 486, and Pentium time frame started eating IBM's lunch. It seems like IBM jumped the shark with the PS/2 as far as PCs are concerned. I think many in the industry -- though maybe not in this group -- will agree with me when I say that IBM was considered an "also built PCs" or "they still build PCs?" in the late '90s and early '00s. The notable exception is the ThinkPad. But IBM gave up on that with the sale to Lenovo in the early '00s. I think that x Series servers have been good all along, but they are through the nose prices compared to competitors. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On 3 Aug 2023, at 2:26 am, P H > <04843e86df79-dmarc-requ...@listserv.ua.edu> wrote: > > The numbers quoted by Tom: > > So I pointed out there's only 12 I/O drawers max on a z16 which is 12 x > 16 = 192 slots or 384 ports max. He replied, but didn't seem to fully > accept that answer. > > are 100% correct. These numbers are the MAXIMUM. Depending on the > configuration, these could be a lot less e.g. the number of coupling links > could reduce the numbers. If z16 is ordered with BPA power supplies, the MAX > I/O drawers go down from 12 to 10. > > I have already mentioned things like cache, memory, I/O Subsystem, on chip > data compression/Crypto (z has been a leader for this)/Sort/AI capabilities. Maybe for crypto but certainly not for AI. My iPhone has a more sophisticated AI engine than the z16. Other platforms have integrated AI engines, AMD ZenDNN, Intel oneDNN etc. Both ship with open source libraries and toolkits sadly lacking for z/OS. I noticed that IBM have shipped patched Python packages for TensorFlow and SnapML that exploit Telum for Linux on Z. I suppose like everything, we’ll have to wait a while for z/OS. Java 11 still does not utilise zEDC compression on z/OS. Talking about compression and crypto, Intel have hardware accelerators as part of QAT, either PCIe cards or on-die. You could argue that the compression tech is better than zEDC as it supports more formats then just gzip. https://www.intel.com/content/www/us/en/architecture-and-technology/intel-quick-assist-technology-overview.html > > Talking about the I/O Subsystem, this is a key strength when it comes to > handling large number of I/Os. Unlike x86, the I/O Subsystem handles this > very well and lets the CP get on with what it's mean to do. What no one has > mentioned is the 'processing' power of z. In addition to the main CPs (up to > 200 for z16 Models A01 and L01), the I/O Subsystem has up eo 192 POWER > processors. These are in a N+1 config making a total of 384 in he sub-system > alone. > > Impressive numbers. What do all these prove? Taken out of context, these are > meaningless. As I stated previously, one has to consisder the whole system. > This is where z has strengths. It has a 'balanced system design'. This > morning I decided to do a full virus scan on my 2 year old latop with an > Intel i5 chip. While the scan was running, I couldn't even open a 10 MB > Powerpoint presentation 🙁 (before the smartones give me their 2 cents worth, > I know I could have run the scan as a background task). > Get yourself a better machine. My Mac runs clusters of Linux systems on Kubernetes running stacks like Kafka, ELK at a full pelt without breaking a sweat and I can watch YouTube in 4K at the same time. For a more apples to apples comparison to x86 it would be more interesting to compare a z box to an HP Superdome kitted out with all the fruit. There are only three large systems remaining since Oracle killed off the SPARCs. Z, POWER and the super domes. The server market is dominated by single socket rack servers running distributed systems. > Talking about numbers, the Airbus A380 plane has been designed to have up to > 840 passengers. Are there any airlines with A380s which carry such numbers! > > Horses for courses!! > > > From: IBM Mainframe Discussion List on behalf of > Tom Brennan > Sent: 02 August 2023 17:34 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: The > IBM mainframe: How it runs and why it survives > >> I’ve missed this thread. > > He first said 1536 ports (not slots, not lanes) on a full z16. I asked > where he got that number. Response was there are 12 fanout slots on a > CEC drawer (true), so with 4 CEC drawers that's 48 fanout slots (true) > which means the 4 CEC drawers could address 48 I/O drawers with 16 cards > each and 2 ports per card = 1536 ports. > > So I pointed out there's only 12 I/O drawers max on a z16 which is 12 x > 16 = 192 slots or 384 ports max. He replied, but didn't seem to fully > accept that answer. > > Later he said there are 1600 slots (not ports, not lanes) on a z16 so I > asked where he got that new number. He said he meant 1536 slots (not > ports, not lanes) so the number doubled from last time. I replied same > as I did previously. > > Below, he said 1536 slots again. 1536 cards on a single z16 could be > over 3000 cables! I've had to untangle some 150+ cable rats nests, but > for that one I'd just say, Naw... I'm going home :) > > On 8/2/2023 1:53 AM, David Crayford wrote: >>> On 2 Aug 2023, at 12:15 pm, Tom Brennan wrote: >>&
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I seem to remember that action when working on a PDP11 using a VT100 terminal. It was as if the designers said, hey, you obviously want a CR in the middle of the line, so there you go. And to Linux users, TSO READY mode must look really odd when they find they can move the cursor to a previous command and press Enter, but nothing happens until they overtype at least one byte. We must look like nut cases sometimes :) On 8/3/2023 1:27 PM, Rahim Azizarab wrote: One of its oddities was that if you typed a line and happened to have the cursor before end of the line the right portion of the line was lost. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
When it comes to mainframes IBM is the standard setter as well as the established standard. I mostly worked on IBM systems; but at one point I worked on a UNISYS system that was essentially a weird adaptation of Linux. One of its oddities was that if you typed a line and happened to have the cursor before end of the line the right portion of the line was lost. The system was more of a mini computer than a real mainframe. IBM is the standard bearer in computer design even when it came to laptops, just see how well IBM designed the Thinkpads. regards; Rahim On Monday, July 31, 2023 at 10:40:31 AM CDT, Steve Thompson wrote: I just have to throw this in here. IBM is not the only maker of Mainframes. I understand that Fujitsu still makes mainframes. Does UNISYS still make mainframes? How about Honeywell Bull? Why don't we see these systems being discussed (or maybe I just don't frequent the right web sites)? Steve Thompson -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Oh, surely not! "Extremely rare", you must mean? Redundancy can spot errors, but not all. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* The use of Fashions in thought is to distract the attention of men from their real dangersThe game is to have them all running about with fire extinguishers whenever there is a flood, and all crowding to that side of the boat which is already nearly gunwale under. Thuscruel ages are put on their guard against Sentimentality, feckless and idle ones against Respectability, lecherous ones against Puritanism -advice to a tempter, from The Screwtape Letters by C S Lewis */ -Original Message----- From: IBM Mainframe Discussion List On Behalf Of Joel C. Ewing Sent: Thursday, August 3, 2023 13:48 The hardware is designed with redundancy to detect failuresUndetected hardware errors don't happen. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I hope so, because when I worked part-time with Unix/Linux from maybe 2003 to 2013, I used to have a joke, "If you get an error message that makes no sense at all, check if the disk is full." Not really a joke because about half the time a vague error occurred, that was the cause. When you make the application responsible for relaying common failures to the user or log, the app programmers tend to skip it. One of the good things about z/OS is you get an abend such as x37 by default, with no application logic necessary. On 8/3/2023 12:18 PM, Grant Taylor wrote: Aside: I think much of the Unix industry decided to move complexity and cost out of the hardware and instead put it into software that runs on more commodity / inexpensive hardware. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 8/3/23 12:47 PM, Joel C. Ewing wrote: The hardware is designed with redundancy to detect failures in components (processors, memory, I/O subsystems, interconnection cables), correct any resulting data errors where possible, retry a failed operation using different hardware components where appropriate, vary a failing component off line, and in many cases allow concurrent repair of failing components while production continues. Undetected hardware errors don't happen. Save for retrying a failed operation the rest of those statements weren't specific to IBM mainframes. I remember reading about a Unix server being demonstrated at a trade show that was running applications interactively wherein the demonstrators removed all but one CPU book from the system, reinserted the removed CPU books, then removed the one they hadn't removed, and then reinserted it. At a later demonstration they took a cup of water and pored it into the top of the system. What was running continued to run in both demonstrations. The real time demo programs didn't even stutter. What was obvious was that other non-real-time programs running on the system slowed down as the OS reacted to hardware going offline and rescheduling tasks on the remaining online CPUs. Monitoring agents lit up like a Christmas tree as they removed CPU books but became happier as they were re-inserted. My understanding was that this was a system that was shipping in the mid to late '90s and people were buying them. Thus not a demonstration special. I don't remember if this was an HP SuperDome running HP-UX or a Sun Enterprise 1 running Solaris. RAS is not specific to IBM. Though I do think that IBM trademarked the name / phrase. I'm not aware of any x86_64 servers being anywhere near this level of reliability. Aside: I think much of the Unix industry decided to move complexity and cost out of the hardware and instead put it into software that runs on more commodity / inexpensive hardware. Having a super reliable basket with all your eggs in it is still all your eggs in one basket. z/OS not only coordinates with the hardware when resources visible to z/OS are affected by failures and concurrent maintenance, it is also designed with the philosophy that software failures may occur within parts of the operating system, either from a hardware failure or a system software bug. System recovery routines exist to clean up after such failures, limit what running address spaces are affected, and allow production to continue in unaffected address spaces. I can't enumerate things, but I feel like non-mainframes have things that can speak to this. Another important feature of z/OS that requires some hardware coordination is the System Measurement Facility that gathers measurement of system activity and resource usage at a level to support performance tuning or billing based on resource usage. How much of SMF is hardware vs software? System accounting -- originally for billing -- has been used for a long time to provide information for system scaling. Aside from fact that z/OS is closed-source and only licensed by IBM to specific hardware, if you could somehow succeed in running it under Linux or on non-z hardware, it would lose the reliability, availability, and serviceability it gets from that hardware/software synergy that makes it an ideal production platform for critical workloads. There is an entire hobby genre doing exactly this. I absolutely agree that it does not have anywhere near the same RAS that z Series has. But I also realize that not everybody needs, much less is willing to pay for, such RAS features. It doesn't matter how reliable the single basket is if the network connectivity into the facility is cut. -- This is one of the places that having redundancy higher in the application stack and distributing load geographically starts to shine. An IBM mainframe is a very impressive system. A Cadillac is a very impressive car. But using an IBM mainframe to serve files in a small office is about as appropriate as using the Cadillac to deliver pizzas. -- Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Well written. Sent from Outlook for Android<https://aka.ms/AAb9ysg> From: IBM Mainframe Discussion List on behalf of Joel C. Ewing Sent: Thursday, August 3, 2023 6:47:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives There is a synergy that exists between z-architecture hardware and z/OS that has evolved over many decades. The hardware is designed with redundancy to detect failures in components (processors, memory, I/O subsystems, interconnection cables), correct any resulting data errors where possible, retry a failed operation using different hardware components where appropriate, vary a failing component off line, and in many cases allow concurrent repair of failing components while production continues. Undetected hardware errors don't happen. z/OS not only coordinates with the hardware when resources visible to z/OS are affected by failures and concurrent maintenance, it is also designed with the philosophy that software failures may occur within parts of the operating system, either from a hardware failure or a system software bug. System recovery routines exist to clean up after such failures, limit what running address spaces are affected, and allow production to continue in unaffected address spaces. An explicit part of the design philosophy is that applications running in different address spaces are isolated: a failure or bug in one application cannot induce a failure in some different application in a different address space, or induce a failure in the operating system itself. Another important feature of z/OS that requires some hardware coordination is the System Measurement Facility that gathers measurement of system activity and resource usage at a level to support performance tuning or billing based on resource usage. Aside from fact that z/OS is closed-source and only licensed by IBM to specific hardware, if you could somehow succeed in running it under Linux or on non-z hardware, it would lose the reliability, availability, and serviceability it gets from that hardware/software synergy that makes it an ideal production platform for critical workloads. Joel C Ewing On 8/2/23 22:28, Jon Perryman wrote: > > On Wednesday, August 2, 2023 at 06:24:15 AM PDT, Rick Troth > wrote: > >> I think Jon Perryman first asked us to define mainframe. And I bit! >> [voice of Leonard Bones McCoy] "Dammit Jon! I'm a software developer, >> not a field service engineer!" >> But it really started with Andrew Hudson at Ars Technica getting a >> number of facts wrong. > The ARS Technica story made me wonder z/OS people think there is more than a > design difference between z/OS on z and Linux on Intel. Unix was ported ot > z/OS. I want to know why people think z/OS couldn't be ported to Linux. There > are people here who consider the article mostly true. What makes people think > that is more than a philosophical design difference? Would IBM be relevant if > it used Linux design philosophy? > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Joel C. Ewing -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
There is a synergy that exists between z-architecture hardware and z/OS that has evolved over many decades. The hardware is designed with redundancy to detect failures in components (processors, memory, I/O subsystems, interconnection cables), correct any resulting data errors where possible, retry a failed operation using different hardware components where appropriate, vary a failing component off line, and in many cases allow concurrent repair of failing components while production continues. Undetected hardware errors don't happen. z/OS not only coordinates with the hardware when resources visible to z/OS are affected by failures and concurrent maintenance, it is also designed with the philosophy that software failures may occur within parts of the operating system, either from a hardware failure or a system software bug. System recovery routines exist to clean up after such failures, limit what running address spaces are affected, and allow production to continue in unaffected address spaces. An explicit part of the design philosophy is that applications running in different address spaces are isolated: a failure or bug in one application cannot induce a failure in some different application in a different address space, or induce a failure in the operating system itself. Another important feature of z/OS that requires some hardware coordination is the System Measurement Facility that gathers measurement of system activity and resource usage at a level to support performance tuning or billing based on resource usage. Aside from fact that z/OS is closed-source and only licensed by IBM to specific hardware, if you could somehow succeed in running it under Linux or on non-z hardware, it would lose the reliability, availability, and serviceability it gets from that hardware/software synergy that makes it an ideal production platform for critical workloads. Joel C Ewing On 8/2/23 22:28, Jon Perryman wrote: > On Wednesday, August 2, 2023 at 06:24:15 AM PDT, Rick Troth wrote: I think Jon Perryman first asked us to define mainframe. And I bit! [voice of Leonard Bones McCoy] "Dammit Jon! I'm a software developer, not a field service engineer!" But it really started with Andrew Hudson at Ars Technica getting a number of facts wrong. The ARS Technica story made me wonder z/OS people think there is more than a design difference between z/OS on z and Linux on Intel. Unix was ported ot z/OS. I want to know why people think z/OS couldn't be ported to Linux. There are people here who consider the article mostly true. What makes people think that is more than a philosophical design difference? Would IBM be relevant if it used Linux design philosophy? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
The YouTube is excellent in promoting key strengths of z in a light hearted manner. With numerours z systems on the test floor during development, testing and product and stress testing the patch panel is key to enable 'any to any' configurations. ____ From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: 03 August 2023 03:56 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives > On Wednesday, August 2, 2023 at 09:34:34 AM PDT, Tom Brennan wrote: > So I pointed out there's only 12 I/O drawers max on a z16 Sorry Tom and all. I don't recall anyone saying max of 12 I/O drawers otherwise it would have been obvious my number was wrong. Yahoo mail does strange things with tab, backspace, space and other keys. > which is 12 x 16 = 192 slots or 384 ports max. Thanks to youtube, the first IBM z I've seen was the z16 tour at https://youtu.be/ZDtaanCENbc. You say 192 slots or 384 ports. I understand slots being PCIe but was is ports? Is this fiber optic cables or does it somehow split a PCIe slot? > I've had to untangle some 150+ cable rats nests, but> for that one I'd just > say, Naw... I'm going home :) Towards the end of the video, they show the patch panels which are true rats nests. Looks like some of the network rooms I've seen. Some people don't mind dealing with a mess. -- 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: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 8/2/2023 7:56 PM, Jon Perryman wrote: You say 192 slots or 384 ports. Not me, it's IBM doc along with Parwez Hamid, top IBM tech person, redbook author, conference speaker, etc. etc. (retired now from IBM I believe). I understand slots being PCIe but was is ports? Is this fiber optic cables or does it somehow split a PCIe slot? IBM I/O cards almost all come with two plug ports, or SFP's, or whatever you want to call the spot where you plug in a cable. The only cards I can think of that only have one plug port are the 10G OSA cards. So that's why I said 384 ports MAX. And crypto cards have no plug ports. So if a machine has any of those, down goes that 384 max count. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On Wednesday, August 2, 2023 at 06:24:15 AM PDT, Rick Troth > wrote: > I think Jon Perryman first asked us to define mainframe. And I bit! > [voice of Leonard Bones McCoy] "Dammit Jon! I'm a software developer, > not a field service engineer!" > But it really started with Andrew Hudson at Ars Technica getting a > number of facts wrong. The ARS Technica story made me wonder z/OS people think there is more than a design difference between z/OS on z and Linux on Intel. Unix was ported ot z/OS. I want to know why people think z/OS couldn't be ported to Linux. There are people here who consider the article mostly true. What makes people think that is more than a philosophical design difference? Would IBM be relevant if it used Linux design philosophy? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On Wednesday, August 2, 2023 at 09:34:34 AM PDT, Tom Brennan wrote: > So I pointed out there's only 12 I/O drawers max on a z16 Sorry Tom and all. I don't recall anyone saying max of 12 I/O drawers otherwise it would have been obvious my number was wrong. Yahoo mail does strange things with tab, backspace, space and other keys. > which is 12 x 16 = 192 slots or 384 ports max. Thanks to youtube, the first IBM z I've seen was the z16 tour at https://youtu.be/ZDtaanCENbc. You say 192 slots or 384 ports. I understand slots being PCIe but was is ports? Is this fiber optic cables or does it somehow split a PCIe slot? > I've had to untangle some 150+ cable rats nests, but> for that one I'd just > say, Naw... I'm going home :) Towards the end of the video, they show the patch panels which are true rats nests. Looks like some of the network rooms I've seen. Some people don't mind dealing with a mess. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
615 passengers on a few planes. https://en.m.wikipedia.org/wiki/Seat_configurations_of_Airbus_A380 On Wed, Aug 2, 2023, 13:26 P H < 04843e86df79-dmarc-requ...@listserv.ua.edu> wrote: > The numbers quoted by Tom: > > So I pointed out there's only 12 I/O drawers max on a z16 which is 12 x > 16 = 192 slots or 384 ports max. He replied, but didn't seem to fully > accept that answer. > > are 100% correct. These numbers are the MAXIMUM. Depending on the > configuration, these could be a lot less e.g. the number of coupling links > could reduce the numbers. If z16 is ordered with BPA power supplies, the > MAX I/O drawers go down from 12 to 10. > > I have already mentioned things like cache, memory, I/O Subsystem, on chip > data compression/Crypto (z has been a leader for this)/Sort/AI capabilities. > > Talking about the I/O Subsystem, this is a key strength when it comes to > handling large number of I/Os. Unlike x86, the I/O Subsystem handles this > very well and lets the CP get on with what it's mean to do. What no one has > mentioned is the 'processing' power of z. In addition to the main CPs (up > to 200 for z16 Models A01 and L01), the I/O Subsystem has up eo 192 POWER > processors. These are in a N+1 config making a total of 384 in he > sub-system alone. > > Impressive numbers. What do all these prove? Taken out of context, these > are meaningless. As I stated previously, one has to consisder the whole > system. This is where z has strengths. It has a 'balanced system design'. > This morning I decided to do a full virus scan on my 2 year old latop with > an Intel i5 chip. While the scan was running, I couldn't even open a 10 MB > Powerpoint presentation 🙁 (before the smartones give me their 2 cents > worth, I know I could have run the scan as a background task). > > Talking about numbers, the Airbus A380 plane has been designed to have up > to 840 passengers. Are there any airlines with A380s which carry such > numbers! > > Horses for courses!! > > > From: IBM Mainframe Discussion List on behalf > of Tom Brennan > Sent: 02 August 2023 17:34 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Channelized I/O WAS: Mainframe Makers WAS: Ars Technica: > The IBM mainframe: How it runs and why it survives > > > I’ve missed this thread. > > He first said 1536 ports (not slots, not lanes) on a full z16. I asked > where he got that number. Response was there are 12 fanout slots on a > CEC drawer (true), so with 4 CEC drawers that's 48 fanout slots (true) > which means the 4 CEC drawers could address 48 I/O drawers with 16 cards > each and 2 ports per card = 1536 ports. > > So I pointed out there's only 12 I/O drawers max on a z16 which is 12 x > 16 = 192 slots or 384 ports max. He replied, but didn't seem to fully > accept that answer. > > Later he said there are 1600 slots (not ports, not lanes) on a z16 so I > asked where he got that new number. He said he meant 1536 slots (not > ports, not lanes) so the number doubled from last time. I replied same > as I did previously. > > Below, he said 1536 slots again. 1536 cards on a single z16 could be > over 3000 cables! I've had to untangle some 150+ cable rats nests, but > for that one I'd just say, Naw... I'm going home :) > > On 8/2/2023 1:53 AM, David Crayford wrote: > >> On 2 Aug 2023, at 12:15 pm, Tom Brennan > wrote: > >> > >>> The IBM z16 can have up to 1,536 PCIe+ slots > >> > >> I'm gonna quit explaining this and just say, "WRONG" every time you say > this as if it's a fact :) > > > > I’ve missed this thread. By 1,536 PCIe slots, that’s slots not lanes > right? Even if it were lanes that would be a ludicrous suggestions! That’s > so far fetched it’s laughable. The Redbook [1] is quite clear about I/O > configurations. What I find interesting is that the z16 seems to use PCIe > gen 3 and not gen 4 which doubles the transfer rate per lane. There must be > a good technical reason for this. > > > > [1] https://www.redbooks.ibm.com/redbooks/pdfs/sg248951.pdf > > > >> > >> On 8/1/2023 8:01 PM, Jon Perryman wrote: > >>> > On Tuesday, August 1, 2023 at 05:20:33 PM PDT, David Crayford < > dcrayf...@gmail.com> wrote: > >>>> What’s the difference between between channelized I/O and a rack of > >>>> x86 servers connected to a SAN using fibre channel driven by high > speed HBAs? > >>> PCIe was created specifically for PCs and IBM z16 chose to use that as > their only channel technology. Channelized I/O for PC has been available > for several
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Cray used a variety of front ens, including DG Supernova. From: IBM Mainframe Discussion List on behalf of Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, August 2, 2023 5:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives On 8/2/23 10:35 AM, Allan Staller wrote: > My vague recollection of the CRAY was that is used (at the time) > a 370/158 to buffer up all of the data so the CRAY could run full tilt. That may very well have been a possibility. I read that the CRAY used a CDC mainframe a it's front end for this purpose. But I would not be at all surprised if an IBM mainframe could function equivalently. -- Grant. . . . -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
A Cray-1 could use a CDC, or an IBM, or a VAX, and possibly others as front end processors. One cow orker in the dim recesses of my past had worked on the IBM Cray Station software before she went to work where I was. On Wed, Aug 2, 2023 at 4:02 PM Grant Taylor < 023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > On 8/2/23 10:35 AM, Allan Staller wrote: > > My vague recollection of the CRAY was that is used (at the time) > > a 370/158 to buffer up all of the data so the CRAY could run full tilt. > > That may very well have been a possibility. > > I read that the CRAY used a CDC mainframe a it's front end for this > purpose. > > But I would not be at all surprised if an IBM mainframe could function > equivalently. > > > > -- > Grant. . . . > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Steve Thompson wrote: >How about we change from Mainframe to zFrame? zFrame? ZFrame? Zframe? IBM keeps playing with case (remember, it's now "Db2", not "DB2") so even that's risky! >Yeah, I know, then when IBM comes up with a new Architecture... >How long will it take to need > 64bit addressing? Probably forever. 2**64 is, like, a shedload-the number of atoms in the solar system is estimated at 2**56 (actually 1.2x2**56, but, um, close enough). So even with Facebook, unlikely to be reached anytime soon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Seymour Cray worked for CDC before he founded Cray Research, so that makes sense. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Wed, Aug 2, 2023 at 5:02 PM Grant Taylor < 023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > On 8/2/23 10:35 AM, Allan Staller wrote: > > My vague recollection of the CRAY was that is used (at the time) > > a 370/158 to buffer up all of the data so the CRAY could run full tilt. > > That may very well have been a possibility. > > I read that the CRAY used a CDC mainframe a it's front end for this > purpose. > > But I would not be at all surprised if an IBM mainframe could function > equivalently. > > > > -- > Grant. . . . > > -- > 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 8/2/23 10:35 AM, Allan Staller wrote: My vague recollection of the CRAY was that is used (at the time) a 370/158 to buffer up all of the data so the CRAY could run full tilt. That may very well have been a possibility. I read that the CRAY used a CDC mainframe a it's front end for this purpose. But I would not be at all surprised if an IBM mainframe could function equivalently. -- Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Wow! I had completely forgotten about Cornerstone and FunSoft. But I had not known how they were doing what they did. I knew, at one time, they were trying to get the ESCON or FICON code (I guess they really meant license of patents). But IBM wasn't allowing it. Then IBM dumped the Tier 2 z/Series "partners" (like where I was at the time) and so I moved on and forgot about it all. But back on topic, I had not known of their use of zFrame. Grateful Dead: What a long strange trip its been. Steve Thompson On 8/2/2023 2:18 AM, Sebastian Welton wrote: On Tue, 1 Aug 2023 15:53:57 -0400, Steve Thompson wrote: How about we change from Mainframe to zFrame? Yeah, I know, then when IBM comes up with a new Architecture... How long will it take to need > 64bit addressing? Here you go: http://hammocktree.us/flexes/zFrameOV.pdf https://vtda.org/docs/computing/CornerstoneSystems/MVMUA_ZFrameSlideDeck_Oct2005.pdf Sebastian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Regards, Steve Thompson VS Strategies LLC Westfield IN 972-983-9430 cell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
The numbers quoted by Tom: So I pointed out there's only 12 I/O drawers max on a z16 which is 12 x 16 = 192 slots or 384 ports max. He replied, but didn't seem to fully accept that answer. are 100% correct. These numbers are the MAXIMUM. Depending on the configuration, these could be a lot less e.g. the number of coupling links could reduce the numbers. If z16 is ordered with BPA power supplies, the MAX I/O drawers go down from 12 to 10. I have already mentioned things like cache, memory, I/O Subsystem, on chip data compression/Crypto (z has been a leader for this)/Sort/AI capabilities. Talking about the I/O Subsystem, this is a key strength when it comes to handling large number of I/Os. Unlike x86, the I/O Subsystem handles this very well and lets the CP get on with what it's mean to do. What no one has mentioned is the 'processing' power of z. In addition to the main CPs (up to 200 for z16 Models A01 and L01), the I/O Subsystem has up eo 192 POWER processors. These are in a N+1 config making a total of 384 in he sub-system alone. Impressive numbers. What do all these prove? Taken out of context, these are meaningless. As I stated previously, one has to consisder the whole system. This is where z has strengths. It has a 'balanced system design'. This morning I decided to do a full virus scan on my 2 year old latop with an Intel i5 chip. While the scan was running, I couldn't even open a 10 MB Powerpoint presentation 🙁 (before the smartones give me their 2 cents worth, I know I could have run the scan as a background task). Talking about numbers, the Airbus A380 plane has been designed to have up to 840 passengers. Are there any airlines with A380s which carry such numbers! Horses for courses!! ____ From: IBM Mainframe Discussion List on behalf of Tom Brennan Sent: 02 August 2023 17:34 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives > I’ve missed this thread. He first said 1536 ports (not slots, not lanes) on a full z16. I asked where he got that number. Response was there are 12 fanout slots on a CEC drawer (true), so with 4 CEC drawers that's 48 fanout slots (true) which means the 4 CEC drawers could address 48 I/O drawers with 16 cards each and 2 ports per card = 1536 ports. So I pointed out there's only 12 I/O drawers max on a z16 which is 12 x 16 = 192 slots or 384 ports max. He replied, but didn't seem to fully accept that answer. Later he said there are 1600 slots (not ports, not lanes) on a z16 so I asked where he got that new number. He said he meant 1536 slots (not ports, not lanes) so the number doubled from last time. I replied same as I did previously. Below, he said 1536 slots again. 1536 cards on a single z16 could be over 3000 cables! I've had to untangle some 150+ cable rats nests, but for that one I'd just say, Naw... I'm going home :) On 8/2/2023 1:53 AM, David Crayford wrote: >> On 2 Aug 2023, at 12:15 pm, Tom Brennan wrote: >> >>> The IBM z16 can have up to 1,536 PCIe+ slots >> >> I'm gonna quit explaining this and just say, "WRONG" every time you say this >> as if it's a fact :) > > I’ve missed this thread. By 1,536 PCIe slots, that’s slots not lanes right? > Even if it were lanes that would be a ludicrous suggestions! That’s so far > fetched it’s laughable. The Redbook [1] is quite clear about I/O > configurations. What I find interesting is that the z16 seems to use PCIe gen > 3 and not gen 4 which doubles the transfer rate per lane. There must be a > good technical reason for this. > > [1] https://www.redbooks.ibm.com/redbooks/pdfs/sg248951.pdf > >> >> On 8/1/2023 8:01 PM, Jon Perryman wrote: >>> > On Tuesday, August 1, 2023 at 05:20:33 PM PDT, David Crayford >>> wrote: >>>> What’s the difference between between channelized I/O and a rack of >>>> x86 servers connected to a SAN using fibre channel driven by high speed >>>> HBAs? >>> PCIe was created specifically for PCs and IBM z16 chose to use that as >>> their only channel technology. Channelized I/O for PC has been available >>> for several decades and is not limited to PCIe. The IBM z16 can have up to >>> 1,536 PCIe+ slots. >>> As for x86 fiber channel connection to a PC, PCIe is only one possibility. >>> -- >>> 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 / si
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
A z/16 has a maximum I/O bandwidth of 128 GBps. The limitation is no the number of channels, but the bandwidth to memory. I don't know if the I/O bandwidth has any impact on processor access to memory, but my understanding is that there is little, if any. The z16 implementation allows one processor chip to access the cache in other processor chips. This helps to ensure integrity when one chip alters a memory location and another chip needs to access the same location. What happens in x86 architecture systems when one chip has data in cache that it alters and another chip needs to access the same location in the shared memory? What happens when a DMA I/O operation needs to access the same memory that is contained in a processor's cache? The hard part of designing an x86 system to handle very large amounts of I/O is the memory design, allowing the I/O subsystem to access large amounts of memory without impacting the processors. -- Tom Marchant On Wed, 2 Aug 2023 09:24:59 -0500, Grant Taylor wrote: >On 8/1/23 10:26 PM, David Crayford wrote: >> When you consider that a standard commodity rack server such as an >> AMD EPYC can support 128 PCIe lanes and up to 8 memory channels I >> would suggest x86 can handle a lot of I/O if you have the right gear. > >I think it's important to note that all of these are distinct and germane: > > - what the hardware can theoretically support > - what the OS can support > - what is asked of them > - what people are willing to pay for > >Having the right gear is very important. Effectively utilizing it is >also important. > >Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> I’ve missed this thread. He first said 1536 ports (not slots, not lanes) on a full z16. I asked where he got that number. Response was there are 12 fanout slots on a CEC drawer (true), so with 4 CEC drawers that's 48 fanout slots (true) which means the 4 CEC drawers could address 48 I/O drawers with 16 cards each and 2 ports per card = 1536 ports. So I pointed out there's only 12 I/O drawers max on a z16 which is 12 x 16 = 192 slots or 384 ports max. He replied, but didn't seem to fully accept that answer. Later he said there are 1600 slots (not ports, not lanes) on a z16 so I asked where he got that new number. He said he meant 1536 slots (not ports, not lanes) so the number doubled from last time. I replied same as I did previously. Below, he said 1536 slots again. 1536 cards on a single z16 could be over 3000 cables! I've had to untangle some 150+ cable rats nests, but for that one I'd just say, Naw... I'm going home :) On 8/2/2023 1:53 AM, David Crayford wrote: On 2 Aug 2023, at 12:15 pm, Tom Brennan wrote: The IBM z16 can have up to 1,536 PCIe+ slots I'm gonna quit explaining this and just say, "WRONG" every time you say this as if it's a fact :) I’ve missed this thread. By 1,536 PCIe slots, that’s slots not lanes right? Even if it were lanes that would be a ludicrous suggestions! That’s so far fetched it’s laughable. The Redbook [1] is quite clear about I/O configurations. What I find interesting is that the z16 seems to use PCIe gen 3 and not gen 4 which doubles the transfer rate per lane. There must be a good technical reason for this. [1] https://www.redbooks.ibm.com/redbooks/pdfs/sg248951.pdf On 8/1/2023 8:01 PM, Jon Perryman wrote: > On Tuesday, August 1, 2023 at 05:20:33 PM PDT, David Crayford wrote: What’s the difference between between channelized I/O and a rack of x86 servers connected to a SAN using fibre channel driven by high speed HBAs? PCIe was created specifically for PCs and IBM z16 chose to use that as their only channel technology. Channelized I/O for PC has been available for several decades and is not limited to PCIe. The IBM z16 can have up to 1,536 PCIe+ slots. As for x86 fiber channel connection to a PC, PCIe is only one possibility. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Classification: Confidential I must disagree here. This is just a different implementation of the existing z architecture. There may be some minor omissions, but I see nothing new here. FLEX has been around for quite a while, and was always about z-emulation on an x86 chip. It does provide some low-end relief for those that require less than the minimum z/16 horsepower. My USD 0.02 worth. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sebastian Welton Sent: Wednesday, August 2, 2023 1:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don't click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] On Tue, 1 Aug 2023 15:53:57 -0400, Steve Thompson wrote: >How about we change from Mainframe to zFrame? > >Yeah, I know, then when IBM comes up with a new Architecture... >How long will it take to need > 64bit addressing? > > Here you go: http://hammocktree.us/flexes/zFrameOV.pdf https://vtda.org/docs/computing/CornerstoneSystems/MVMUA_ZFrameSlideDeck_Oct2005.pdf Sebastian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Classification: Confidential Than sounds suspiciously like a "channel" on the mainframe (pick your favorite protocol). -Original Message----- From: IBM Mainframe Discussion List On Behalf Of Grant Taylor Sent: Tuesday, August 1, 2023 9:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] On 8/1/23 7:20 PM, David Crayford wrote: > What’s the difference between between channelized I/O and a rack of > x86 servers connected to a SAN using fibre channel driven by high > speed HBAs? I don't know. My understanding is that Fibre Channel is an evolution of SCSI which is supposedly a somewhat intelligent controller wherein the OS asks said controller to fetch / store some data for it. As I understand it, the OS & main CPU aren't involved in the transfer beyond asking the controller to do the transfer on it's behalf. I'd have to reference documentation to see if / how much Direct Memory Access comes into play vs the CPU's involvement in the transfer to / from the controller. But between the controller and the back end drive, as I understand it, the CPU ins't involved. So I can't say that "a rack of x86 servers connected to a SAN using fibre channel" isn't using channelized I/O. I think in many ways they are. This is a place where minutia matters. Grnat. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Classification: Confidential My vague recollection of the CRAY was that is used (at the time) a 370/158 to buffer up all of the data so the CRAY could run full tilt. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Grant Taylor Sent: Tuesday, August 1, 2023 5:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] On 8/1/23 3:10 PM, Rick Troth wrote: > Look for channelized I/O, Didn't supers ~> cray use channelized I/O? Also, I feel like there is another slippery slope discussion of what is channelized I/O in this context. > then other physical attributes (not just size, not just the > instruction set). Please elaborate on what "other physical attributes" means. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
At the risk of being "WRONG" ;¬)) several times, I offer the following. The Processor Units (GPs, CPU, etc.) are PCIe Gen 4, but the 16 slots in the I/O drawer hold Gen 3 cards, up to 16 of them at 16GBps. Each card can support a max of 32 lanes which can be multiplexed. The max theoretical transmission per lane with encoding is 984.6 MBps, and per link is 15.75 GBpsm. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 8/1/23 10:26 PM, David Crayford wrote: When you consider that a standard commodity rack server such as an AMD EPYC can support 128 PCIe lanes and up to 8 memory channels I would suggest x86 can handle a lot of I/O if you have the right gear. I think it's important to note that all of these are distinct and germane: - what the hardware can theoretically support - what the OS can support - what is asked of them - what people are willing to pay for Having the right gear is very important. Effectively utilizing it is also important. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 8/1/23 22:42, Grant Taylor wrote: On 8/1/23 7:20 PM, David Crayford wrote: What’s the difference between between channelized I/O and a rack of x86 servers connected to a SAN using fibre channel driven by high speed HBAs? I don't know. My understanding is that Fibre Channel is an evolution of SCSI which is supposedly a somewhat intelligent controller wherein the OS asks said controller to fetch / store some data for it. As I understand it, the OS & main CPU aren't involved in the transfer beyond asking the controller to do the transfer on it's behalf. SCSI originally had much more limited scale ... by design. The acronym expands to "small computer system interface". I haven't read-up on the details of FCP, but I do suspect it follows SCSI yet with dramatically relaxed limits. Operationally, FCP appears to be a lot like FICON, and that's channelz. I'd have to reference documentation to see if / how much Direct Memory Access comes into play vs the CPU's involvement in the transfer to / from the controller. DMA is significant. True: PCs have had DMA in corner cases for a long time. DMA is part of the equation. But between the controller and the back end drive, as I understand it, the CPU ins't involved. Right. A channel processor for an IBM-class "mainframe" operates independently of the CPU(s) other than being triggered when a CPU says "go run this channel program" and effectively "don't bother me until you're done". So I can't say that "a rack of x86 servers connected to a SAN using fibre channel" isn't using channelized I/O. I think in many ways they are. This is a place where minutia matters. If the CPUs are truly free to continue their own work until SAN fibre channel independently completes its work, that sounds like a mainframe class channel. Grnat. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN These things can be hard to pin down. Labeling is sometimes counter-productive. In the automotive industry, is the vehicle a sedan or a van or a mini-van or an SUV or a truck? So in the auto industry, we hear "cross over". [sigh] I think Jon Perryman first asked us to define mainframe. And I bit! [voice of Leonard Bones McCoy] "Dammit Jon! I'm a software developer, not a field service engineer!" But it really started with Andrew Hudson at Ars Technica getting a number of facts wrong. -- R; <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On 2 Aug 2023, at 12:15 pm, Tom Brennan wrote: > > > The IBM z16 can have up to 1,536 PCIe+ slots > > I'm gonna quit explaining this and just say, "WRONG" every time you say this > as if it's a fact :) I’ve missed this thread. By 1,536 PCIe slots, that’s slots not lanes right? Even if it were lanes that would be a ludicrous suggestions! That’s so far fetched it’s laughable. The Redbook [1] is quite clear about I/O configurations. What I find interesting is that the z16 seems to use PCIe gen 3 and not gen 4 which doubles the transfer rate per lane. There must be a good technical reason for this. [1] https://www.redbooks.ibm.com/redbooks/pdfs/sg248951.pdf > > On 8/1/2023 8:01 PM, Jon Perryman wrote: >> > On Tuesday, August 1, 2023 at 05:20:33 PM PDT, David Crayford >> wrote: >>> What’s the difference between between channelized I/O and a rack of >>> x86 servers connected to a SAN using fibre channel driven by high speed >>> HBAs? >> PCIe was created specifically for PCs and IBM z16 chose to use that as their >> only channel technology. Channelized I/O for PC has been available for >> several decades and is not limited to PCIe. The IBM z16 can have up to 1,536 >> PCIe+ slots. >> As for x86 fiber channel connection to a PC, PCIe is only one possibility. >> -- >> 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On Wed, 2 Aug 2023 01:18:53 -0500, Sebastian Welton wrote: >On Tue, 1 Aug 2023 15:53:57 -0400, Steve Thompson wrote: > >>How about we change from Mainframe to zFrame? >> >>Yeah, I know, then when IBM comes up with a new Architecture... >>How long will it take to need > 64bit addressing? >> >> > >Here you go: > >http://hammocktree.us/flexes/zFrameOV.pdf > >https://vtda.org/docs/computing/CornerstoneSystems/MVMUA_ZFrameSlideDeck_Oct2005.pdf > I forgot, the z14 had a Z Frame too: https://en.wikichip.org/wiki/ibm/microarchitectures/z14 Sebastian. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On Tue, 1 Aug 2023 15:53:57 -0400, Steve Thompson wrote: >How about we change from Mainframe to zFrame? > >Yeah, I know, then when IBM comes up with a new Architecture... >How long will it take to need > 64bit addressing? > > Here you go: http://hammocktree.us/flexes/zFrameOV.pdf https://vtda.org/docs/computing/CornerstoneSystems/MVMUA_ZFrameSlideDeck_Oct2005.pdf Sebastian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On Tue, 1 Aug 2023 23:09:15 +0200, Radoslaw Skorupka wrote: >This is former Siemens product, very similar to IBM mainframe. >I saw such machine around 2001 in National Bank of Austria. >Connected to Symmetrix CKD DASD using ESCON channels. >There was at least one installation in Poland. However it was popular in >DACH countries (Deutschland, Austria, Confederiatio Helvetica). >Now it is as moribound as Nec - Bull - GE - Honeywell Gecos. > Not quite as dead as people think, I know of a few still in Germany and then there is this one in the UK: https://www.datacenterdynamics.com/en/news/fujitsu-retains-mainframe-support-contract-for-uks-police-national-computer/ The latest user group meeting in May: https://server41.der-moderne-verein.de/portal/veranstaltungsmanager/index_direkt.php?MANDANT_KEY=635cb726889f125958900974e9ea6d26&ELN_KEY=f34eea1fe3c96348d5d0911e8ebc8c2b Sebastian. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> The IBM z16 can have up to 1,536 PCIe+ slots I'm gonna quit explaining this and just say, "WRONG" every time you say this as if it's a fact :) On 8/1/2023 8:01 PM, Jon Perryman wrote: > On Tuesday, August 1, 2023 at 05:20:33 PM PDT, David Crayford wrote: What’s the difference between between channelized I/O and a rack of x86 servers connected to a SAN using fibre channel driven by high speed HBAs? PCIe was created specifically for PCs and IBM z16 chose to use that as their only channel technology. Channelized I/O for PC has been available for several decades and is not limited to PCIe. The IBM z16 can have up to 1,536 PCIe+ slots. As for x86 fiber channel connection to a PC, PCIe is only one possibility. -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Take for example an Emulex (Broadcom) HBA. The quad port adapter can handle up to 10M IOPS with a throughput rate of 12,800MB/s full duplex using 16-lane PCIe which utilities DMA. All I/O is offloaded, interrupts, multiplexing etc. When you consider that a standard commodity rack server such as an AMD EPYC can support 128 PCIe lanes and up to 8 memory channels I would suggest x86 can handle a lot of I/O if you have the right gear. https://docs.broadcom.com/doc/LPe35000-LPe36000-PB > On 2 Aug 2023, at 10:42 am, Grant Taylor > <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > > On 8/1/23 7:20 PM, David Crayford wrote: >> What’s the difference between between channelized I/O and a rack of x86 >> servers connected to a SAN using fibre channel driven by high speed HBAs? > > I don't know. > > My understanding is that Fibre Channel is an evolution of SCSI which is > supposedly a somewhat intelligent controller wherein the OS asks said > controller to fetch / store some data for it. As I understand it, the OS & > main CPU aren't involved in the transfer beyond asking the controller to do > the transfer on it's behalf. > > I'd have to reference documentation to see if / how much Direct Memory Access > comes into play vs the CPU's involvement in the transfer to / from the > controller. > > But between the controller and the back end drive, as I understand it, the > CPU ins't involved. > > So I can't say that "a rack of x86 servers connected to a SAN using fibre > channel" isn't using channelized I/O. I think in many ways they are. > > This is a place where minutia matters. > > > > Grnat. . . . > > -- > 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
Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On Tuesday, August 1, 2023 at 05:20:33 PM PDT, David Crayford > wrote: > What’s the difference between between channelized I/O and a rack of > x86 servers connected to a SAN using fibre channel driven by high speed HBAs? PCIe was created specifically for PCs and IBM z16 chose to use that as their only channel technology. Channelized I/O for PC has been available for several decades and is not limited to PCIe. The IBM z16 can have up to 1,536 PCIe+ slots. As for x86 fiber channel connection to a PC, PCIe is only one possibility. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 8/1/23 7:20 PM, David Crayford wrote: What’s the difference between between channelized I/O and a rack of x86 servers connected to a SAN using fibre channel driven by high speed HBAs? I don't know. My understanding is that Fibre Channel is an evolution of SCSI which is supposedly a somewhat intelligent controller wherein the OS asks said controller to fetch / store some data for it. As I understand it, the OS & main CPU aren't involved in the transfer beyond asking the controller to do the transfer on it's behalf. I'd have to reference documentation to see if / how much Direct Memory Access comes into play vs the CPU's involvement in the transfer to / from the controller. But between the controller and the back end drive, as I understand it, the CPU ins't involved. So I can't say that "a rack of x86 servers connected to a SAN using fibre channel" isn't using channelized I/O. I think in many ways they are. This is a place where minutia matters. Grnat. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
What’s the difference between between channelized I/O and a rack of x86 servers connected to a SAN using fibre channel driven by high speed HBAs? > On 2 Aug 2023, at 6:53 am, Grant Taylor > <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > > On 8/1/23 3:10 PM, Rick Troth wrote: >> Look for channelized I/O, > > Didn't supers ~> cray use channelized I/O? > > Also, I feel like there is another slippery slope discussion of what is > channelized I/O in this context. > >> then other physical attributes (not just size, not just the instruction set). > > Please elaborate on what "other physical attributes" means. > > > > Grant. . . . > > -- > 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 8/1/23 3:10 PM, Rick Troth wrote: Look for channelized I/O, Didn't supers ~> cray use channelized I/O? Also, I feel like there is another slippery slope discussion of what is channelized I/O in this context. then other physical attributes (not just size, not just the instruction set). Please elaborate on what "other physical attributes" means. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I do not recall Multi-core cpus being part of the initial z/arch disclosure in 1979 when I was at that special meeting in POK for CA. The ideas of the G3 chipset was announced about 2001 at another disclosure meeting I went to in NY (forgot the name of the town, it was not POK) given by Bob Rogers. S/390 v2.10 and z/OS 1.1 were discussed and Bob said the two were so close to each other he would have had to look at the CVT prefix to know which OS was running on that machine. Wasn't it the z14s that initially had "dual" core processing for the zIIPs and IFLs? Eventually the zAAPs became zIIPs So many changes, that I just can't remember all of them. Steve Thompson On 8/1/2023 5:44 PM, Jon Perryman wrote: > On Tuesday, August 1, 2023 at 12:54:10 PM PDT, Steve Thompson wrote: when IBM comes up with a new Architecture... AFAIK, IBM z is not a new architecture. Intel, Sun & HP invented multi-core CPU chips. Intel invented PCI and PCIe. What is the new architecture that IBM z introduced? How long will it take to need > 64bit addressing? 64 bit data adressing already exists. As for programs, does anyone think they can write a 4TB ( 64 bit ) program? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Regards, Steve Thompson VS Strategies LLC Westfield IN 972-983-9430 cell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
> On Tuesday, August 1, 2023 at 12:54:10 PM PDT, Steve Thompson > wrote: > when IBM comes up with a new Architecture... AFAIK, IBM z is not a new architecture. Intel, Sun & HP invented multi-core CPU chips. Intel invented PCI and PCIe. What is the new architecture that IBM z introduced? > How long will it take to need > 64bit addressing? 64 bit data adressing already exists. As for programs, does anyone think they can write a 4TB ( 64 bit ) program? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
W dniu 01.08.2023 o 19:52, Phil Smith III pisze: Sebastian Welton wrote: https://www.fujitsu.com/de/products/computing/servers/mainframe/bs2000/ Heh heh, "BS2000". Reminds me of the company that bought the NOMAD product: Select Business Systems; their domain was SelectBS.com. Wow, make that "is", it lives: https://selectbs.com/products/nomad/ This is former Siemens product, very similar to IBM mainframe. I saw such machine around 2001 in National Bank of Austria. Connected to Symmetrix CKD DASD using ESCON channels. There was at least one installation in Poland. However it was popular in DACH countries (Deutschland, Austria, Confederiatio Helvetica). Now it is as moribound as Nec - Bull - GE - Honeywell Gecos. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I've been told by some sales folks not to use the M-word when talking about LinuxONE. I feel like HAL keeping secrets from the crew of Discovery One. No relation to Linux One - or is there? On 8/1/2023 12:44 PM, Phil Smith III wrote: Jon Perryman wrote: The last Fujitsu mainframe is scheduled for 2030 and dropping all support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are now x86 based. Are these mainframes or are they PCs? PCframes? mainCs? It is hard to define rigorously, but as someone else quoted SCOTUS, "I know it when I see it". In common use, I'd argue (not very vociferously, I admit) that only IBM machines-and maybe Fujitsus-are really mainframes: The others are just very large computers. But this may be due entirely by the fact that I have to explain to sales reps on a regular basis that our z/OS support means IBM machines, not Unisys or whatever! -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I had a brief exposure to Burroughs machines in the mid-1970s. I would say that the B6700 was definitely a mainframe, as well as the B6800 that followed it. I've never worked with any Univac mainframes, nor am I familiar with the current line from Unisys. It has been said here that the current Unisys machines use x86 processors. I don't consider that to be relevant in discussing whether or not they are mainframes. IOW, whether or not anyone is doing it, it is possible to design a mainframe using commodity processors, x86 or otherwise. -- Tom Marchant On Tue, 1 Aug 2023 16:10:48 -0400, Rick Troth wrote: >On balance, I encountered a Unisys machine, with the instruction set of >a much older system (which might have been a mainframe in its time) >which was definitely *not* a mainframe (because the contemporary box >just did not fit the class). >So Unisis machines not so much. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I don't know what you mean, Mike. Access Registers (introduced with ESA/390) do not point to pages or bytes, but to address spaces or data spaces. -- Tom Marchant On Tue, 1 Aug 2023 15:09:01 -0500, Mike Schwab wrote: >Of course ¿ESA? did create access registers that point to 4K pages instead >of bytes, so 8/16 TB was possible. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
An access register points (indirectly) to an entire address space, not just a page. From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Tuesday, August 1, 2023 4:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives On 40TB main memory now, so only 20,480 x since 1999 intro of 64 in 24 years. Of course ¿ESA? did create access registers that point to 4K pages instead of bytes, so 8/16 TB was possible. On Tue, Aug 1, 2023, 14:54 Steve Thompson wrote: > How about we change from Mainframe to zFrame? > > Yeah, I know, then when IBM comes up with a new Architecture... > How long will it take to need > 64bit addressing? > > Steve Thompson > > On 8/1/2023 3:44 PM, Phil Smith III wrote: > > Jon Perryman wrote: > >> The last Fujitsu mainframe is scheduled for 2030 and dropping all > >> support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are > >> now x86 based. Are these mainframes or are they PCs? > > PCframes? mainCs? It is hard to define rigorously, but as someone else > quoted SCOTUS, "I know it when I see it". > > > > In common use, I'd argue (not very vociferously, I admit) that only IBM > machines-and maybe Fujitsus-are really mainframes: The others are just very > large computers. But this may be due entirely by the fact that I have to > explain to sales reps on a regular basis that our z/OS support means IBM > machines, not Unisys or whatever! > > > > > > -- > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 8/1/23 15:44, Phil Smith III wrote: Jon Perryman wrote: The last Fujitsu mainframe is scheduled for 2030 and dropping all support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are now x86 based. Are these mainframes or are they PCs? PCframes? mainCs? It is hard to define rigorously, but as someone else quoted SCOTUS, "I know it when I see it". In common use, I'd argue (not very vociferously, I admit) that only IBM machines-and maybe Fujitsus-are really mainframes: The others are just very large computers. But this may be due entirely by the fact that I have to explain to sales reps on a regular basis that our z/OS support means IBM machines, not Unisys or whatever! Fujitsu machines following S/370 architecture are mainframes. Amdahl machines were definitely mainframes. Look for channelized I/O, then other physical attributes (not just size, not just the instruction set). It's not difficult, and it's not merely cultural. On balance, I encountered a Unisys machine, with the instruction set of a much older system (which might have been a mainframe in its time) which was definitely *not* a mainframe (because the contemporary box just did not fit the class). So Unisis machines not so much. -- R; <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 40TB main memory now, so only 20,480 x since 1999 intro of 64 in 24 years. Of course ¿ESA? did create access registers that point to 4K pages instead of bytes, so 8/16 TB was possible. On Tue, Aug 1, 2023, 14:54 Steve Thompson wrote: > How about we change from Mainframe to zFrame? > > Yeah, I know, then when IBM comes up with a new Architecture... > How long will it take to need > 64bit addressing? > > Steve Thompson > > On 8/1/2023 3:44 PM, Phil Smith III wrote: > > Jon Perryman wrote: > >> The last Fujitsu mainframe is scheduled for 2030 and dropping all > >> support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are > >> now x86 based. Are these mainframes or are they PCs? > > PCframes? mainCs? It is hard to define rigorously, but as someone else > quoted SCOTUS, "I know it when I see it". > > > > In common use, I'd argue (not very vociferously, I admit) that only IBM > machines-and maybe Fujitsus-are really mainframes: The others are just very > large computers. But this may be due entirely by the fact that I have to > explain to sales reps on a regular basis that our z/OS support means IBM > machines, not Unisys or whatever! > > > > > > -- > > 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
How about we change from Mainframe to zFrame? Yeah, I know, then when IBM comes up with a new Architecture... How long will it take to need > 64bit addressing? Steve Thompson On 8/1/2023 3:44 PM, Phil Smith III wrote: Jon Perryman wrote: The last Fujitsu mainframe is scheduled for 2030 and dropping all support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are now x86 based. Are these mainframes or are they PCs? PCframes? mainCs? It is hard to define rigorously, but as someone else quoted SCOTUS, "I know it when I see it". In common use, I'd argue (not very vociferously, I admit) that only IBM machines-and maybe Fujitsus-are really mainframes: The others are just very large computers. But this may be due entirely by the fact that I have to explain to sales reps on a regular basis that our z/OS support means IBM machines, not Unisys or whatever! -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Jon Perryman wrote: >The last Fujitsu mainframe is scheduled for 2030 and dropping all >support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are >now x86 based. Are these mainframes or are they PCs? PCframes? mainCs? It is hard to define rigorously, but as someone else quoted SCOTUS, "I know it when I see it". In common use, I'd argue (not very vociferously, I admit) that only IBM machines-and maybe Fujitsus-are really mainframes: The others are just very large computers. But this may be due entirely by the fact that I have to explain to sales reps on a regular basis that our z/OS support means IBM machines, not Unisys or whatever! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Sebastian Welton wrote: >https://www.fujitsu.com/de/products/computing/servers/mainframe/bs2000/ Heh heh, "BS2000". Reminds me of the company that bought the NOMAD product: Select Business Systems; their domain was SelectBS.com. Wow, make that "is", it lives: https://selectbs.com/products/nomad/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
https://www.fujitsu.com/de/products/computing/servers/mainframe/bs2000/ Sebastian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
My first job at Packard Electric, we had 2 mainframes, 1 for production, a NAS 9000, and 1 for development, a NAS 6650. Sent from Yahoo Mail for iPhone On Monday, July 31, 2023, 7:40 PM, Steve Thompson wrote: Something that I read (in one post or another) indicated, to me, that Fujitsu was buying Amdahl machines. Wasn't pointing fingers. I know that Fujitsu owned 40% of Amdahl in the late 80s when I got hired. It was a sad day when they exercised their right to buy the rest of Amdahl. I lost money on that taking. I think I still have an Amdahl stock certificate somewhere. Steve Thompson On 7/31/2023 6:54 PM, Phil Smith III wrote: > Steve Thompson wrote, in part: >> Fujitsu did not "buy" Amdahl machines > If you were replying to me, note that I didn't say they bought Amdahl > machines; I said they bought Amdahl: > "Fujitsu agreed to acquire the 58 percent of Amdahl Corporation (including > the Canada-based DMR consulting group) that it did not already own for around > $850 million in July 1997." > https://www.nytimes.com/1997/07/31/business/fujitsu-to-pay-850-million-to-acquire-rest-of-amdahl.html > > And thanks to those reminding me it was the z800 that Hitachi built for IBM. > I had about the right period in my wee brain but couldn't remember which > machine! > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Regards, Steve Thompson VS Strategies LLC Westfield IN 972-983-9430 cell -- 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: [External] : Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I actually traveled to Japan to work on an Amdahl machine installed there. We visited the factory where the base machines were built and then sent to Amdahl for their modifications. My time at Amdahl was fantastic. Best technology (PERIOD) and some of the best people I ever worked with. We pushed like crazy to have Fujitsu move from 31-bit to 64-bit and keep competing with the new CMOS machines. However, FJs fascination with high-end unix ended that dream. I left Amdahl/Fujitsu America after a small amount of time working on the unit stuff. Jon Nolting System Administrator Engineering IT jon.nolt...@oracle.com 425-295-1733 (Cell) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Monday, July 31, 2023 4:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] : Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives On Mon, 31 Jul 2023 16:29:22 -0400, Steve Thompson wrote: >Fujitsu did not "buy" Amdahl machines, Phil didn't say that Fujitsu bought Amdahl machines. He said that they bought Amdahl. This is true. >Fujitsu supplied Amdahl with their machines I worked for Amdahl too, from 1978 to 1984. I started as a field Systems Engineer, often finding and occasionally fixing bugs in MVS. When MVS abended on an Amdahl machine, IBM would take the position that it must be the hardware, unless the customer could reproduce it in an IBM machine.Then I cross-trained to hardware, then an SE Specialist. During that time frame, Fujitsu did not supply Amdahl with their machines. Amdahl designed and built their own machines. IIRC Amdahl designed the chips. I don't remember who fabricated the chips, but it might have been Fujitsu. Probably other components were supplied by Fujitsu as well. >with the MODs we (yeah, I worked for Amdahl >prior to 1990) asked for/needed, and then for instructions we >didn't have micro-store for, Micro-store? There was no micro-store on the 470 or 580 (5850,5860, 5870 and 5880) systems. All instructions were implemented entirely in hardware. On the 470 series, that caused Amdahl to be at a disadvantage when IBM added new instructions. Instead, Amdahl used software emulation for the new instructions. The first of these was MVS/SE Assist, an enhancement to the Program Interruption First-Level Interrupt Handler. It would detect the PIC 1 and emulate the instruction in software if it was something that it handled. The 580 had a radical new design. During a three month stint at headquarters, I worked with the 580 console project and I had my own, numbered and registered copy of the ALTA Principles of operation. Among other things, it defined a mechanism to permit another level of virtualization, allowing 4 Domains to be defined and mapping System storage to domain storage. Sometimes I wish I had "forgotten" to return it when I left... To manage it, there was a new state, System state, in addition to Problem and Supervisor state. System state registers registers for use only when in System state. Special System state instructions to do things like moving data between the normal registers and the system state registers. The design included 31 or 32 bit memory (I forget which) and a much improved channel subsystem. When 370/XA came out a year or two later, I looked in the XA POO for anything that didn't more or less fit in the ALTA design and didn't find anything. Macrocode ran in System state IIRC it was loaded into System storage by the console processor. The console on the 580 was a separate 370 processor on one MCC that ran the UTS flavor of Unix. That was my first exposure to Unix. Macrocode mapped System storage to domain storage and system channels to domain channels. All interruptions went through Macrocode. New instructions could be simulated by Macrocode >we used FAM (Fast Assist Mode) which >we then emulated instructions (part of MacroCode). > ... > >And I still think my time at Amdahl was the best job and >education in machine hardware I could have ever had for the short >time I was there. Same here. And the training was top notch. -- Tom Marchant -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Something that I read (in one post or another) indicated, to me, that Fujitsu was buying Amdahl machines. Wasn't pointing fingers. I know that Fujitsu owned 40% of Amdahl in the late 80s when I got hired. It was a sad day when they exercised their right to buy the rest of Amdahl. I lost money on that taking. I think I still have an Amdahl stock certificate somewhere. Steve Thompson On 7/31/2023 6:54 PM, Phil Smith III wrote: Steve Thompson wrote, in part: Fujitsu did not "buy" Amdahl machines If you were replying to me, note that I didn't say they bought Amdahl machines; I said they bought Amdahl: "Fujitsu agreed to acquire the 58 percent of Amdahl Corporation (including the Canada-based DMR consulting group) that it did not already own for around $850 million in July 1997." https://www.nytimes.com/1997/07/31/business/fujitsu-to-pay-850-million-to-acquire-rest-of-amdahl.html And thanks to those reminding me it was the z800 that Hitachi built for IBM. I had about the right period in my wee brain but couldn't remember which machine! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Regards, Steve Thompson VS Strategies LLC Westfield IN 972-983-9430 cell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On Mon, 31 Jul 2023 16:29:22 -0400, Steve Thompson wrote: >Fujitsu did not "buy" Amdahl machines, Phil didn't say that Fujitsu bought Amdahl machines. He said that they bought Amdahl. This is true. >Fujitsu supplied Amdahl with their machines I worked for Amdahl too, from 1978 to 1984. I started as a field Systems Engineer, often finding and occasionally fixing bugs in MVS. When MVS abended on an Amdahl machine, IBM would take the position that it must be the hardware, unless the customer could reproduce it in an IBM machine.Then I cross-trained to hardware, then an SE Specialist. During that time frame, Fujitsu did not supply Amdahl with their machines. Amdahl designed and built their own machines. IIRC Amdahl designed the chips. I don't remember who fabricated the chips, but it might have been Fujitsu. Probably other components were supplied by Fujitsu as well. >with the MODs we (yeah, I worked for Amdahl >prior to 1990) asked for/needed, and then for instructions we >didn't have micro-store for, Micro-store? There was no micro-store on the 470 or 580 (5850,5860, 5870 and 5880) systems. All instructions were implemented entirely in hardware. On the 470 series, that caused Amdahl to be at a disadvantage when IBM added new instructions. Instead, Amdahl used software emulation for the new instructions. The first of these was MVS/SE Assist, an enhancement to the Program Interruption First-Level Interrupt Handler. It would detect the PIC 1 and emulate the instruction in software if it was something that it handled. The 580 had a radical new design. During a three month stint at headquarters, I worked with the 580 console project and I had my own, numbered and registered copy of the ALTA Principles of operation. Among other things, it defined a mechanism to permit another level of virtualization, allowing 4 Domains to be defined and mapping System storage to domain storage. Sometimes I wish I had "forgotten" to return it when I left... To manage it, there was a new state, System state, in addition to Problem and Supervisor state. System state registers registers for use only when in System state. Special System state instructions to do things like moving data between the normal registers and the system state registers. The design included 31 or 32 bit memory (I forget which) and a much improved channel subsystem. When 370/XA came out a year or two later, I looked in the XA POO for anything that didn't more or less fit in the ALTA design and didn't find anything. Macrocode ran in System state IIRC it was loaded into System storage by the console processor. The console on the 580 was a separate 370 processor on one MCC that ran the UTS flavor of Unix. That was my first exposure to Unix. Macrocode mapped System storage to domain storage and system channels to domain channels. All interruptions went through Macrocode. New instructions could be simulated by Macrocode >we used FAM (Fast Assist Mode) which >we then emulated instructions (part of MacroCode). > ... > >And I still think my time at Amdahl was the best job and >education in machine hardware I could have ever had for the short >time I was there. Same here. And the training was top notch. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
The last Fujitsu mainframe is scheduled for 2030 and dropping all support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are now x86 based. Are these mainframes or are they PCs? On Monday, July 31, 2023 at 08:40:25 AM PDT, Steve Thompson wrote: I just have to throw this in here. IBM is not the only maker of Mainframes. I understand that Fujitsu still makes mainframes. Does UNISYS still make mainframes? How about Honeywell Bull? Why don't we see these systems being discussed (or maybe I just don't frequent the right web sites)? Steve Thompson -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Steve Thompson wrote, in part: >Fujitsu did not "buy" Amdahl machines If you were replying to me, note that I didn't say they bought Amdahl machines; I said they bought Amdahl: "Fujitsu agreed to acquire the 58 percent of Amdahl Corporation (including the Canada-based DMR consulting group) that it did not already own for around $850 million in July 1997." https://www.nytimes.com/1997/07/31/business/fujitsu-to-pay-850-million-to-acquire-rest-of-amdahl.html And thanks to those reminding me it was the z800 that Hitachi built for IBM. I had about the right period in my wee brain but couldn't remember which machine! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I remember that class. Not from Amdahl though. I took it from IBM. Lots of good information which stayed with you. Another one like that was MVS Performance. We went to 909 3rd Avenue, NYC for that one. Took the train from New Haven. Bill Hitefield Dino-Software Corporation 800.480.DINO www.dino-software.com > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Steve Thompson > Sent: Monday, July 31, 2023 5:50 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How > it runs and why it survives > > I had to take the MVS Structure and Flow class as part of my job. > It was 2 weeks long and I felt numb after that drink from a fire hose. But > what I > learned there I have been using ever since anytime I was doing low level > programming as a developer. > > Steve Thompson > > > > On 7/31/2023 5:02 PM, Jay Maynard wrote: > > Me too. I learned more in the MVS Internals course I took from Amdahl > > than any other mainframe class. Really sharp folks. > > > > On Mon, Jul 31, 2023, 16:50 Tom Brennan > wrote: > > > >> I went to some Amdahl MVS internal classes around 1990. The > >> instructors were probably previous IBMers, and just seemed so relaxed > >> having fun teaching. I had a great couple of weeks and learned tons. > >> > >> On 7/31/2023 1:29 PM, Steve Thompson wrote: > >>> And I still think my time at Amdahl was the best job and education > >>> in machine hardware I could have ever had for the short time I was there. > >> - > >> - 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Just the z800! Regards Parwez Hamid From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: 31 July 2023 22:33 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Makers WAS: Ars Technica: The IBM mainframe: How it runs and why it survives On Mon, 31 Jul 2023 14:33:26 -0400, Phil Smith III wrote: >I also STR that Fujitsu builds some of IBM's stuff, which doesn't mean >anything much but is sorta interesting, maybe. IIRC it was Hitachi that built the z800 and z890 using IBM chips. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ________ From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: 31 July 2023 22:33 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives On Mon, 31 Jul 2023 14:33:26 -0400, Phil Smith III wrote: >I also STR that Fujitsu builds some of IBM's stuff, which doesn't mean >anything much but is sorta interesting, maybe. IIRC it was Hitachi that built the z800 and z890 using IBM chips. -- Tom Marchant -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I had to take the MVS Structure and Flow class as part of my job. It was 2 weeks long and I felt numb after that drink from a fire hose. But what I learned there I have been using ever since anytime I was doing low level programming as a developer. Steve Thompson On 7/31/2023 5:02 PM, Jay Maynard wrote: Me too. I learned more in the MVS Internals course I took from Amdahl than any other mainframe class. Really sharp folks. On Mon, Jul 31, 2023, 16:50 Tom Brennan wrote: I went to some Amdahl MVS internal classes around 1990. The instructors were probably previous IBMers, and just seemed so relaxed having fun teaching. I had a great couple of weeks and learned tons. On 7/31/2023 1:29 PM, Steve Thompson wrote: And I still think my time at Amdahl was the best job and education in machine hardware I could have ever had for the short time I was there. -- 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On Mon, 31 Jul 2023 14:33:26 -0400, Phil Smith III wrote: >I also STR that Fujitsu builds some of IBM's stuff, which doesn't mean >anything much but is sorta interesting, maybe. IIRC it was Hitachi that built the z800 and z890 using IBM chips. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Me too. I learned more in the MVS Internals course I took from Amdahl than any other mainframe class. Really sharp folks. On Mon, Jul 31, 2023, 16:50 Tom Brennan wrote: > I went to some Amdahl MVS internal classes around 1990. The instructors > were probably previous IBMers, and just seemed so relaxed having fun > teaching. I had a great couple of weeks and learned tons. > > On 7/31/2023 1:29 PM, Steve Thompson wrote: > > And I still think my time at Amdahl was the best job and education in > > machine hardware I could have ever had for the short time I was there. > > -- > 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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I went to some Amdahl MVS internal classes around 1990. The instructors were probably previous IBMers, and just seemed so relaxed having fun teaching. I had a great couple of weeks and learned tons. On 7/31/2023 1:29 PM, Steve Thompson wrote: And I still think my time at Amdahl was the best job and education in machine hardware I could have ever had for the short time I was there. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
Fujitsu did not "buy" Amdahl machines, Fujitsu supplied Amdahl with their machines with the MODs we (yeah, I worked for Amdahl prior to 1990) asked for/needed, and then for instructions we didn't have micro-store for, we used FAM (Fast Assist Mode) which we then emulated instructions (part of MacroCode). It was interesting, IBM had no idea that Amdahl had a new processor and was caught flat footed when we announced the 5990 machines and breaking the 100 MIP barrier. So they added another frame to the 3990s for 2 more processors to get over 100MIPS. And then they announced ESA. Some of those who were allowed to have the direct doc from IBM said they got the idea ESA really stood for Eat dung Amdahl. Bob Rogers really had a laugh at that when I told him about that discussion. At any rate, we had enough micro store we could free up that the 5995A boxes could run ESA faster than the 3090 machines. And I can't remember for sure, but I think the 5890s were able to run at the same speed as the 3090s when doing ESA. The 5890s had to emulate ESA instructions. If Amdahl management had pushed forward into CMOS earlier and stopped trying to dance with being a super UNIX system, or being a software company, or a communications company, etc. and didn't go through silly lay offs, things might have been very different today. We knew that we were going to need more RAM so 31bit wasn't going to work much longer if we wanted to run with more than 4 Domains (LPARs in IBM speak) with each of them having 1GB of RAM. To be honest I didn't see that at the time, but I came to understand later the issues for varying RAM on and off for an LPAR while working at ACS on WYLBUR. And I still think my time at Amdahl was the best job and education in machine hardware I could have ever had for the short time I was there. Steve Thompson On 7/31/2023 2:33 PM, Phil Smith III wrote: See https://en.wikipedia.org/wiki/Amdahl_Corporation#Fujitsu_GS21 - Fujitsu machines are 31-bit, based on the technology they got when they bought Amdahl. I also STR that Fujitsu builds some of IBM's stuff, which doesn't mean anything much but is sorta interesting, maybe. If you google "fujitsu osiv" you'll find a lot more than you likely want to know. ObAnecdote: back in the day (mid-80s) we had a plug-compatible mainframe, a Formation 4000, on which we ran our small (~30-person) software company, VM Systems Group, including sales support systems, development, and, well, just about everything; I think when I started there was maybe one PC in the office. Our Formation was the high-end, an (approximately) 0.25MIPS attached processor machine with a whopping 4MB! It was.not fast. And had occasional fun problems, like the time that a previously unnoticed poor solder on a board somehow decided to matter after an IML (perhaps because the IML was most likely caused after the room was shut down because the A/C failed and it had gotten very hot-so maybe the solder joint flowed a bit?) and the 64K memory chips were misdetected as 16K chips. The machine was kind of unhappy that it couldn't find the other 3MB. We replaced that box with one of the first 9370s, upgrading to 0.5MIPS (though uniprocessor) and 16MB. Now that was livin' large! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Regards, Steve Thompson VS Strategies LLC Westfield IN 972-983-9430 cell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
W dniu 31.07.2023 o 20:33, Phil Smith III pisze: See https://en.wikipedia.org/wiki/Amdahl_Corporation#Fujitsu_GS21 - Fujitsu machines are 31-bit, based on the technology they got when they bought Amdahl. I also STR that Fujitsu builds some of IBM's stuff, which doesn't mean anything much but is sorta interesting, maybe. If you google "fujitsu osiv" you'll find a lot more than you likely want to know. Several years ago I had an opportunity to implement StorageTek tapes in mainframe (and distributed) environment. BTW, at the time it was the largest tape installation in Poland. I was hired by Sun (they bought STK), because they had no skills here. However they delivered me manuals. Project Manager with no mainframe background. So I'd got a lot of junk, including implementation manuals for Fujitsu MSP. Due to some communication issues I started reading it - regular JCL, started tasks, PARMLIB, PROCLIB, etc. There were differences in TCPIP. Finally I got proper manuals and stopped learning MSP system. ;-) BTW: There is also Hitachi MVS clone as well. AFAIK it is VOS3. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives
Robert Crawford asked: >Was the 2260 keyboard the one with two, count 'em, two PF keys? .which reminds me of my favorite bit of IBM trivia: What IBM device had exactly *13* PF keys? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
See https://en.wikipedia.org/wiki/Amdahl_Corporation#Fujitsu_GS21 - Fujitsu machines are 31-bit, based on the technology they got when they bought Amdahl. I also STR that Fujitsu builds some of IBM's stuff, which doesn't mean anything much but is sorta interesting, maybe. If you google "fujitsu osiv" you'll find a lot more than you likely want to know. ObAnecdote: back in the day (mid-80s) we had a plug-compatible mainframe, a Formation 4000, on which we ran our small (~30-person) software company, VM Systems Group, including sales support systems, development, and, well, just about everything; I think when I started there was maybe one PC in the office. Our Formation was the high-end, an (approximately) 0.25MIPS attached processor machine with a whopping 4MB! It was.not fast. And had occasional fun problems, like the time that a previously unnoticed poor solder on a board somehow decided to matter after an IML (perhaps because the IML was most likely caused after the room was shut down because the A/C failed and it had gotten very hot-so maybe the solder joint flowed a bit?) and the 64K memory chips were misdetected as 16K chips. The machine was kind of unhappy that it couldn't find the other 3MB. We replaced that box with one of the first 9370s, upgrading to 0.5MIPS (though uniprocessor) and 16MB. Now that was livin' large! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On Mon, 31 Jul 2023 10:54:28 -0500, Grant Taylor wrote: >> Why don't we see these systems being discussed (or maybe I just don't >> frequent the right web sites)? >I suspect it's /where/ we are talking. This list, IBM territory reddit.com/r/mainframe/ does occasionally get some Unisys discussion. Only mention of Fujitsu I found was just about a storage device, though. ¬R -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
On 7/31/23 10:40 AM, Steve Thompson wrote: I just have to throw this in here. IBM is not the only maker of Mainframes. Nicely done. :-) I understand that Fujitsu still makes mainframes. That's my understanding too. Does UNISYS still make mainframes? My understanding is that UNISYS is now primarily service on very large x86(_64) based systems. I think they were one of the companies that made x86 systems in the late '90s / early '00s that were massively multi-CPU systems. as in they (and the likes) are the reason Windows NT / 2000 support up to 32 CPUs. How about Honeywell Bull? I don't remember seeing anything about Honeywell computers in a LONG time. Why don't we see these systems being discussed (or maybe I just don't frequent the right web sites)? I suspect it's /where/ we are talking. This list, IBM territory (if I can use such a loose comparison), geographic region, business region, etc. Aren't Fujitsu much bigger in the Asia Pacific market? Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives
I just have to throw this in here. IBM is not the only maker of Mainframes. I understand that Fujitsu still makes mainframes. Does UNISYS still make mainframes? How about Honeywell Bull? Why don't we see these systems being discussed (or maybe I just don't frequent the right web sites)? Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives
The 2260 had no function keys. The 3270 was available with half a dozen keyboard arrangements, with no, five or 12 function keys. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Crawford Robert C (Contractor) [04e08f385650-dmarc-requ...@listserv.ua.edu] Sent: Monday, July 31, 2023 9:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives 480 characters? Sounds like Twitter. Was the 2260 keyboard the one with two, count 'em, two PF keys? Robert Crawford Abstract Evolutions LLC (210) 913-3822 -Original Message- From: IBM Mainframe Discussion List On Behalf Of billogden Sent: Saturday, July 29, 2023 11:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives >From:Seymour J Metz >Yep, "Model 1 displays 480 characters (12 rows of 40 characters)." >Did you have keyboard issues? My memory of those ancient history days (early 70s) simply fails too much. I seem to remember "something" simple we did with the keyboard, but the details have vanished. (And I am probably confusing it with the 2260 keyboards from a few years earlier!) Bill Ogden -- 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: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives
480 characters? Sounds like Twitter. Was the 2260 keyboard the one with two, count 'em, two PF keys? Robert Crawford Abstract Evolutions LLC (210) 913-3822 -Original Message- From: IBM Mainframe Discussion List On Behalf Of billogden Sent: Saturday, July 29, 2023 11:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives >From:Seymour J Metz >Yep, "Model 1 displays 480 characters (12 rows of 40 characters)." >Did you have keyboard issues? My memory of those ancient history days (early 70s) simply fails too much. I seem to remember "something" simple we did with the keyboard, but the details have vanished. (And I am probably confusing it with the 2260 keyboards from a few years earlier!) Bill Ogden -- 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: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives
>From:Seymour J Metz >Yep, "Model 1 displays 480 characters (12 rows of 40 characters)." >Did you have keyboard issues? My memory of those ancient history days (early 70s) simply fails too much. I seem to remember "something" simple we did with the keyboard, but the details have vanished. (And I am probably confusing it with the 2260 keyboards from a few years earlier!) Bill Ogden -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives
Hah! That's just what I say about Windows WordPad; it does most of what I need (until my writing gets a lot fancier; for serious documentation I use a markup language) without weighing me down with too much bloatware. I may be the only use in the country that uses WordPad much, though. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Always look in the oven before you turn it on. -from "Things I've learned from my children" */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of billogden Sent: Friday, July 28, 2023 10:11 >OS/VS1 did have some things that MVS did not. I liked it because, in many ways, it was as simple as could be but still did the job needed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives
Yep, "Model 1 displays 480 characters (12 rows of 40 characters)." Did you have keyboard issues? ____ From: IBM Mainframe Discussion List on behalf of billogden Sent: Friday, July 28, 2023 10:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives Comment for Seymour: > By the time the 370/148 came out 3270s were old hat. Not in all parts of the world! >3270-1? Did you mean 3277-1? I never saw one in the flesh, and it was way too small. Sorry, I used the "generic" 3270 instead of the specific "3277". Yes, the model 1 had a very small screen. My memory is not good, but I think it was 12x40. >OS/VS1 did have some things that MVS did not. I liked it because, in many ways, it was as simple as could be but still did the job needed. Bill Ogden -- 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