date:20230522


On 22/5/2023 11:22 pm, Rick Troth wrote:

Rex is right.
Linux (Z or otherwise) is a different operating system. And it's "full 
ASCII".


USS, also known as OMVS, has been an integral part of MVS (now known 
as z/OS) since the mid 1990s.
IBM has put more and more function into USS, even moving things from 
the "traditional" side.
USS is really an excellent piece of work, even though it does speak 
EBCDIC. (Which, being Unix in every other way, really confuses 
newcomers.)


USS is bi-modal as are the C/C++ compilers. I run everything in USS in 
ASCII mode. All of Rocket and IBMs z/OS UNIX ports are in ASCII.





A growing number of people do in fact buy their first mainframe and 
run Linux on it. They can go native (LPAR) or on top of z/VM. But 
that's not USS (with or without VM).


Z hardware is phenomenal. There's nothing like it. From time to time, 
a potential customer will recognize the value of that hardware, 
regardless what software workload they anticipate.
Of course, if they want the data moving power of a diesel locomotive, 
they should go with z/OS. But for lots of other workloads, they'll 
want Linux. No problem!


Not just I/O bandwidth. One of the real differentiators is that Z can 
run at 100%. There is an excellent blog by Bob Rogers which explains how 
this achieved.


https://blog.share.org/Article/how-does-ibm-z-achieve-efficiency-at-exceedingly-high-utilization-rates




Just ... watch out ... be wary of the folks who mislabel it "Linux for 
z/OS". Even with more than 20 years of "Linux for Z", there are still 
many people out there who cannot separate z/OS the operating system 
from Z hardware.


Does zCX constitute "Linux for z/OS"? z/OS (zCX) is the hypervisor and 
it's running s390x Linux containers. I've been working with a RedHat OCP 
cluster running on z/OS which is interesting.





-- R; <><


On 5/22/23 10:40, Pommier, Rex wrote:

Hi Bob,

Linux on Z and OMVS are 2 completely different animals.  OMVS is an 
integral part of z/OS (try running TCP/IP without it for example).  
zLinux is a completely separate operating system, running in an LPAR 
or on top of VM just like another OS image. Another difference is 
that OMVS (as part of z/OS) runs EBCDIC where I believe zLinux is a 
full ASCII OS running on the z hardware.


Rex

From: IBM Mainframe Discussion List  on 
behalf of Bob Bridges 

Sent: Monday, May 22, 2023 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Are Banks Breaking Up With Mainframes? | Forbes

Wait, did I misunderstand this?  People buy their first mainframe and 
run Linux on it?!


