Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

2023-08-08 Thread David Crayford
> 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

2023-08-07 Thread Timothy Sipples
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

2023-08-06 Thread Seymour J Metz
> 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

2023-08-05 Thread Jack Zukt
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

2023-08-04 Thread Tom Marchant
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

2023-08-04 Thread Bob Bridges
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

2023-08-04 Thread Jon Perryman
 > 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

2023-08-04 Thread Jon Perryman
 > 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

2023-08-04 Thread Bob Bridges
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

2023-08-04 Thread Schmitt, Michael
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

2023-08-04 Thread Tom Marchant
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

2023-08-04 Thread Bob Bridges
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

2023-08-04 Thread Tom Marchant
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

2023-08-04 Thread Seymour J Metz
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

2023-08-04 Thread Bob Bridges
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

2023-08-04 Thread P H
Data Processing, most probably from DP division of IBM of that time.

Sent from Outlook for Android

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
> 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 
> 

Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

2023-08-04 Thread P H
My mistake, the 370/195 had 2 MB, this customer's 360/75 had 1 MB

Sent from Outlook for Android

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
> 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 
> 

Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

2023-08-04 Thread Seymour J Metz
> 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 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 

Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

2023-08-04 Thread P H
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.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. 

Re: Channelized I/O WAS: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

2023-08-04 Thread David Crayford
> 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

2023-08-03 Thread Jon Perryman
> 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

2023-08-03 Thread Timothy Sipples
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

2023-08-03 Thread Bob Bridges
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

2023-08-03 Thread Bob Bridges
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

2023-08-03 Thread Grant Taylor

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

2023-08-03 Thread David Crayford
> 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:
>>> 
 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 

Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

2023-08-03 Thread Tom Brennan
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

2023-08-03 Thread Rahim Azizarab
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

2023-08-03 Thread Bob Bridges
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

2023-08-03 Thread Tom Brennan
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

2023-08-03 Thread Grant Taylor

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

2023-08-03 Thread P H
Well written.

Sent from Outlook for Android

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

2023-08-03 Thread Joel C. Ewing
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

2023-08-03 Thread P H
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

2023-08-03 Thread Tom Brennan

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

2023-08-02 Thread Jon Perryman
 > 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

2023-08-02 Thread Jon Perryman
 > 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

2023-08-02 Thread Mike Schwab
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 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 

Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

2023-08-02 Thread Seymour J Metz
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

2023-08-02 Thread Jay Maynard
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

2023-08-02 Thread Phil Smith III
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

2023-08-02 Thread Mike Shaw
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

2023-08-02 Thread Grant Taylor

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

2023-08-02 Thread Steve Thompson

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

2023-08-02 Thread P H
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 / 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 

Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

2023-08-02 Thread Tom Marchant
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

2023-08-02 Thread Tom Brennan

> 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

2023-08-02 Thread Allan Staller
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

2023-08-02 Thread Allan Staller
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

2023-08-02 Thread Allan Staller
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

2023-08-02 Thread Jon Butler
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

2023-08-02 Thread Grant Taylor

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

2023-08-02 Thread Rick Troth

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

2023-08-02 Thread David Crayford
> 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

2023-08-02 Thread Sebastian Welton
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

2023-08-02 Thread Sebastian Welton
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

2023-08-02 Thread Sebastian Welton
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_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

2023-08-01 Thread Tom Brennan

> 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

2023-08-01 Thread David Crayford
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

2023-08-01 Thread Jon Perryman
 > 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

2023-08-01 Thread Grant Taylor

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

2023-08-01 Thread David Crayford
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

2023-08-01 Thread Grant Taylor

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

2023-08-01 Thread Steve Thompson
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

2023-08-01 Thread Jon Perryman
 > 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

2023-08-01 Thread Radoslaw Skorupka

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

2023-08-01 Thread Tom Brennan
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

2023-08-01 Thread Tom Marchant
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

2023-08-01 Thread Tom Marchant
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

2023-08-01 Thread Seymour J Metz
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

2023-08-01 Thread Rick Troth

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

2023-08-01 Thread Mike Schwab
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

2023-08-01 Thread Steve Thompson

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

2023-08-01 Thread Phil Smith III
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

2023-08-01 Thread Phil Smith III
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

2023-08-01 Thread Sebastian Welton
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

2023-07-31 Thread Bill Johnson
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

2023-07-31 Thread Jon Nolting
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

2023-07-31 Thread Steve Thompson
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

2023-07-31 Thread Tom Marchant
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

2023-07-31 Thread Jon Perryman
 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

2023-07-31 Thread Phil Smith III
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

2023-07-31 Thread Bill Hitefield
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

2023-07-31 Thread P H
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

2023-07-31 Thread Steve Thompson
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

2023-07-31 Thread Tom Marchant
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

2023-07-31 Thread Jay Maynard
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

2023-07-31 Thread Tom Brennan
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

2023-07-31 Thread Steve Thompson
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

2023-07-31 Thread Radoslaw Skorupka

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: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

2023-07-31 Thread Phil Smith III
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

2023-07-31 Thread Glenn Knickerbocker
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

2023-07-31 Thread Grant Taylor

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

2023-07-31 Thread Steve Thompson

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