Re: Banks migrate from mainframes to AI-driven cloud tech
One of the big drawbacks to non mainframe clouds is the ease with which they are hacked. AWS & Azure are hacked pretty frequently. https://www.securityweek.com/microsoft-cloud-hack-exposed-more-than-exchange-outlook-emails/ https://cybernews.com/security/amazon-cloud-loses-silver-lining/ Sent from Yahoo Mail for iPhone On Sunday, February 11, 2024, 6:51 PM, Seymour J Metz wrote: With current technology, Z has the edge for I/O and RAS, but not for CPU. What makes sense depends very much on the business and legal requirements. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Sunday, February 11, 2024 3:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Banks migrate from mainframes to AI-driven cloud tech Shmuel wrote: >I was thinking of zCX as hosting containers >The process for deploying virtual machines in z/VM is different >although it also eliminates manual setup that used to be necessary. >i was trying to illustrated that the automation of deployment was not >limited to the cloud. Ah! Gotcha. Sure, containers is containers is containers. But given the expense of IBM zSystems MIPS, it's hard to envision overprovisioning for possible usage spikes the way x86 clusters do. Yes, there's CoD, which is sort of the forerunner to this elastic capacity, but not nearly as automated. To be clear: I'm unconvinced that cloud elasticity is a particularly useful capacity in most serious business use cases. Black Friday (heck, the whole holiday season) maybe, but that's moderately predictable, and CoD or just plain ol' capacity planning can deal with that. Similarly, I'm unconvinced that zCX is meaningful other than as a "See, we can do stuff like this too". I don't see folks embracing it significantly [yet--still relatively early days, obviously). What I've seen is people going "Neat!" but then.what? I do think that the management-by-magazine folks are all aTwitter (or is that aX now?) about cloud capabilities because they think they will eliminate the need for capacity management and thus save them money. My bet is maybe on the first, no on the second. But I have nothing to support that other than my gut based on experience. (And I had Thai food for lunch, so gut may be even less reliable than usual!) -- 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
IBM-MAIN Welcome Message
Reposting the Welcome message for this list... * DISCLAIMER * All subscribers to this list are responsible for the information contained below. Failure to familiarize yourself with the guidelines and policies of this list will not absolve you from the consequences of violating them. * WELCOME! * Any Questions? Write to: ibm-main-requ...@listserv.ua.edu Please save this e-mail for future reference! IBM-MAIN is primarily for the discussion of IBM mainframe topics. Please view IBM-MAIN as an opportunity to network with other mainframe professionals from around the United States and around the world. Discussions should remain related to mainframes. Profanity is not welcome, nor is language which demeans or belittles other people or groups of people. It is further expected that list members will conduct themselves in a mature and polite manner towards fellow list members. "Flames" will not be tolerated. The list owner reserves the right to take any action he feels appropriate to ensure the smooth operation of the list. IBM-MAIN is an e-mail discussion list. Despite casual references to the contrary in popular use, an e-mail discussion list is not “a listserv.” “LISTSERV” is a registered trademark (of L-Soft, Incorporated) and refers to the server on which lists are hosted, not to the lists themselves. One LISTSERV server will typically host numerous lists. As an IBM-MAIN list member, you will communicate with the LISTSERV server for a number of reasons, such as when you want to post to the list, alter your subscription options, search the archives, or update your subscription address. All LISTSERV commands are sent in the body of e-mail (not in the Subject: line) to: lists...@listserv.ua.edu * POLICY REGARDING VIOLATIONS OF IBM-MAIN POLICIES * Because the above policies are in place for the good of the list, and because general admonishments to the list membership do not usually succeed in altering behavior deemed detrimental to the list, the list owner reserve the right to take action individually against list members violating IBM-MAIN policies. This could be being set to REVIEW. NOPOST, or removal from the list. Remember, please save this e-mail for future reference! As this Welcome does change from time to time, you should know that you can always grab a copy of the current version by sending the command: GET IBM-MAIN WELCOME in the body of e-mail to: lists...@listserv.ua.edu Virtually, Darren Evans-Young (List Owner) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Banks migrate from mainframes to AI-driven cloud tech
With current technology, Z has the edge for I/O and RAS, but not for CPU. What makes sense depends very much on the business and legal requirements. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Sunday, February 11, 2024 3:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Banks migrate from mainframes to AI-driven cloud tech Shmuel wrote: >I was thinking of zCX as hosting containers >The process for deploying virtual machines in z/VM is different >although it also eliminates manual setup that used to be necessary. >i was trying to illustrated that the automation of deployment was not >limited to the cloud. Ah! Gotcha. Sure, containers is containers is containers. But given the expense of IBM zSystems MIPS, it's hard to envision overprovisioning for possible usage spikes the way x86 clusters do. Yes, there's CoD, which is sort of the forerunner to this elastic capacity, but not nearly as automated. To be clear: I'm unconvinced that cloud elasticity is a particularly useful capacity in most serious business use cases. Black Friday (heck, the whole holiday season) maybe, but that's moderately predictable, and CoD or just plain ol' capacity planning can deal with that. Similarly, I'm unconvinced that zCX is meaningful other than as a "See, we can do stuff like this too". I don't see folks embracing it significantly [yet--still relatively early days, obviously). What I've seen is people going "Neat!" but then.what? I do think that the management-by-magazine folks are all aTwitter (or is that aX now?) about cloud capabilities because they think they will eliminate the need for capacity management and thus save them money. My bet is maybe on the first, no on the second. But I have nothing to support that other than my gut based on experience. (And I had Thai food for lunch, so gut may be even less reliable than usual!) -- 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: Banks migrate from mainframes to AI-driven cloud tech
Shmuel wrote: >I was thinking of zCX as hosting containers >The process for deploying virtual machines in z/VM is different >although it also eliminates manual setup that used to be necessary. >i was trying to illustrated that the automation of deployment was not >limited to the cloud. Ah! Gotcha. Sure, containers is containers is containers. But given the expense of IBM zSystems MIPS, it's hard to envision overprovisioning for possible usage spikes the way x86 clusters do. Yes, there's CoD, which is sort of the forerunner to this elastic capacity, but not nearly as automated. To be clear: I'm unconvinced that cloud elasticity is a particularly useful capacity in most serious business use cases. Black Friday (heck, the whole holiday season) maybe, but that's moderately predictable, and CoD or just plain ol' capacity planning can deal with that. Similarly, I'm unconvinced that zCX is meaningful other than as a "See, we can do stuff like this too". I don't see folks embracing it significantly [yet--still relatively early days, obviously). What I've seen is people going "Neat!" but then.what? I do think that the management-by-magazine folks are all aTwitter (or is that aX now?) about cloud capabilities because they think they will eliminate the need for capacity management and thus save them money. My bet is maybe on the first, no on the second. But I have nothing to support that other than my gut based on experience. (And I had Thai food for lunch, so gut may be even less reliable than usual!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Banks migrate from mainframes to AI-driven cloud tech
I was thinking of zCX as hosting containers The process for deploying virtual machines in z/VM is different although it also eliminates manual setup that used to be necessary. i was trying to illustrated that the automation of deployment was not limited to the cloud. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Sunday, February 11, 2024 3:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Banks migrate from mainframes to AI-driven cloud tech Shmuel asked: >How do containers in the cloud differ from containers on the >mainframe? How difficult is it to provision a new z/VM virtual machine >with contemporary software? ow much is just different coverage in the >in-flight magazines versus substantive benefits of the cloud? Just checking: are you considering a z/VM VM (z/VM??) a container? I wouldn't argue with that, just checking. Anyway, it's.different. While z/VM has the "pool" concept, it's not quite the same as "just fire up another container". But at not-too-high an altitude, I'd say they were very much the same. Acourse the IBM zSystems MIPS are still more expensive. -- 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: Banks migrate from mainframes to AI-driven cloud tech
Shmuel asked: >How do containers in the cloud differ from containers on the >mainframe? How difficult is it to provision a new z/VM virtual machine >with contemporary software? ow much is just different coverage in the >in-flight magazines versus substantive benefits of the cloud? Just checking: are you considering a z/VM VM (z/VM??) a container? I wouldn't argue with that, just checking. Anyway, it's.different. While z/VM has the "pool" concept, it's not quite the same as "just fire up another container". But at not-too-high an altitude, I'd say they were very much the same. Acourse the IBM zSystems MIPS are still more expensive. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Banks migrate from mainframes to AI-driven cloud tech
Confirmation bias. Sent from Yahoo Mail for iPhone On Sunday, February 11, 2024, 11:14 AM, Dave Beagle <0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote: LOL, new customers were confirmed about a year ago on this very forum. Perhaps your memory is fading? The mainframe is still by far the most secure, which is why companies needing the best security still use it. Also, it can process a trillion web transactions per day and that was in 2019. A huge chunk of Fortune 500 companies use mainframe systems, at least 71%. Credit transactions heavily rely on sophisticated mainframe systems. Globally 90% of credit card transactions happen on mainframe systems. Worldwide, mainframe systems handle 68% of information technology workloads. The “mainframe is dying” crowd has been wrong for 30 years. And will be wrong for another 30. IBM stock is hitting new highs and growing revenue again. Sent from Yahoo Mail for iPhone On Saturday, February 10, 2024, 9:32 PM, Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: On Sat, 10 Feb 2024 19:56:06 -0500, Phil Smith III wrote: > ... about IBM zSystems than other platforms these days either, alas. > This discussion is driven by a mixture of technical expertise and sentiment. -- gil -- 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: Banks migrate from mainframes to AI-driven cloud tech
LOL, new customers were confirmed about a year ago on this very forum. Perhaps your memory is fading? The mainframe is still by far the most secure, which is why companies needing the best security still use it. Also, it can process a trillion web transactions per day and that was in 2019. A huge chunk of Fortune 500 companies use mainframe systems, at least 71%. Credit transactions heavily rely on sophisticated mainframe systems. Globally 90% of credit card transactions happen on mainframe systems. Worldwide, mainframe systems handle 68% of information technology workloads. The “mainframe is dying” crowd has been wrong for 30 years. And will be wrong for another 30. IBM stock is hitting new highs and growing revenue again. Sent from Yahoo Mail for iPhone On Saturday, February 10, 2024, 9:32 PM, Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: On Sat, 10 Feb 2024 19:56:06 -0500, Phil Smith III wrote: > ... about IBM zSystems than other platforms these days either, alas. > This discussion is driven by a mixture of technical expertise and sentiment. -- gil -- 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: Reading a scratch tape
AFAIK, there no PDSE in CMS OS simulation. I'd have to check the z/VM documentation to be sure. That said, I abandoned EXEC and EXEC2 once REXX was available. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Sunday, February 11, 2024 9:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Reading a scratch tape On Sun, 11 Feb 2024 13:44:16 +, Seymour J Metz wrote: >EXEC2 didn't exist in 1971. > But later, could EXEC2 read a PDSE? > >From: Seymour J Metz >Sent: Saturday, February 10, 2024 8:09 PM > >I would assume that it's difficult or impossible with PDSE, but that there is >less need in PDSE2, due to generations. -- gil -- 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: Reading a scratch tape
On Sun, 11 Feb 2024 13:44:16 +, Seymour J Metz wrote: >EXEC2 didn't exist in 1971. > But later, could EXEC2 read a PDSE? > >From: Seymour J Metz >Sent: Saturday, February 10, 2024 8:09 PM > >I would assume that it's difficult or impossible with PDSE, but that there is >less need in PDSE2, due to generations. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Reading a scratch tape
EXEC2 didn't exist in 1971. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Saturday, February 10, 2024 8:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Reading a scratch tape I would assume that it's difficult or impossible with PDSE, but that there is less need in PDSE2, due to generations. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Friday, February 9, 2024 6:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Reading a scratch tape On Thu, 8 Feb 2024 22:41:03 +, Pommier, Rex wrote: > >Actually, it does make sense (at least to me) to have this threshold set. >We've gone back more than once to rescue a developer or support person who >inadvertently scratched a tape the day before and we were able to recover it >for them by using this "expired but not really" feature...> > I believe PDS86 has a similar ability to recover deleted PDS members. Does this work for PDSE? I suspect it's harder. Is that used as an argument against migrating from PDS to PDSE? That's what generations are for. -- gil -- 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