(Color me ignorant, but I've always thought of OMVS as a late add-on.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313


--
The information contained in this message is confidential, protected 
from disclosure and may be legally privileged. If the reader of this 
message is not the intended recipient or an employee or agent 
responsible for delivering this message to the intended recipient, 
you are hereby notified that any disclosure, distribution, copying, 
or any action taken or action omitted in reliance on it, is strictly 
prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to 
this message and destroy the material in its entirety, whether in 
electronic or hard copy format. Thank you.


--
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: Architectural questions [WAS: Are Banks Breaking Up With Mainframes? | Forbes]

Good question. By bus size I'm assuming that your referring to
cache-lines? I wonder how much of a difference that makes with OOO
pipelines? What I can confirm is that my new Arm M2 MacBook Pro which
has a 32-byte cache-line sizes absolutely smashes my AMD Ryzen 5 in
Cinebench benchmarks.

On 22/5/2023 8:26 pm, Steve Thompson wrote:

I have a question about these systems, both z and not z.

What is the current bus width supported?

At the G3 level for "z" the CPU-RAM bus was 256 bytes wide, as I recall.

For IOP to RAM it was 64 bytes wide.

For the systems I run (off the shelf stuff for Linux and windows) the
bus is still at 64bits (8 bytes). Yes it has bus mastering, and
pathing to allow certain adapter cards to use 8bit "channels"

z/Arch POP has instructions for interrogating the bus sizes. I haven't
had the time or opportunity to write any tests using this to find out
what those bus sizes are it would report on.

Steve Thompson

On 5/22/2023 7:52 AM, David Crayford wrote:

On 22/5/2023 1:26 pm, Attila Fogarasi wrote:
Good point about NUMAand it is still a differentiator and
competitive

advantage for IBM z.

How is NUMA a competitive advantage for z? Superdomes use Intel
UltraPath Interconnect (UPI) links that can do glueless NUMA.

IBM bought Sequent 20+ years ago to get their
excellent NUMA technology, and has since built some very clever cache
topology and management algorithms. AMD has historically been
crippled in

real-world performance due to cache inefficiencies.

What historical generation of AMD silicon was crippled? The EPYC
supports up to 384MB of L3 cache and the specs and benchmarks suggest
the chiplet architecture can easily handle the I/O.

10 years ago CICS was at 30 billion transactions per day, so
volume has tripled in 10 years, during the massive growth of cloud.
Healthy indeed.

I have a different perspective on what constitutes healthy. Here in
Australia, I've had the opportunity to meet architects from various
banks who are actively involved in or have completed the process of
migrating the read side of their CICS transactions to distributed
systems. They have embraced technologies like CDC and streaming
platforms such as Apache Kafka and distributed data stores such as
Cassandra and MongoDb. This shift has been primarily driven by
disruptive technologies like mobile banking pushing up mainframe
software costs.

This is a common architectural pattern.

https://www.conferencecast.tv/talk-29844-nationwide-building-society-building-mobile-applications-and-a-speed-layer-with-mongodb#.talkPage-header

On Mon, May 22, 2023 at 2:56 PM David Crayford
wrote:

Sent again in plain text. Apple mail is too clever for it’s own good!

On 22 May 2023, at 12:46 pm, David Crayford
wrote:

On 21 May 2023, at 12:52 pm, Howard
Rifkind

wrote:
Hundreds of PC type servers still can’t handle the huge amount of
data

like a mainframe can.

Of course, that's an absurd statement! By "PC type," I assume you're
referring to x86? We can easily break this down. First things
first, let's

forget about the "hundreds" requirement. A 32 single socket system is
enough to match up.

AMD EPYC is the poster child for single socket servers, running its
novel
chiplet technology on a 5nm process node. AMD's infinity
interconnects are

capable of massive I/O bandwidth. You can learn more about it here:
https://www.amd.com/en/technologies/infinity-architecture. Each socket
can have a maximum of 96 cores, but even if we use a conservative
64 cores
per socket, that's a scale-out of 2048 cores. AMD also has
accelerators for

offload encryption/compression, etc.

DEFLATE. You can find more information here:
https://www.intel.com.au/content/www/au/en/architecture-and-technology/intel-quick-assist-technology-overview.html

A more apples-to-apples comparison would be the HP Superdome Flex,
which
is a large shared memory system lashed together with NUMA
interconnects,

with a whopping 32 sockets and a maximum core count of 896 on a single
vertically integrated system. HP Enterprise has technology such as
nPars,

which is similar to PR/SM. They claim 99.999% availability on a single
system and even beyond when clustered.

details about it here:
https://www.nextplatform.com/2023/05/18/ampere-gets-out-in-front-of-x86-with-192-core-siryn-ampereone/

Re: Are you serious about wanting a better IBM doc RCF-type process?

+1000

On Mon, May 22, 2023 at 7:59 PM Steve Thompson  wrote:

> +1 to what Mike and Charles have said.
>
> And I too have done much of what Mike said below over the past 40
> years.
>
> Things wrong in RTM relative to SRBs and FRRs. Fairly recently I
> found a bug in ESPIE. I've reported doc that is wrong about
> Macros, or the Macro is wrong relative to the doc. Or the sample
> can't be copied because the way the PDF is built, the copy for
> paste doesn't work right.
>
> BPXDYN2 -- Showed them where the COBOL samples were going to
> confuse newbie COBOL programmers.
>
> I have had arguments with IBM management on some of these
> subjects as a contractor, client and employee.
>
> BTW -- I did vote for Peter's RFE. What an ordeal to get an
> account to be able to vote on an RFE.
>
> Steve Thompson
>
>
>
> On 5/22/2023 6:33 PM, Mike Shaw wrote:
> > +1
> >
> > I have been working with IBM z/OS documentation for over 40 years and
> have
> > submitted many reader comment forms in that time. In that time I have
> found
> > and reported typographical errors, inconsistencies, obsolete information,
> > and even flat-out WRONG statements.
> >
> > Without real-world feedback from z/OS professionals who actually USE the
> > documentation, it's accuracy and usability will not improve.
> >
> > IBM has good technical documentation writers but they are NOT end-users.
> >
> > Eliminating RCFs disconnects authors of the documentation from consumers
> of
> > the documentation...NOT a good idea.
> >
> > Mike Shaw
> > MVS/QuickRef Support Group
> > Chicago-Soft, Ltd.
> >
> > On Mon, May 22, 2023, 6:05 PM Charles Mills  wrote:
> >
> >> For those who have not been following this discussion, IBM is on track
> to
> >> remove the RCF process as we have known it for forty or so years.
> Customers
> >> and ISVs will be limited to a Web pop-up “Was this helpful?” and if you
> >> answer No, you will be able to briefly justify that answer. There is
> also
> >> apparently now no path whatsoever for a customer to open a requirement
> >> against IBM documentation.
> >>
> >> We need a way to provide formatted suggestions for improvements,
> >> clarifications or corrections to IBM manuals.
> >>
> >> If you would like that, then wishing and hoping and grumping will not
> make
> >> it happen. Here is what might make it happen:
> >>
> >> - You could start by replying with a simple +1 to this post. The IBM
> >> powers that be do not participate in this forum, but there is strong
> >> evidence that what happens here sometimes percolates in that direction.
> >> - You could vote for Peter Farley’s RFE. Find it here:
> >>
> https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3691
> >> (apologies for any fold).
> >> - If you have an IBM rep at your shop, you could let him or her know. If
> >> you simply know an IBMer you could tell him or her nicely.
> >> - If you have contacts who are responsible at your shop for other
> products
> >> such as the languages, Db2, CICS, MQ and so forth, you could try to get
> >> them to chime in. Apparently one of the pushbacks from the documentation
> >> team is “IBM has 1200 products and our process works fine for all of
> them –
> >> what’s wrong with you z/OS people?”
> >>
> >> Thank you.
> >> Charles
> >>
> >> --
> >> 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
>


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

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

Re: Are you serious about wanting a better IBM doc RCF-type process?

2023-05-22 Thread Steve Thompson


+1 to what Mike and Charles have said.

And I too have done much of what Mike said below over the past 40 
years.


Things wrong in RTM relative to SRBs and FRRs. Fairly recently I 
found a bug in ESPIE. I've reported doc that is wrong about 
Macros, or the Macro is wrong relative to the doc. Or the sample 
can't be copied because the way the PDF is built, the copy for 
paste doesn't work right.


BPXDYN2 -- Showed them where the COBOL samples were going to 
confuse newbie COBOL programmers.


I have had arguments with IBM management on some of these 
subjects as a contractor, client and employee.


BTW -- I did vote for Peter's RFE. What an ordeal to get an 
account to be able to vote on an RFE.


Steve Thompson



On 5/22/2023 6:33 PM, Mike Shaw wrote:

+1

I have been working with IBM z/OS documentation for over 40 years and have
submitted many reader comment forms in that time. In that time I have found
and reported typographical errors, inconsistencies, obsolete information,
and even flat-out WRONG statements.

Without real-world feedback from z/OS professionals who actually USE the
documentation, it's accuracy and usability will not improve.

IBM has good technical documentation writers but they are NOT end-users.

Eliminating RCFs disconnects authors of the documentation from consumers of
the documentation...NOT a good idea.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

On Mon, May 22, 2023, 6:05 PM Charles Mills  wrote:


For those who have not been following this discussion, IBM is on track to
remove the RCF process as we have known it for forty or so years. Customers
and ISVs will be limited to a Web pop-up “Was this helpful?” and if you
answer No, you will be able to briefly justify that answer. There is also
apparently now no path whatsoever for a customer to open a requirement
against IBM documentation.

We need a way to provide formatted suggestions for improvements,
clarifications or corrections to IBM manuals.

If you would like that, then wishing and hoping and grumping will not make
it happen. Here is what might make it happen:

- You could start by replying with a simple +1 to this post. The IBM
powers that be do not participate in this forum, but there is strong
evidence that what happens here sometimes percolates in that direction.
- You could vote for Peter Farley’s RFE. Find it here:
https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3691
(apologies for any fold).
- If you have an IBM rep at your shop, you could let him or her know. If
you simply know an IBMer you could tell him or her nicely.
- If you have contacts who are responsible at your shop for other products
such as the languages, Db2, CICS, MQ and so forth, you could try to get
them to chime in. Apparently one of the pushbacks from the documentation
team is “IBM has 1200 products and our process works fine for all of them –
what’s wrong with you z/OS people?”

Thank you.
Charles

--
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: Are you serious about wanting a better IBM doc RCF-type process?

+1

> On 23 May 2023, at 6:05 am, Charles Mills  wrote:
> 
> For those who have not been following this discussion, IBM is on track to 
> remove the RCF process as we have known it for forty or so years. Customers 
> and ISVs will be limited to a Web pop-up “Was this helpful?” and if you 
> answer No, you will be able to briefly justify that answer. There is also 
> apparently now no path whatsoever for a customer to open a requirement 
> against IBM documentation.
> 
> We need a way to provide formatted suggestions for improvements, 
> clarifications or corrections to IBM manuals.
> 
> If you would like that, then wishing and hoping and grumping will not make it 
> happen. Here is what might make it happen:
> 
> - You could start by replying with a simple +1 to this post. The IBM powers 
> that be do not participate in this forum, but there is strong evidence that 
> what happens here sometimes percolates in that direction.
> - You could vote for Peter Farley’s RFE. Find it here: 
> https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3691 
> (apologies for any fold).
> - If you have an IBM rep at your shop, you could let him or her know. If you 
> simply know an IBMer you could tell him or her nicely. 
> - If you have contacts who are responsible at your shop for other products 
> such as the languages, Db2, CICS, MQ and so forth, you could try to get them 
> to chime in. Apparently one of the pushbacks from the documentation team is 
> “IBM has 1200 products and our process works fine for all of them – what’s 
> wrong with you z/OS people?”
> 
> Thank you.
> Charles
> 
> --
> 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: Are you serious about wanting a better IBM doc RCF-type process?

2023-05-22 Thread Ramsey Hallman

+1

I agree whole-heartedly with Mike and Charles.

Ramsey Hallman
MVS/Quickref Support Group
Chicago-Soft, LTD.

On Mon, May 22, 2023 at 5:34 PM Mike Shaw  wrote:

> +1
>
> I have been working with IBM z/OS documentation for over 40 years and have
> submitted many reader comment forms in that time. In that time I have found
> and reported typographical errors, inconsistencies, obsolete information,
> and even flat-out WRONG statements.
>
> Without real-world feedback from z/OS professionals who actually USE the
> documentation, it's accuracy and usability will not improve.
>
> IBM has good technical documentation writers but they are NOT end-users.
>
> Eliminating RCFs disconnects authors of the documentation from consumers of
> the documentation...NOT a good idea.
>
> Mike Shaw
> MVS/QuickRef Support Group
> Chicago-Soft, Ltd.
>
> On Mon, May 22, 2023, 6:05 PM Charles Mills  wrote:
>
> > For those who have not been following this discussion, IBM is on track to
> > remove the RCF process as we have known it for forty or so years.
> Customers
> > and ISVs will be limited to a Web pop-up “Was this helpful?” and if you
> > answer No, you will be able to briefly justify that answer. There is also
> > apparently now no path whatsoever for a customer to open a requirement
> > against IBM documentation.
> >
> > We need a way to provide formatted suggestions for improvements,
> > clarifications or corrections to IBM manuals.
> >
> > If you would like that, then wishing and hoping and grumping will not
> make
> > it happen. Here is what might make it happen:
> >
> > - You could start by replying with a simple +1 to this post. The IBM
> > powers that be do not participate in this forum, but there is strong
> > evidence that what happens here sometimes percolates in that direction.
> > - You could vote for Peter Farley’s RFE. Find it here:
> >
> https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3691
> > (apologies for any fold).
> > - If you have an IBM rep at your shop, you could let him or her know. If
> > you simply know an IBMer you could tell him or her nicely.
> > - If you have contacts who are responsible at your shop for other
> products
> > such as the languages, Db2, CICS, MQ and so forth, you could try to get
> > them to chime in. Apparently one of the pushbacks from the documentation
> > team is “IBM has 1200 products and our process works fine for all of
> them –
> > what’s wrong with you z/OS people?”
> >
> > Thank you.
> > Charles
> >
> > --
> > 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: Are you serious about wanting a better IBM doc RCF-type process?

2023-05-22 Thread Mike Shaw

+1

I have been working with IBM z/OS documentation for over 40 years and have
submitted many reader comment forms in that time. In that time I have found
and reported typographical errors, inconsistencies, obsolete information,
and even flat-out WRONG statements.

Without real-world feedback from z/OS professionals who actually USE the
documentation, it's accuracy and usability will not improve.

IBM has good technical documentation writers but they are NOT end-users.

Eliminating RCFs disconnects authors of the documentation from consumers of
the documentation...NOT a good idea.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

On Mon, May 22, 2023, 6:05 PM Charles Mills  wrote:

> For those who have not been following this discussion, IBM is on track to
> remove the RCF process as we have known it for forty or so years. Customers
> and ISVs will be limited to a Web pop-up “Was this helpful?” and if you
> answer No, you will be able to briefly justify that answer. There is also
> apparently now no path whatsoever for a customer to open a requirement
> against IBM documentation.
>
> We need a way to provide formatted suggestions for improvements,
> clarifications or corrections to IBM manuals.
>
> If you would like that, then wishing and hoping and grumping will not make
> it happen. Here is what might make it happen:
>
> - You could start by replying with a simple +1 to this post. The IBM
> powers that be do not participate in this forum, but there is strong
> evidence that what happens here sometimes percolates in that direction.
> - You could vote for Peter Farley’s RFE. Find it here:
> https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3691
> (apologies for any fold).
> - If you have an IBM rep at your shop, you could let him or her know. If
> you simply know an IBMer you could tell him or her nicely.
> - If you have contacts who are responsible at your shop for other products
> such as the languages, Db2, CICS, MQ and so forth, you could try to get
> them to chime in. Apparently one of the pushbacks from the documentation
> team is “IBM has 1200 products and our process works fine for all of them –
> what’s wrong with you z/OS people?”
>
> Thank you.
> Charles
>
> --
> 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

Are you serious about wanting a better IBM doc RCF-type process?

2023-05-22 Thread Charles Mills

For those who have not been following this discussion, IBM is on track to 
remove the RCF process as we have known it for forty or so years. Customers and 
ISVs will be limited to a Web pop-up “Was this helpful?” and if you answer No, 
you will be able to briefly justify that answer. There is also apparently now 
no path whatsoever for a customer to open a requirement against IBM 
documentation.

We need a way to provide formatted suggestions for improvements, clarifications 
or corrections to IBM manuals.

If you would like that, then wishing and hoping and grumping will not make it 
happen. Here is what might make it happen:

- You could start by replying with a simple +1 to this post. The IBM powers 
that be do not participate in this forum, but there is strong evidence that 
what happens here sometimes percolates in that direction.
- You could vote for Peter Farley’s RFE. Find it here: 
https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3691 
(apologies for any fold).
- If you have an IBM rep at your shop, you could let him or her know. If you 
simply know an IBMer you could tell him or her nicely. 
- If you have contacts who are responsible at your shop for other products such 
as the languages, Db2, CICS, MQ and so forth, you could try to get them to 
chime in. Apparently one of the pushbacks from the documentation team is “IBM 
has 1200 products and our process works fine for all of them – what’s wrong 
with you z/OS people?”

Thank you.
Charles

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

Re: Are Banks Breaking Up With Mainframes? | Forbes

2023-05-22 Thread Tom Brennan

In early 2017 a z13s I worked with was delivered to San Diego USA, all 
the way from Singapore!  I asked what was going on, and the answer was 
simply that Poughkeepsie was too busy.  I remember viewing a map from 
the shipping company showing its path across the Pacific :)


On 5/22/2023 2:07 PM, Radoslaw Skorupka wrote:

Oh, I forgot about quite small Singapore. That's the place my mainframes 
come from. :-)))




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

Re: IMS Connect Socket Call Example

2023-05-22 Thread Rahim Azizarab

look for it in SYS1.samplib.


regards;

Rahim   



   

 

On Monday, May 22, 2023 at 11:19:19 AM CDT, Schmitt, Michael 
 wrote:  
 
 I'm looking for an example of a program that makes synchronous calls to an IMS 
TM transaction via socket calls to IMS Connect. Preferably in COBOL, but if 
not, in any language.

The IMS Connect manual gives the API but doesn't have sample code for putting 
it all together into a call sequence.

The IMS manual has sample code for the OTMA Callable Interface, but I need the 
IMS Connect API, not OTMA.




--
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: Are Banks Breaking Up With Mainframes? | Forbes

2023-05-22 Thread Radoslaw Skorupka


W dniu 22.05.2023 o 15:48, Bob Bridges pisze:

Wait, did I misunderstand this?  People buy their first mainframe and run
Linux on it?!

(Color me ignorant, but I've always thought of OMVS as a late add-on.)


Yes, definitely.
In Poland we have at least two such new users, one of them agreed to use 
his name Nowy Styl. It is furniture company. I'm aware of the second, 
but AFAIK they are not reference. Both are absolutely new users of very 
first mainframe. LinuxOne.
I'm also aware of several other attempts where LinuxONE was seriously 
considered. I supported some of them.


BTW: it is not public, but really well known: there is attempt to 
purchase yet another mainframe. This time not for zLinux, but for... zTPF.



--
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: Are Banks Breaking Up With Mainframes? | Forbes

2023-05-22 Thread Radoslaw Skorupka


Timothy,
Can you share some examples of "first in country" new customers?
It need not to be company name, but IMHO the country is not matter of 
contract privacy.
It is especially interesting for me because I used to collect 
information about mainframe installation in "not so big" countries and 
regions like Trinidad & Tobago, Belize, Puerto Rico or Liechtenstein. 
Yes, each of mentioned regions does/did have mainframe.
Oh, I forgot about quite small Singapore. That's the place my mainframes 
come from. :-)))


--
Radoslaw Skorupka
Lodz, Poland




W dniu 22.05.2023 o 03:29, Timothy Sipples pisze:

Yes, there are brand new customers buying their first mainframes. IBM periodically 
discloses this basic fact. Sometimes I'm personally involved, sometimes when it's a 
"first in country" situation. (First in country?!? Yes, really.) And sometimes 
I have personal knowledge of other new mainframe customers. I'm reasonably sure I'm not 
hallucinating. :-)

It's a big world with many exciting developments.

Most new customers start with Linux but not all. Some add z/OS later. Some start by 
renting various virtualized pieces of IBM mainframes on IBM Cloud — there are many such 
choices now — then some later add "on premises" machines. Some are banks, some 
are not. While there are some common patterns, each new mainframe customer has their own 
unique needs.

Thank you all for your support.

—
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: VTS and volume categories (Friday questions)

2023-05-22 Thread Radoslaw Skorupka


That's good answer to the question not asked.
Yes, different categories are good for multi-tenancy, even if it is set 
of RMM, each having own db.
However I'm asking for the reason for having multiple categories 
logically assigned to single system.
I excluded various (virtual) tape capacities since the capacity is now  
set up by dataclass. So, why should one have more than one scratch 
category, still assuming there is one z/OS image?




--
Radoslaw Skorupka
Lodz, Poland



W dniu 20.05.2023 o 05:20, Brian Fraser pisze:

If different LPARs using the tape library have different TMCs, then they
must also have different category codes assigned so the correct tapes are
used for scratch mounts.


On Sat, 20 May 2023 at 02:43, Radoslaw Skorupka <
0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:


Volume categories (0001, 0002, and so on) are useful for library
partitioning. Each SMS-plex can use it's own set of categories (00x1,
00x2...).
Categorie are good to request big tape of small tape (JA, JK) or newer
or older (JB, JC...).
However the last sentence was good for real tapes.
In VTS world we have virtual tapes and the max. volume size is
determined in DATA CLASS construct - so one can have several sizes
within category.

So, the question arises: what is a purpose to have multiple categories
for one SMS-plex? Of course, there is no obligation to more than one
scratch category, however what goal can be achieved by using more than one?
I see the only one: different scratch Expiration settings.

BTW: all the volumes and drives are emulated, but... are there any
architectural limits (i.e. volume size) resulting from choice o CAT 00x1
aka MEDIA1 vs 00x2, etc. ?

Rather obvious, but I want to ask: is there any reason to define more
categories, that means for MEDIA3 and above?
In real tape world 3490E drive was completely incompatible with MEDIA3,
4, etc.
And the VTS allows to insert only CST (MEDIA1) and ECCST (MEDIA2)
virtual volumes.

--
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: Using COBOL COPY/REPLACING in display literals?

2023-05-22 Thread Schmitt, Michael

Copy FRED Replacing ==:CC:== By ==COMND==
':CC:' By 'COMND'

Move  SpacesTo  w-in-:CC:-grp
Move  '*'   To  w-in-:CC:(1)
Move  w-set-max To  w-in-:CC:-ct
String 'Global Default Set for '
   ':CC'
   into w-sysin-msg



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, May 22, 2023 2:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Using COBOL COPY/REPLACING in display literals?

Billy,

I do not believe it is possible to use COPY REPLACING to replace text inside a 
literal.  I haven't the time ATM to research the relevant manual citation, but 
I believe the answer is that REPLACING is a COBOL WORD-based search-and-replace 
rather than a simple string search-and-replace, and a literal is a single 
COBOL-word token.

With sufficient quoting you may be able to replace an entire (probably only 
relatively short in practical terms) literal string, but I am not even sure 
that can be done.

I'll look up the manual reference (if there is one, and there may not be) later 
if I can find the time.  Or maybe Tom Ross can pick up on your question and 
provide a more complete answer than mine.

Another solution could be a string-based pre-processing step before a compile 
that does those literal replacements for you instead of asking the compiler to 
do it, but that has its own complexities (like wrapping literals with 
replacements that expand the literal beyond column 72).

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Billy Ashton
Sent: Monday, May 22, 2023 3:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Using COBOL COPY/REPLACING in display literals?

Hi guys and gals, I have an odd one that someone asked and I could not come up 
with an answer.

In a COBOL program, using a COPY REPLACING directive, I can see the replacement 
of COBOL procedure statements fine, but when the tag is inside of a literal 
used for a DISPLAY, it is not replaced.

Is this something that can't be done, or is there some special syntax for it?

For example, my copy member (FRED) has this (plus a lot more):
If sysin-dflt
Move  SpacesTo  w-in-:CC:-grp
Move  '*'   To  w-in-:CC:(1)
Move  w-set-max To  w-in-:CC:-ct
Move  'Global Default set for :CC:' To  w-sysin-msg Else ...

So if I say
Copy FRED Replacing ==:CC:== By ==COMND==

I get this:
If sysin-dflt
Move  SpacesTo  w-in-COMND-grp
Move  '*'   To  w-in-COMND(1)
Move  w-set-max To  w-in-COMND-ct
Move  'Global Default set for :CC:' To  w-sysin-msg Else ...

I have looked through the manuals and done my Google diligence, but saw nothing 
about replacements (or lack of) in Procedure Division literals.

Does anyone have a good answer here? Can my programmer do this or not, and if 
so, how?

Thank you and best regards,
Billy Ashton
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
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: Using COBOL COPY/REPLACING in display literals?

2023-05-22 Thread Farley, Peter

Billy,

I do not believe it is possible to use COPY REPLACING to replace text inside a 
literal.  I haven't the time ATM to research the relevant manual citation, but 
I believe the answer is that REPLACING is a COBOL WORD-based search-and-replace 
rather than a simple string search-and-replace, and a literal is a single 
COBOL-word token.

With sufficient quoting you may be able to replace an entire (probably only 
relatively short in practical terms) literal string, but I am not even sure 
that can be done.

I'll look up the manual reference (if there is one, and there may not be) later 
if I can find the time.  Or maybe Tom Ross can pick up on your question and 
provide a more complete answer than mine.

Another solution could be a string-based pre-processing step before a compile 
that does those literal replacements for you instead of asking the compiler to 
do it, but that has its own complexities (like wrapping literals with 
replacements that expand the literal beyond column 72).

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Billy Ashton
Sent: Monday, May 22, 2023 3:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Using COBOL COPY/REPLACING in display literals?

Hi guys and gals, I have an odd one that someone asked and I could not come up 
with an answer.

In a COBOL program, using a COPY REPLACING directive, I can see the replacement 
of COBOL procedure statements fine, but when the tag is inside of a literal 
used for a DISPLAY, it is not replaced.

Is this something that can't be done, or is there some special syntax for it?

For example, my copy member (FRED) has this (plus a lot more):
If sysin-dflt
Move  SpacesTo  w-in-:CC:-grp
Move  '*'   To  w-in-:CC:(1)
Move  w-set-max To  w-in-:CC:-ct
Move  'Global Default set for :CC:' To  w-sysin-msg Else ...

So if I say
Copy FRED Replacing ==:CC:== By ==COMND==

I get this:
If sysin-dflt
Move  SpacesTo  w-in-COMND-grp
Move  '*'   To  w-in-COMND(1)
Move  w-set-max To  w-in-COMND-ct
Move  'Global Default set for :CC:' To  w-sysin-msg Else ...

I have looked through the manuals and done my Google diligence, but saw nothing 
about replacements (or lack of) in Procedure Division literals.

Does anyone have a good answer here? Can my programmer do this or not, and if 
so, how?

Thank you and best regards,
Billy Ashton
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Using COBOL COPY/REPLACING in display literals?

2023-05-22 Thread Billy Ashton

Hi guys and gals, I have an odd one that someone asked and I could not 
come up with an answer.


In a COBOL program, using a COPY REPLACING directive, I can see the 
replacement of COBOL procedure statements fine, but when the tag is 
inside of a literal used for a DISPLAY, it is not replaced.


Is this something that can't be done, or is there some special syntax 
for it?


For example, my copy member (FRED) has this (plus a lot more):
If sysin-dflt
   Move  SpacesTo  w-in-:CC:-grp
   Move  '*'   To  w-in-:CC:(1)
   Move  w-set-max To  w-in-:CC:-ct
   Move  'Global Default set for :CC:' To  w-sysin-msg
Else
...

So if I say
Copy FRED Replacing ==:CC:== By ==COMND==

I get this:
If sysin-dflt
   Move  SpacesTo  w-in-COMND-grp
   Move  '*'   To  w-in-COMND(1)
   Move  w-set-max To  w-in-COMND-ct
   Move  'Global Default set for :CC:' To  w-sysin-msg
Else
...

I have looked through the manuals and done my Google diligence, but saw 
nothing about replacements (or lack of) in Procedure Division literals.


Does anyone have a good answer here? Can my programmer do this or not, 
and if so, how?


Thank you and best regards,
Billy Ashton

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

IBM download server root CA change

2023-05-22 Thread Kurt J. Quackenbush

Take note of the planned 30 May 2023 change to the certificate authority (CA) 
root for the IBM software download servers:
https://www.ibm.com/support/pages/node/6997317

This affects downloads for z/OS product and service orders submitted from 
Shopz, service orders submitted by SMP/E RECEIVE ORDER, and service orders 
submitted by ServiceLink.  Take action now to avoid interruptions in your PTF 
and software product download capability.

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  
ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.




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

IMS Connect Socket Call Example

2023-05-22 Thread Schmitt, Michael

I'm looking for an example of a program that makes synchronous calls to an IMS 
TM transaction via socket calls to IMS Connect. Preferably in COBOL, but if 
not, in any language.

The IMS Connect manual gives the API but doesn't have sample code for putting 
it all together into a call sequence.

The IMS manual has sample code for the OTMA Callable Interface, but I need the 
IMS Connect API, not OTMA.




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

Re: [EXTERNAL] Re: zLinux (was are banks breaking up with mainframes)

People tend to be knowingly sloppy about their language. Other people hear them 
and assume that what they hear is accurate. Sometimes they miss subtle nuances, 
like the interrogative tone of the Yiddish "I could care less?", and come up 
with utter absurdities. Then they act on what they think they know; hilarity 
ensues (assuming that you're not the one who has to clean up after them.)

ObQoheleth1:10 I believe that this has been going on since my Uncle Crow and 
aunt Maggie.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pommier, Rex [rpomm...@sfgmembers.com]
Sent: Monday, May 22, 2023 11:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: zLinux (was are banks breaking up with mainframes)

Hi Rick,

Thanks for the confirmation.  I was meandering the internet to remove the last 
shred of doubt about zLinux being full ASCII and was somewhat dismayed at the 
number of hits I got talking about "Linux for z/OS"  No it ain't!!!   :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rick Troth
Sent: Monday, May 22, 2023 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: zLinux (was are banks breaking up with mainframes)

Rex is right.
Linux (Z or otherwise) is a different operating system. And it's "full ASCII".

USS, also known as OMVS, has been an integral part of MVS (now known as
z/OS) since the mid 1990s.
IBM has put more and more function into USS, even moving things from the 
"traditional" side.
USS is really an excellent piece of work, even though it does speak EBCDIC. 
(Which, being Unix in every other way, really confuses newcomers.)

A growing number of people do in fact buy their first mainframe and run Linux 
on it. They can go native (LPAR) or on top of z/VM. But that's not USS (with or 
without VM).

Z hardware is phenomenal. There's nothing like it. From time to time, a 
potential customer will recognize the value of that hardware, regardless what 
software workload they anticipate.
Of course, if they want the data moving power of a diesel locomotive, they 
should go with z/OS. But for lots of other workloads, they'll want Linux. No 
problem!

Just ... watch out ... be wary of the folks who mislabel it "Linux for z/OS". 
Even with more than 20 years of "Linux for Z", there are still many people out 
there who cannot separate z/OS the operating system from Z hardware.

-- R; <><

On 5/22/23 10:40, Pommier, Rex wrote:
> Hi Bob,
>
> Linux on Z and OMVS are 2 completely different animals.  OMVS is an integral 
> part of z/OS (try running TCP/IP without it for example).  zLinux is a 
> completely separate operating system, running in an LPAR or on top of VM just 
> like another OS image.  Another difference is that OMVS (as part of z/OS) 
> runs EBCDIC where I believe zLinux is a full ASCII OS running on the z 
> hardware.
>
> Rex
>
> From: IBM Mainframe Discussion List  on
> behalf of Bob Bridges 
> Sent: Monday, May 22, 2023 9:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Are Banks Breaking Up With Mainframes? | Forbes
>
> Wait, did I misunderstand this?  People buy their first mainframe and run 
> Linux on it?!
>
> (Color me ignorant, but I've always thought of OMVS as a late add-on.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
>
> --
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged. If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format. Thank you.
>
> --
> 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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any

Re: zLinux (was are banks breaking up with mainframes)

Announced Feb 9, 1993 
;
 available Mar 25, 1994 
.

Merged into base with MVS/SEA SP V5.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rick Troth [tro...@gmail.com]
Sent: Monday, May 22, 2023 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zLinux (was are banks breaking up with mainframes)

Rex is right.
Linux (Z or otherwise) is a different operating system. And it's "full
ASCII".

USS, also known as OMVS, has been an integral part of MVS (now known as
z/OS) since the mid 1990s.
IBM has put more and more function into USS, even moving things from the
"traditional" side.
USS is really an excellent piece of work, even though it does speak
EBCDIC. (Which, being Unix in every other way, really confuses newcomers.)

A growing number of people do in fact buy their first mainframe and run
Linux on it. They can go native (LPAR) or on top of z/VM. But that's not
USS (with or without VM).

Z hardware is phenomenal. There's nothing like it. From time to time, a
potential customer will recognize the value of that hardware, regardless
what software workload they anticipate.
Of course, if they want the data moving power of a diesel locomotive,
they should go with z/OS. But for lots of other workloads, they'll want
Linux. No problem!

Just ... watch out ... be wary of the folks who mislabel it "Linux for
z/OS". Even with more than 20 years of "Linux for Z", there are still
many people out there who cannot separate z/OS the operating system from
Z hardware.

-- R; <><

On 5/22/23 10:40, Pommier, Rex wrote:
> Hi Bob,
>
> Linux on Z and OMVS are 2 completely different animals.  OMVS is an integral 
> part of z/OS (try running TCP/IP without it for example).  zLinux is a 
> completely separate operating system, running in an LPAR or on top of VM just 
> like another OS image.  Another difference is that OMVS (as part of z/OS) 
> runs EBCDIC where I believe zLinux is a full ASCII OS running on the z 
> hardware.
>
> Rex
>
> From: IBM Mainframe Discussion List  on behalf of 
> Bob Bridges 
> Sent: Monday, May 22, 2023 9:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Are Banks Breaking Up With Mainframes? | Forbes
>
> Wait, did I misunderstand this?  People buy their first mainframe and run 
> Linux on it?!
>
> (Color me ignorant, but I've always thought of OMVS as a late add-on.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
>
> --
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged. If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format. Thank you.
>
> --
> 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: [EXTERNAL] Re: zLinux (was are banks breaking up with mainframes)

2023-05-22 Thread Pommier, Rex

Hi Rick,

Thanks for the confirmation.  I was meandering the internet to remove the last 
shred of doubt about zLinux being full ASCII and was somewhat dismayed at the 
number of hits I got talking about "Linux for z/OS"  No it ain't!!!   :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rick Troth
Sent: Monday, May 22, 2023 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: zLinux (was are banks breaking up with mainframes)

Rex is right.
Linux (Z or otherwise) is a different operating system. And it's "full ASCII".

USS, also known as OMVS, has been an integral part of MVS (now known as
z/OS) since the mid 1990s.
IBM has put more and more function into USS, even moving things from the 
"traditional" side.
USS is really an excellent piece of work, even though it does speak EBCDIC. 
(Which, being Unix in every other way, really confuses newcomers.)

A growing number of people do in fact buy their first mainframe and run Linux 
on it. They can go native (LPAR) or on top of z/VM. But that's not USS (with or 
without VM).

Z hardware is phenomenal. There's nothing like it. From time to time, a 
potential customer will recognize the value of that hardware, regardless what 
software workload they anticipate.
Of course, if they want the data moving power of a diesel locomotive, they 
should go with z/OS. But for lots of other workloads, they'll want Linux. No 
problem!

Just ... watch out ... be wary of the folks who mislabel it "Linux for z/OS". 
Even with more than 20 years of "Linux for Z", there are still many people out 
there who cannot separate z/OS the operating system from Z hardware.

-- R; <><

On 5/22/23 10:40, Pommier, Rex wrote:
> Hi Bob,
>
> Linux on Z and OMVS are 2 completely different animals.  OMVS is an integral 
> part of z/OS (try running TCP/IP without it for example).  zLinux is a 
> completely separate operating system, running in an LPAR or on top of VM just 
> like another OS image.  Another difference is that OMVS (as part of z/OS) 
> runs EBCDIC where I believe zLinux is a full ASCII OS running on the z 
> hardware.
>
> Rex
>
> From: IBM Mainframe Discussion List  on 
> behalf of Bob Bridges 
> Sent: Monday, May 22, 2023 9:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Are Banks Breaking Up With Mainframes? | Forbes
>
> Wait, did I misunderstand this?  People buy their first mainframe and run 
> Linux on it?!
>
> (Color me ignorant, but I've always thought of OMVS as a late add-on.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
>
> --
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged. If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format. Thank you.
>
> --
> 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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

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

Re: zLinux (was are banks breaking up with mainframes)

2023-05-22 Thread Rick Troth


Rex is right.
Linux (Z or otherwise) is a different operating system. And it's "full 
ASCII".


USS, also known as OMVS, has been an integral part of MVS (now known as 
z/OS) since the mid 1990s.
IBM has put more and more function into USS, even moving things from the 
"traditional" side.
USS is really an excellent piece of work, even though it does speak 
EBCDIC. (Which, being Unix in every other way, really confuses newcomers.)


A growing number of people do in fact buy their first mainframe and run 
Linux on it. They can go native (LPAR) or on top of z/VM. But that's not 
USS (with or without VM).


Z hardware is phenomenal. There's nothing like it. From time to time, a 
potential customer will recognize the value of that hardware, regardless 
what software workload they anticipate.
Of course, if they want the data moving power of a diesel locomotive, 
they should go with z/OS. But for lots of other workloads, they'll want 
Linux. No problem!


Just ... watch out ... be wary of the folks who mislabel it "Linux for 
z/OS". Even with more than 20 years of "Linux for Z", there are still 
many people out there who cannot separate z/OS the operating system from 
Z hardware.


-- R; <><


On 5/22/23 10:40, Pommier, Rex wrote:

Hi Bob,

Linux on Z and OMVS are 2 completely different animals.  OMVS is an integral 
part of z/OS (try running TCP/IP without it for example).  zLinux is a 
completely separate operating system, running in an LPAR or on top of VM just 
like another OS image.  Another difference is that OMVS (as part of z/OS) runs 
EBCDIC where I believe zLinux is a full ASCII OS running on the z hardware.

Rex

From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Monday, May 22, 2023 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Are Banks Breaking Up With Mainframes? | Forbes

Wait, did I misunderstand this?  People buy their first mainframe and run Linux 
on it?!

(Color me ignorant, but I've always thought of OMVS as a late add-on.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313


--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

--
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: Are Banks Breaking Up With Mainframes? | Forbes

2023-05-22 Thread Bill Johnson

Huge hack in Australia.

https://www.abc.net.au/news/2023-03-27/latitude-far-worse-cyberhacking-almost-8-million-people/102141364




Sent from Yahoo Mail for iPhone


On Monday, May 22, 2023, 7:52 AM, David Crayford  wrote:

On 22/5/2023 1:26 pm, Attila Fogarasi wrote:
> Good point about NUMAand it is still a differentiator and competitive
> advantage for IBM z.

How is NUMA a competitive advantage for z? Superdomes use Intel 
UltraPath Interconnect (UPI) links that can do glueless NUMA.

> IBM bought Sequent 20+ years ago to get their
> excellent NUMA technology, and has since built some very clever cache
> topology and management algorithms.  AMD has historically been crippled in
> real-world performance due to cache inefficiencies.

What historical generation of AMD silicon was crippled? The EPYC 
supports up to 384MB of L3 cache and the specs and benchmarks suggest 
the chiplet architecture can easily handle the I/O.

> 10 years ago CICS was at 30 billion transactions per day, so
> volume has tripled in 10 years, during the massive growth of cloud.
> Healthy indeed.

I have a different perspective on what constitutes healthy. Here in 
Australia, I've had the opportunity to meet architects from various 
banks who are actively involved in or have completed the process of 
migrating the read side of their CICS transactions to distributed 
systems. They have embraced technologies like CDC and streaming 
platforms such as Apache Kafka and distributed data stores such as 
Cassandra and MongoDb. This shift has been primarily driven by 
disruptive technologies like mobile banking pushing up mainframe 
software costs.

This is a common architectural pattern.

https://www.conferencecast.tv/talk-29844-nationwide-building-society-building-mobile-applications-and-a-speed-layer-with-mongodb#.talkPage-header

>
> On Mon, May 22, 2023 at 2:56 PM David Crayford  wrote:
>
>> Sent again in plain text. Apple mail is too clever for it’s own good!
>>
>>> On 22 May 2023, at 12:46 pm, David Crayford  wrote:
>>>
>>>
>>>
 On 21 May 2023, at 12:52 pm, Howard Rifkind
>> wrote:
 Hundreds of PC type servers still can’t handle the huge amount of data
>> like a mainframe can.
>>>
>> Of course, that's an absurd statement! By "PC type," I assume you're
>> referring to x86? We can easily break this down. First things first, let's
>> forget about the "hundreds" requirement. A 32 single socket system is
>> enough to match up.
>>
>> AMD EPYC is the poster child for single socket servers, running its novel
>> chiplet technology on a 5nm process node. AMD's infinity interconnects are
>> capable of massive I/O bandwidth. You can learn more about it here:
>> https://www.amd.com/en/technologies/infinity-architecture. Each socket
>> can have a maximum of 96 cores, but even if we use a conservative 64 cores
>> per socket, that's a scale-out of 2048 cores. AMD also has accelerators for
>> offload encryption/compression, etc.
>>
>> Over in Intel land, the Ice Lake server platform is not quite as
>> impressive, but the QPI (Quick Path Interconnect) yet again handles huge
>> bandwidth. Intel also has accelerators such as their QAT, which can either
>> be on-die SoC or a PCIe card. It's not too dissimilar to zEDC but with the
>> advantage that it supports all popular compression formats and not just
>> DEFLATE. You can find more information here:
>> https://www.intel.com.au/content/www/au/en/architecture-and-technology/intel-quick-assist-technology-overview.html
>> .
>>
>> A more apples-to-apples comparison would be the HP Superdome Flex, which
>> is a large shared memory system lashed together with NUMA interconnects,
>> with a whopping 32 sockets and a maximum core count of 896 on a single
>> vertically integrated system. HP Enterprise has technology such as nPars,
>> which is similar to PR/SM. They claim 99.999% availability on a single
>> system and even beyond when clustered.
>>
>> On the Arm side, it gets even more interesting as the hyperscalers and
>> cloud builders are building their own kit. Although this technology is
>> almost certainly the growth area of non-x86 workloads, you can find more
>> details about it here:
>> https://www.nextplatform.com/2023/05/18/ampere-gets-out-in-front-of-x86-with-192-core-siryn-ampereone/
>> .
>>
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email tolists...@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

zLinux (was are banks breaking up with mainframes)

2023-05-22 Thread Pommier, Rex

Hi Bob,

Linux on Z and OMVS are 2 completely different animals.  OMVS is an integral 
part of z/OS (try running TCP/IP without it for example).  zLinux is a 
completely separate operating system, running in an LPAR or on top of VM just 
like another OS image.  Another difference is that OMVS (as part of z/OS) runs 
EBCDIC where I believe zLinux is a full ASCII OS running on the z hardware.  

Rex

From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Monday, May 22, 2023 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Are Banks Breaking Up With Mainframes? | Forbes

Wait, did I misunderstand this?  People buy their first mainframe and run Linux 
on it?!

(Color me ignorant, but I've always thought of OMVS as a late add-on.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313


--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

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

Re: Are Banks Breaking Up With Mainframes? | Forbes

2023-05-22 Thread Paul Gilmartin

On Fri, 19 May 2023 15:13:54 -0400, Mark Regan wrote:

>https://www.forbes.com/sites/forbesfinancecouncil/2023/03/31/are-banks-breaking-up-with-mainframes/?sh=acb458b6bccc
> 
>
> _id=54716d118b
>
I skipped ahead to the summary.  It seems to be less a breakup than
joining a ménage à trois.


On Mon, 22 May 2023 09:48:19 -0400, Bob Bridges wrote:

>Wait, did I misunderstand this?  People buy their first mainframe and run
>Linux on it?!
>
>(Color me ignorant, but I've always thought of OMVS as a late add-on.)
>
OMVS is fairly pure POSIX.  Linux has many enhancements (and a few
deviations.)

Linux has no 31-bit dependencies.  Programmers can forget about the
antique AMODEs and compatibility interfaces.

Experts on the z/VM fora have said that z/VM optimizes performance on z
better than KVM.

Unfortunately, z/VM administrators still need CMS skills even though the
payload is entirely Linux.

-- 
gil

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

Re: Are Banks Breaking Up With Mainframes? | Forbes

OMVS may have been a Johnny came lately, but Linux is a different code base.

From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Monday, May 22, 2023 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Are Banks Breaking Up With Mainframes? | Forbes

Wait, did I misunderstand this?  People buy their first mainframe and run
Linux on it?!

(Color me ignorant, but I've always thought of OMVS as a late add-on.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Treason doth never prosper: what's the reason? / Why, if it prosper, none
dare call it treason.  -Sir John Harrington */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Timothy Sipples
Sent: Sunday, May 21, 2023 21:30

Yes, there are brand new customers buying their first mainframes. IBM
periodically discloses this basic fact. Sometimes I'm personally involved,
sometimes when it's a "first in country" situation. (First in country?!?
Yes, really.) And sometimes I have personal knowledge of other new mainframe
customers. I'm reasonably sure I'm not hallucinating. :-)

Most new customers start with Linux but not all. Some add z/OS later. Some
start by renting various virtualized pieces of IBM mainframes on IBM Cloud -
there are many such choices now - then some later add "on premises"
machines. Some are banks, some are not. While there are some common
patterns, each new mainframe customer has their own unique needs.

--
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: Are Banks Breaking Up With Mainframes? | Forbes

2023-05-22 Thread Bob Bridges

Wait, did I misunderstand this?  People buy their first mainframe and run
Linux on it?!

(Color me ignorant, but I've always thought of OMVS as a late add-on.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Treason doth never prosper: what's the reason? / Why, if it prosper, none
dare call it treason.  -Sir John Harrington */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Timothy Sipples
Sent: Sunday, May 21, 2023 21:30

Yes, there are brand new customers buying their first mainframes. IBM
periodically discloses this basic fact. Sometimes I'm personally involved,
sometimes when it's a "first in country" situation. (First in country?!?
Yes, really.) And sometimes I have personal knowledge of other new mainframe
customers. I'm reasonably sure I'm not hallucinating. :-)

Most new customers start with Linux but not all. Some add z/OS later. Some
start by renting various virtualized pieces of IBM mainframes on IBM Cloud -
there are many such choices now - then some later add "on premises"
machines. Some are banks, some are not. While there are some common
patterns, each new mainframe customer has their own unique needs.

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

Re: Are Banks Breaking Up With Mainframes? | Forbes

2023-05-22 Thread Matt Hogstrom

All good data … what is lacking on the mainframe IMHO is a modernized approach 
to configuration and management.  Not speeds and feeds inasmuch as getting 
people onboarded to keep feeding the system.  There are improvements but 
culturally customers struggle with significant enhancements like new package 
managers, etc.  

Matt Hogstrom

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On May 22, 2023, at 8:12 AM, zMan  wrote:
> 
> Ah, right, a few Linux on Z customers, sure. That's...different, and Linux
> on Z has, alas, kind of withered of late. I had great hopes for it in the
> early 2000s, but so many of the poster-children have abandoned it
> (Nationwide, for one). It's not dead by a long shot but doesn't seem to be
> the mainframe savior we'd hoped for.
> 
> If IBM is disclosing these new customers, can you point to a few?
> 
> On Sun, May 21, 2023 at 9:29 PM Timothy Sipples  wrote:

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

Architectural questions [WAS: Are Banks Breaking Up With Mainframes? | Forbes]

2023-05-22 Thread Steve Thompson

I have a question about these systems, both z and not z.

What is the current bus width supported?

At the G3 level for "z" the CPU-RAM bus was 256 bytes wide, as I
recall.

For IOP to RAM it was 64 bytes wide.

For the systems I run (off the shelf stuff for Linux and windows)
the bus is still at 64bits (8 bytes). Yes it has bus mastering,
and pathing to allow certain adapter cards to use 8bit "channels"

z/Arch POP has instructions for interrogating the bus sizes. I
haven't had the time or opportunity to write any tests using this
to find out what those bus sizes are it would report on.

Steve Thompson

On 5/22/2023 7:52 AM, David Crayford wrote:

On 22/5/2023 1:26 pm, Attila Fogarasi wrote:
Good point about NUMAand it is still a differentiator and
competitive

advantage for IBM z.

How is NUMA a competitive advantage for z? Superdomes use Intel
UltraPath Interconnect (UPI) links that can do glueless NUMA.

IBM bought Sequent 20+ years ago to get their
excellent NUMA technology, and has since built some very
clever cache
topology and management algorithms. AMD has historically been
crippled in

real-world performance due to cache inefficiencies.

What historical generation of AMD silicon was crippled? The
EPYC supports up to 384MB of L3 cache and the specs and
benchmarks suggest the chiplet architecture can easily handle
the I/O.

10 years ago CICS was at 30 billion transactions per day, so
volume has tripled in 10 years, during the massive growth of
cloud.

Healthy indeed.

I have a different perspective on what constitutes healthy.
Here in Australia, I've had the opportunity to meet architects
from various banks who are actively involved in or have
completed the process of migrating the read side of their CICS
transactions to distributed systems. They have embraced
technologies like CDC and streaming platforms such as Apache
Kafka and distributed data stores such as Cassandra and
MongoDb. This shift has been primarily driven by disruptive
technologies like mobile banking pushing up mainframe software
costs.

This is a common architectural pattern.

https://www.conferencecast.tv/talk-29844-nationwide-building-society-building-mobile-applications-and-a-speed-layer-with-mongodb#.talkPage-header

On Mon, May 22, 2023 at 2:56 PM David
Crayford wrote:

Sent again in plain text. Apple mail is too clever for it’s
own good!

On 22 May 2023, at 12:46 pm, David
Crayford wrote:

On 21 May 2023, at 12:52 pm, Howard
Rifkind

wrote:
Hundreds of PC type servers still can’t handle the huge
amount of data

like a mainframe can.

Of course, that's an absurd statement! By "PC type," I assume
you're
referring to x86? We can easily break this down. First things
first, let's
forget about the "hundreds" requirement. A 32 single socket
system is

enough to match up.

AMD EPYC is the poster child for single socket servers,
running its novel
chiplet technology on a 5nm process node. AMD's infinity
interconnects are
capable of massive I/O bandwidth. You can learn more about it
here:
https://www.amd.com/en/technologies/infinity-architecture.
Each socket
can have a maximum of 96 cores, but even if we use a
conservative 64 cores
per socket, that's a scale-out of 2048 cores. AMD also has
accelerators for

offload encryption/compression, etc.

DEFLATE. You can find more information here:
https://www.intel.com.au/content/www/au/en/architecture-and-technology/intel-quick-assist-technology-overview.html

A more apples-to-apples comparison would be the HP Superdome
Flex, which
is a large shared memory system lashed together with NUMA
interconnects,
with a whopping 32 sockets and a maximum core count of 896 on
a single
vertically integrated system. HP Enterprise has technology
such as nPars,
which is similar to PR/SM. They claim 99.999% availability on
a single

system and even beyond when clustered.

details about it here:
https://www.nextplatform.com/2023/05/18/ampere-gets-out-in-front-of-x86-with-192-core-siryn-ampereone/

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

For IBM-MAIN subscribe / signoff / archive access instructions,
send email

Re: Are Banks Breaking Up With Mainframes? | Forbes

Good point. I'm out.

On Mon, May 22, 2023 at 8:13 AM Jay Maynard  wrote:

> Get a room, you two.
>
> On Mon, May 22, 2023 at 7:10 AM zMan  wrote:
>
> > Right, but there are other facilities, and the article isn't about
> > mainframes, it's about AI and chips in general. RIF.
> >
> > On Sat, May 20, 2023 at 11:18 PM Bill Johnson <
> > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > lol, did you read the article? The Hudson Valley and Poughkeepsie are
> > > where IBM has most of their mainframe engineering and manufacturing.
> > > Poughkeepsie is in the Hudson Valley.
> > >
> > >
> > > Sent from Yahoo Mail for iPhone
> > >
> > >
> > > On Saturday, May 20, 2023, 10:58 PM, zMan 
> > wrote:
> > >
> > > Nothing here says it's investing in POK, or in mainframe technology.
> RIF.
> > >
> > > And the tired stats about 71% of Fortune whatever using mainframes may
> or
> > > may not be current, and don't prove anything about growth. All you have
> > to
> > > do is be awake to see that it's fading. Not fast--nobody thinks it's
> dead
> > > or even necessarily dying yet. But it's NOT growing as a platform by
> the
> > > meaningful metrics of users, applications, customer investment beyond
> > > keeping what they have alive.
> > >
> > > Seriously, take a look around. You want it to be one way; that doesn't
> > mean
> > > it is. I've tried to convince myself otherwise for years, finally had
> to
> > > admit it wasn't happening.
> > >
> > > On Sat, May 20, 2023 at 8:00 PM Bill Johnson <
> > > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > > > IDK, if POK is shrinking, why is IBM investing 20 billion there?
> > > >
> > > >
> > >
> >
> https://spectrumlocalnews.com/nys/central-ny/news/2022/10/05/ibm-to-announce-tech-investment-during-biden-visit
> > > >
> > > >
> > > >
> > > >
> > > > Sent from Yahoo Mail for iPhone
> > > >
> > > >
> > > > On Saturday, May 20, 2023, 7:04 PM, zMan 
> > wrote:
> > > >
> > > > Note that "fewer mainframes" doesn't refer to fewer boxes. It refers
> to
> > > far
> > > > fewer SITES. Yes, there's consolidation in some industries; there
> still
> > > > aren't any NEW sites. You assert "IBM keeps new customers under
> wraps"
> > > but
> > > > if you talk to IBMers, there aren't any to keep under wraps. More
> > wishful
> > > > thinking, I'm afraid. Unless your contention is that they're kept so
> > > secret
> > > > that the people who support them don't know about them...
> > > >
> > > > There might have been 3K folks listed as working in POK 15 months
> ago.
> > > IBM
> > > > just RIFfed another 7,000. Given that it was at least five years ago
> > that
> > > > IBM was down to 25,000 domestic employees, I doubt there are 3K left
> in
> > > POK
> > > > by a long shot, but it's possible. If so, they aren't very busy, at
> > least
> > > > not with zSystems stuff. In any case, ask anyone who's been there
> > lately:
> > > > the build floor is empty.
> > > >
> > > > I've said it before, but some people don't seem to hear it, so I'll
> > > repeat:
> > > > I'm not anti-mainframe. I've been making my living off it for over
> four
> > > > decades, and while retirement is within view, I'm not there yet. I
> > would
> > > > like it to be healthy and growing; all the real evidence points the
> > other
> > > > way, no matter what IBM press releases may state.
> > > >
> > > > P.S. Sorry, Dave, zOSMF doesn't count. It's a tool. Nobody is
> > installing
> > > a
> > > > mainframe so they can run it. We don't buy computers to run tools or
> > > > operating systems: we buy them to run applications. Big difference.
> > > >
> > > > On Sat, May 20, 2023 at 2:17 PM Bill Johnson <
> > > > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> > > >
> > > > > The facts are readily available. Mainframe growth is undeniable.
> And
> > > will
> > > > > be for decades to come. Will weak banks foolishly buy what airline
> > > > > magazines are selling? Of course. Bad decisions are made in the
> > > business
> > > > > world daily. Ms Hovsepian should be more concerned with her company
> > > > > (Microfocus part) desperately trying to reverse engineer CICS so
> they
> > > can
> > > > > justify their decision to partner with Amazon Web Services.
> > > > >
> > > > >
> > > > > Sent from Yahoo Mail for iPhone
> > > > >
> > > > >
> > > > > On Saturday, May 20, 2023, 1:42 PM, Bob Bridges <
> > robhbrid...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > Bill, you said "bull", which I misunderstood to mean that you
> > disagree.
> > > > > But the article you posted in support of that opinion (or whatever
> it
> > > is)
> > > > > doesn't contradict the OP's article.
> > > > >
> > > > > I'm just guessing here, but maybe you've been arguing with those
> > > > > mainframe-is-dying folks so long that you no longer notice the
> > nuances.
> > > > Ms
> > > > > Hovsepian didn't say the mainframe is dying; she said a lot of
> banks
> > > > > (repeat banks) are considering (repeat considering) moving to

Re: Are Banks Breaking Up With Mainframes? | Forbes

2023-05-22 Thread Jay Maynard

Get a room, you two.

On Mon, May 22, 2023 at 7:10 AM zMan  wrote:

> Right, but there are other facilities, and the article isn't about
> mainframes, it's about AI and chips in general. RIF.
>
> On Sat, May 20, 2023 at 11:18 PM Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>
> > lol, did you read the article? The Hudson Valley and Poughkeepsie are
> > where IBM has most of their mainframe engineering and manufacturing.
> > Poughkeepsie is in the Hudson Valley.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Saturday, May 20, 2023, 10:58 PM, zMan 
> wrote:
> >
> > Nothing here says it's investing in POK, or in mainframe technology. RIF.
> >
> > And the tired stats about 71% of Fortune whatever using mainframes may or
> > may not be current, and don't prove anything about growth. All you have
> to
> > do is be awake to see that it's fading. Not fast--nobody thinks it's dead
> > or even necessarily dying yet. But it's NOT growing as a platform by the
> > meaningful metrics of users, applications, customer investment beyond
> > keeping what they have alive.
> >
> > Seriously, take a look around. You want it to be one way; that doesn't
> mean
> > it is. I've tried to convince myself otherwise for years, finally had to
> > admit it wasn't happening.
> >
> > On Sat, May 20, 2023 at 8:00 PM Bill Johnson <
> > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > IDK, if POK is shrinking, why is IBM investing 20 billion there?
> > >
> > >
> >
> https://spectrumlocalnews.com/nys/central-ny/news/2022/10/05/ibm-to-announce-tech-investment-during-biden-visit
> > >
> > >
> > >
> > >
> > > Sent from Yahoo Mail for iPhone
> > >
> > >
> > > On Saturday, May 20, 2023, 7:04 PM, zMan 
> wrote:
> > >
> > > Note that "fewer mainframes" doesn't refer to fewer boxes. It refers to
> > far
> > > fewer SITES. Yes, there's consolidation in some industries; there still
> > > aren't any NEW sites. You assert "IBM keeps new customers under wraps"
> > but
> > > if you talk to IBMers, there aren't any to keep under wraps. More
> wishful
> > > thinking, I'm afraid. Unless your contention is that they're kept so
> > secret
> > > that the people who support them don't know about them...
> > >
> > > There might have been 3K folks listed as working in POK 15 months ago.
> > IBM
> > > just RIFfed another 7,000. Given that it was at least five years ago
> that
> > > IBM was down to 25,000 domestic employees, I doubt there are 3K left in
> > POK
> > > by a long shot, but it's possible. If so, they aren't very busy, at
> least
> > > not with zSystems stuff. In any case, ask anyone who's been there
> lately:
> > > the build floor is empty.
> > >
> > > I've said it before, but some people don't seem to hear it, so I'll
> > repeat:
> > > I'm not anti-mainframe. I've been making my living off it for over four
> > > decades, and while retirement is within view, I'm not there yet. I
> would
> > > like it to be healthy and growing; all the real evidence points the
> other
> > > way, no matter what IBM press releases may state.
> > >
> > > P.S. Sorry, Dave, zOSMF doesn't count. It's a tool. Nobody is
> installing
> > a
> > > mainframe so they can run it. We don't buy computers to run tools or
> > > operating systems: we buy them to run applications. Big difference.
> > >
> > > On Sat, May 20, 2023 at 2:17 PM Bill Johnson <
> > > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > > > The facts are readily available. Mainframe growth is undeniable. And
> > will
> > > > be for decades to come. Will weak banks foolishly buy what airline
> > > > magazines are selling? Of course. Bad decisions are made in the
> > business
> > > > world daily. Ms Hovsepian should be more concerned with her company
> > > > (Microfocus part) desperately trying to reverse engineer CICS so they
> > can
> > > > justify their decision to partner with Amazon Web Services.
> > > >
> > > >
> > > > Sent from Yahoo Mail for iPhone
> > > >
> > > >
> > > > On Saturday, May 20, 2023, 1:42 PM, Bob Bridges <
> robhbrid...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > Bill, you said "bull", which I misunderstood to mean that you
> disagree.
> > > > But the article you posted in support of that opinion (or whatever it
> > is)
> > > > doesn't contradict the OP's article.
> > > >
> > > > I'm just guessing here, but maybe you've been arguing with those
> > > > mainframe-is-dying folks so long that you no longer notice the
> nuances.
> > > Ms
> > > > Hovsepian didn't say the mainframe is dying; she said a lot of banks
> > > > (repeat banks) are considering (repeat considering) moving to the
> > cloud.
> > > >
> > > > (To be fair, it sounds like she made the same mistake.  "Why the
> > > readiness
> > > > to 'swipe left' on their mainframe and COBOL applications?", she asks
> > in
> > > a
> > > > throwaway inference.)
> > > >
> > > > ---
> > > > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> > > >
> > > > /* Perseverance is not

Re: Are Banks Breaking Up With Mainframes? | Forbes

Ah, right, a few Linux on Z customers, sure. That's...different, and Linux
on Z has, alas, kind of withered of late. I had great hopes for it in the
early 2000s, but so many of the poster-children have abandoned it
(Nationwide, for one). It's not dead by a long shot but doesn't seem to be
the mainframe savior we'd hoped for.

If IBM is disclosing these new customers, can you point to a few?

On Sun, May 21, 2023 at 9:29 PM Timothy Sipples  wrote:

> Yes, there are brand new customers buying their first mainframes. IBM
> periodically discloses this basic fact. Sometimes I'm personally involved,
> sometimes when it's a "first in country" situation. (First in country?!?
> Yes, really.) And sometimes I have personal knowledge of other new
> mainframe customers. I'm reasonably sure I'm not hallucinating. :-)
>
> It's a big world with many exciting developments.
>
> Most new customers start with Linux but not all. Some add z/OS later. Some
> start by renting various virtualized pieces of IBM mainframes on IBM Cloud
> — there are many such choices now — then some later add "on premises"
> machines. Some are banks, some are not. While there are some common
> patterns, each new mainframe customer has their own unique needs.
>
> Thank you all for your support.
>
> —
> 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
>


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

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

Re: Are Banks Breaking Up With Mainframes? | Forbes

Right, but there are other facilities, and the article isn't about
mainframes, it's about AI and chips in general. RIF.

On Sat, May 20, 2023 at 11:18 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> lol, did you read the article? The Hudson Valley and Poughkeepsie are
> where IBM has most of their mainframe engineering and manufacturing.
> Poughkeepsie is in the Hudson Valley.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Saturday, May 20, 2023, 10:58 PM, zMan  wrote:
>
> Nothing here says it's investing in POK, or in mainframe technology. RIF.
>
> And the tired stats about 71% of Fortune whatever using mainframes may or
> may not be current, and don't prove anything about growth. All you have to
> do is be awake to see that it's fading. Not fast--nobody thinks it's dead
> or even necessarily dying yet. But it's NOT growing as a platform by the
> meaningful metrics of users, applications, customer investment beyond
> keeping what they have alive.
>
> Seriously, take a look around. You want it to be one way; that doesn't mean
> it is. I've tried to convince myself otherwise for years, finally had to
> admit it wasn't happening.
>
> On Sat, May 20, 2023 at 8:00 PM Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>
> > IDK, if POK is shrinking, why is IBM investing 20 billion there?
> >
> >
> https://spectrumlocalnews.com/nys/central-ny/news/2022/10/05/ibm-to-announce-tech-investment-during-biden-visit
> >
> >
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Saturday, May 20, 2023, 7:04 PM, zMan  wrote:
> >
> > Note that "fewer mainframes" doesn't refer to fewer boxes. It refers to
> far
> > fewer SITES. Yes, there's consolidation in some industries; there still
> > aren't any NEW sites. You assert "IBM keeps new customers under wraps"
> but
> > if you talk to IBMers, there aren't any to keep under wraps. More wishful
> > thinking, I'm afraid. Unless your contention is that they're kept so
> secret
> > that the people who support them don't know about them...
> >
> > There might have been 3K folks listed as working in POK 15 months ago.
> IBM
> > just RIFfed another 7,000. Given that it was at least five years ago that
> > IBM was down to 25,000 domestic employees, I doubt there are 3K left in
> POK
> > by a long shot, but it's possible. If so, they aren't very busy, at least
> > not with zSystems stuff. In any case, ask anyone who's been there lately:
> > the build floor is empty.
> >
> > I've said it before, but some people don't seem to hear it, so I'll
> repeat:
> > I'm not anti-mainframe. I've been making my living off it for over four
> > decades, and while retirement is within view, I'm not there yet. I would
> > like it to be healthy and growing; all the real evidence points the other
> > way, no matter what IBM press releases may state.
> >
> > P.S. Sorry, Dave, zOSMF doesn't count. It's a tool. Nobody is installing
> a
> > mainframe so they can run it. We don't buy computers to run tools or
> > operating systems: we buy them to run applications. Big difference.
> >
> > On Sat, May 20, 2023 at 2:17 PM Bill Johnson <
> > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > The facts are readily available. Mainframe growth is undeniable. And
> will
> > > be for decades to come. Will weak banks foolishly buy what airline
> > > magazines are selling? Of course. Bad decisions are made in the
> business
> > > world daily. Ms Hovsepian should be more concerned with her company
> > > (Microfocus part) desperately trying to reverse engineer CICS so they
> can
> > > justify their decision to partner with Amazon Web Services.
> > >
> > >
> > > Sent from Yahoo Mail for iPhone
> > >
> > >
> > > On Saturday, May 20, 2023, 1:42 PM, Bob Bridges  >
> > > wrote:
> > >
> > > Bill, you said "bull", which I misunderstood to mean that you disagree.
> > > But the article you posted in support of that opinion (or whatever it
> is)
> > > doesn't contradict the OP's article.
> > >
> > > I'm just guessing here, but maybe you've been arguing with those
> > > mainframe-is-dying folks so long that you no longer notice the nuances.
> > Ms
> > > Hovsepian didn't say the mainframe is dying; she said a lot of banks
> > > (repeat banks) are considering (repeat considering) moving to the
> cloud.
> > >
> > > (To be fair, it sounds like she made the same mistake.  "Why the
> > readiness
> > > to 'swipe left' on their mainframe and COBOL applications?", she asks
> in
> > a
> > > throwaway inference.)
> > >
> > > ---
> > > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> > >
> > > /* Perseverance is not a long race; it is many short races one after
> > > another. */
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> Behalf
> > > Of Bill Johnson
> > > Sent: Saturday, May 20, 2023 10:27
> > >
> > > Bull.
> > >
> >
> https://www.flynetviewer.com/blog/20220922/global-mainframe-market-projected-grow-318-billion-2029
> > >
> > >

Re: Are Banks Breaking Up With Mainframes? | Forbes

On 22/5/2023 1:26 pm, Attila Fogarasi wrote:

Good point about NUMAand it is still a differentiator and competitive
advantage for IBM z.

How is NUMA a competitive advantage for z? Superdomes use Intel
UltraPath Interconnect (UPI) links that can do glueless NUMA.

IBM bought Sequent 20+ years ago to get their
excellent NUMA technology, and has since built some very clever cache
topology and management algorithms. AMD has historically been crippled in
real-world performance due to cache inefficiencies.

What historical generation of AMD silicon was crippled? The EPYC
supports up to 384MB of L3 cache and the specs and benchmarks suggest
the chiplet architecture can easily handle the I/O.

10 years ago CICS was at 30 billion transactions per day, so
volume has tripled in 10 years, during the massive growth of cloud.
Healthy indeed.

This is a common architectural pattern.

https://www.conferencecast.tv/talk-29844-nationwide-building-society-building-mobile-applications-and-a-speed-layer-with-mongodb#.talkPage-header

On Mon, May 22, 2023 at 2:56 PM David Crayford wrote:

Sent again in plain text. Apple mail is too clever for it’s own good!

On 22 May 2023, at 12:46 pm, David Crayford wrote:

On 21 May 2023, at 12:52 pm, Howard Rifkind

wrote:

Hundreds of PC type servers still can’t handle the huge amount of data

like a mainframe can.

Of course, that's an absurd statement! By "PC type," I assume you're
referring to x86? We can easily break this down. First things first, let's
forget about the "hundreds" requirement. A 32 single socket system is
enough to match up.

AMD EPYC is the poster child for single socket servers, running its novel
chiplet technology on a 5nm process node. AMD's infinity interconnects are
capable of massive I/O bandwidth. You can learn more about it here:
https://www.amd.com/en/technologies/infinity-architecture. Each socket
can have a maximum of 96 cores, but even if we use a conservative 64 cores
per socket, that's a scale-out of 2048 cores. AMD also has accelerators for
offload encryption/compression, etc.

Over in Intel land, the Ice Lake server platform is not quite as
impressive, but the QPI (Quick Path Interconnect) yet again handles huge
bandwidth. Intel also has accelerators such as their QAT, which can either
be on-die SoC or a PCIe card. It's not too dissimilar to zEDC but with the
advantage that it supports all popular compression formats and not just
DEFLATE. You can find more information here:
https://www.intel.com.au/content/www/au/en/architecture-and-technology/intel-quick-assist-technology-overview.html
.

A more apples-to-apples comparison would be the HP Superdome Flex, which
is a large shared memory system lashed together with NUMA interconnects,
with a whopping 32 sockets and a maximum core count of 896 on a single
vertically integrated system. HP Enterprise has technology such as nPars,
which is similar to PR/SM. They claim 99.999% availability on a single
system and even beyond when clustered.

On the Arm side, it gets even more interesting as the hyperscalers and
cloud builders are building their own kit. Although this technology is
almost certainly the growth area of non-x86 workloads, you can find more
details about it here:
https://www.nextplatform.com/2023/05/18/ampere-gets-out-in-front-of-x86-with-192-core-siryn-ampereone/
.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: XEDUT vs. ISPF (was: Typo ...)

It produces excellent quality code. I discussed this with my colleague and we 
agreed that it produces code of better quality then a lot of senior devs. When 
it’s capable of code reviews it’s a major game changer. 

> On 22 May 2023, at 3:56 pm, Seymour J Metz  wrote:
> 
> Its utility will depend on the quality of the code it produces. Can it be 
> trained to produce clean maintainable code?
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> David Crayford [dcrayf...@gmail.com]
> Sent: Sunday, May 21, 2023 11:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: XEDUT vs. ISPF (was: Typo ...)
> 
>> On 22 May 2023, at 8:15 am, Farley, Peter 
>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> Please explain what "co-pilot" in this context means.  I am not familiar 
>> with that reference.
> 
> Github co-pilot is an AI programming assistant. You can ask it to do things 
> like write a search algorithm or a Java servlet application. It’s powered by 
> OpenAI the deep learning technology used by ChatGPT. It builds its language 
> model from millions of lines of open source code. I’m interested if it could 
> be trained on large legacy code bases written in languages like COBOL. This 
> would be very useful onboarding next gen developers as the inevitable skills 
> shortage is already starting to bite.
> 
> I doubt that ISPF will be used by next gen devs who are being trained to use 
> VS Code which supports copilot. It’s not just for GUI IDEs though, Microsoft 
> have released a Vim (neovim) plugin https://github.com/github/copilot.vim.
> 
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> David Crayford
>> Sent: Sunday, May 21, 2023 7:47 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: XEDUT vs. ISPF (was: Typo ...)
>> 
>> Has anybody developed a co-pilot plugin for ISPF yet? :)
>> 
>>> On 21 May 2023, at 3:42 pm, Seymour J Metz  wrote:
>>> 
>>> Well, I am a TSO bigot and grew up on CLIST, but once I had REXX available 
>>> in TSO/E I bid CLIST a fond AMF. As is common in such cases, while REXX is 
>>> in general far better than EXEC2 and CLIST, there are things that that it 
>>> lacks.
>>> 
>>> ISPF versus XEDIT is harder.ISPF has significant advantages as an 
>>> application framework, and ISPF/PDF EDIT has some nice features that XEDIT 
>>> lacks, but XEDIT is on balance a much better editor.
>>> 
>>> 
>>> --
>>> Shmuel (Seymour J.) Metz
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
>>> behalf of Jack Zukt [jzuk...@gmail.com]
>>> Sent: Saturday, May 20, 2023 3:55 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: XEDUT vs. ISPF (was: Typo ...)
>>> 
>>> Hi,
>>> That made for some interesting reading. I was quite proficient with
>>> REXX and XEDIT before moving to MVS and ISPF. The first MVS I worked
>>> with did not yet have REXX. It was helish doing the transition to ISPF and 
>>> CLIST.
>>> I still find VM help much better than MVS's. One of the first things
>>> that I do when starting on a new MVS system is to put an edit macro
>>> named QQ on the SYSPROC or SYSEXEC concatenation, so that I do not
>>> have to write CANCEL. I really do not like having that on a pfkey. Too
>>> much grief because of that.
>>> I find that XEDIT environment capabilities permit us to tailor our
>>> working environment far more than ISPF but, as always, I think that
>>> has more to do with our path than with the products themselves.
>>> As I said at the beginning, it really was an interesting reading.
>>> Regards
>>> Jack
>>> 
 On Sat, May 20, 2023, 00:08 Paul Gilmartin <
 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
 
> On Fri, 19 May 2023 18:32:57 -0400, Phil Smith III wrote:
> ...
>> I was trying to automate that in a macro on PF3.
> 
> Yeah, that makes sense.
> 
 I learned a smattering of ISPF before any XEDIT; the latter in the
 era before PQUIT and QQIT intruded: the wrong solution.  But I
 immediately longed for ISPF's smart END which did a Save only when
 needed and left the timestamp unchanged otherwise.
 
 And I was irritated by XEDIT's behavior of *always* scrolling to
 center the target of a successful search, usually needlessly
 
 And it was disappointing that the XEDIT-based *LIST menus always ran
 in separate rings, never sharing with each other, PEEK, and XEDIT.
 They should have used ADDRESS XEDIT instead of CMS.
 
 I wasted too much time scripting around such things, never modifying
 IBM code, only using undocumented interfaces.
 And it all went for naught when a major update broke them
 
>> --
>> 
>> This message and any attachments are intended only for the use of the 
>> addressee and may contain information that is privileged and

Re: XEDUT vs. ISPF (was: Typo ...)