Re: Banks migrate from mainframes to AI-driven cloud
LOL! On 2/10/2024 4:30 PM, Lennie Dymoke-Bradshaw wrote: " I have not seen a RISC system in 30 years" " Sent from my iPhone" What irony. Lennie -- 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
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
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
Re: Banks migrate from mainframes to AI-driven cloud tech
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? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Saturday, February 10, 2024 7:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Banks migrate from mainframes to AI-driven cloud tech Bob Bridges wrote: >"...where mainframes' resilience meets the agility of cloud computing." >What is the "agility" of the cloud, exactly? The ability to spin up more instances [of applications that are built that way, obviously] on demand/automatically. For certain very peaky workloads this is a huge win. Not that I'm in any way arguing that these are important applications in the real world, but things like Pinterest and Instagram at least started this way in AWS or GCP, still use the model (albeit presumably on their own cloud now): when something big happens and usage blows up, instead of just getting dog-slow or crashing, more instances get spun up and things hum along. Yes, there are a ton of assumptions involved there-capacity/competence/security/etc. of the cloud provider. I'm very chary of public cloud for "real work" for this reason. But if you look at it at the right angle (perhaps squinting a lot!), you can see that-again, for the right workloads-it gets you out of the business of provisioning/capacity management/etc. Of course it also encourages inefficient code, but ?maybe? that's OK (again, in the right use cases). One of the biggest problems, of course, is that folks don't understand the caveats, go in with both feet first, and get burned. All of the CSPs, for example, offer some sort of cryptographic service. None of them are BYOK (Bring Your Own Key)-in other words, you're trusting the service itself not to attack you or to get compromised and allow an attack. WCGW? For software vendors, the attraction is that they don't have to build/manage as much of the platform as they do when they provide a fully functional server. All that really does is move that requirement from the vendor (once) to each customer, so it's a win for the vendor and a loss for the customer. That is, the customer has to do all the vulnerability scanning, patching, etc., instead of having the vendor do the heavy lifting (the wise customer does the scanning anyway, but then expects the vendor to provide the updates.) I keep waiting for the customer world to figure this out; hasn't happened yet AFAICT. Weird. -- 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
Dave Beagle wrote: >Large amounts of data, including AI, will require processing power >(and security) unlike anything DP has seen. Perfect for the mainframe. >And, there ARE new mainframe shops. "processing power"-the mainframe lost that battle long ago. "security"-there's nothing inherently more secure about IBM zSystems than other platforms these days either, alas. New mainframe shops? As the saying goes, "Pics or it didn't happen". I'd be thrilled to learn that these exist! -- 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
Bob Bridges wrote: >"...where mainframes' resilience meets the agility of cloud computing." >What is the "agility" of the cloud, exactly? The ability to spin up more instances [of applications that are built that way, obviously] on demand/automatically. For certain very peaky workloads this is a huge win. Not that I'm in any way arguing that these are important applications in the real world, but things like Pinterest and Instagram at least started this way in AWS or GCP, still use the model (albeit presumably on their own cloud now): when something big happens and usage blows up, instead of just getting dog-slow or crashing, more instances get spun up and things hum along. Yes, there are a ton of assumptions involved there-capacity/competence/security/etc. of the cloud provider. I'm very chary of public cloud for "real work" for this reason. But if you look at it at the right angle (perhaps squinting a lot!), you can see that-again, for the right workloads-it gets you out of the business of provisioning/capacity management/etc. Of course it also encourages inefficient code, but ?maybe? that's OK (again, in the right use cases). One of the biggest problems, of course, is that folks don't understand the caveats, go in with both feet first, and get burned. All of the CSPs, for example, offer some sort of cryptographic service. None of them are BYOK (Bring Your Own Key)-in other words, you're trusting the service itself not to attack you or to get compromised and allow an attack. WCGW? For software vendors, the attraction is that they don't have to build/manage as much of the platform as they do when they provide a fully functional server. All that really does is move that requirement from the vendor (once) to each customer, so it's a win for the vendor and a loss for the customer. That is, the customer has to do all the vulnerability scanning, patching, etc., instead of having the vendor do the heavy lifting (the wise customer does the scanning anyway, but then expects the vendor to provide the updates.) I keep waiting for the customer world to figure this out; hasn't happened yet AFAICT. Weird. -- 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
It's in the intrinsic angular momentum. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Bob Bridges <0587168ababf-dmarc-requ...@listserv.ua.edu> Sent: Saturday, February 10, 2024 3:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Banks migrate from mainframes to AI-driven cloud tech "...where mainframes’ resilience meets the agility of cloud computing." What is the "agility" of the cloud, exactly? --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Always look a gift horse in the mouth. It may have hoof-and-mouth disease. -Bob Bridges, 1977 */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Regan Sent: Friday, February 9, 2024 06:35 https://www.finextra.com/newsarticle/43673/banks-migrate-from-mainframes-to-ai-driven-cloud-tech -- 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
" I have not seen a RISC system in 30 years" " Sent from my iPhone" What irony. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Beaver Sent: 10 February 2024 15:52 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Banks migrate from mainframes to AI-driven cloud I have not seen a RISC system in 30 years Sent from my iPhone No one said I could type with one thumb > On Feb 10, 2024, at 09:27, Arthur Fichtl wrote: > > Am 10.02.2024 um 06:00 schrieb IBM-MAIN automatic digest system: > migration from the mainframe? > > The mainframe as a piece of hardware might vanish. But the Exabytes of MF > software might move to some sort of virtualization platform, I guess, may > that be based on Intel, cloud, or RISC . > > > -- > Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft. > www.avast.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Banks migrate from mainframes to AI-driven cloud tech
"...where mainframes’ resilience meets the agility of cloud computing." What is the "agility" of the cloud, exactly? --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Always look a gift horse in the mouth. It may have hoof-and-mouth disease. -Bob Bridges, 1977 */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Regan Sent: Friday, February 9, 2024 06:35 https://www.finextra.com/newsarticle/43673/banks-migrate-from-mainframes-to-ai-driven-cloud-tech -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Lets have a thought exercise: WAS Banks migrate from mainframes to AI-driven cloud tech
Who wants to have a thought exercise where we can see where we end up. In early wood frame constrution, joins were done with things like friction dovetails and Pegs. Along comes the next techology - metal.Look at the new thing - Nails. Lets use them to join our wood. Metal technology changes --- and we get Screws. An everybody rejoices at the wonderful new uses. Parallels are glue and its family But wait, how do we join metals --- oh yeah... metal pegs (rivets)... Pegs can still work, and look at this new Bolt thing. With parallels called welding. - NOW --- Everybody step back from your current comfort zone. Be it mainframe or server. On-siteor Cloud. And we want to 'DO' something using computers. What I believe is that any technology can be beaten into shape to perform the task with enough effort and time. The problems start when humans get involved. ALL humans have a bias to use what they find easiest and know best. Put two or more groups of these to the task and you will get many many designs... all of them using the tools the designer knows best. Then you have to "pick a winner" and go with that.The decision may be based on categories totally outside the technology arguements (like budgets or legal requirements or the manager going out to lunch with a sales rep). Time passes and new technologies come along... New thoughts on how to accoimplish the task... With everyone arguing that "My" way is the best for an entire list of reasons that "I" view as important. The wars start when what "I" think is important is not what "You" think is important. This can degrade into personal attacks and calling the competitor degrading names. - Now for the thought exercise: IF we apply this view to all of the newsgroups, web articles, sales materials and water cooler chats.Can you find reasons why Tasks don't get done and are always being redone? -- 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
I have not seen a RISC system in 30 years Sent from my iPhone No one said I could type with one thumb > On Feb 10, 2024, at 09:27, Arthur Fichtl wrote: > > Am 10.02.2024 um 06:00 schrieb IBM-MAIN automatic digest system: > migration from the mainframe? > > The mainframe as a piece of hardware might vanish. But the Exabytes of MF > software might move to some sort of virtualization platform, I guess, may > that be based on Intel, cloud, or RISC . > > > -- > Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft. > www.avast.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Banks migrate from mainframes to AI-driven cloud
Am 10.02.2024 um 06:00 schrieb IBM-MAIN automatic digest system: migration from the mainframe? The mainframe as a piece of hardware might vanish. But the Exabytes of MF software might move to some sort of virtualization platform, I guess, may that be based on Intel, cloud, or RISC . -- Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft. www.avast.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XTL64E_EXTENTADDR
It should be apparent that if you're using a 4-byte address from an 8-byte PSW, you cannot possibly handle information from an extent list that might have addresses above 2G. 16-byte PSW with its 8-byte address (and similarly GR high halves) is provided only for time of error. That's not either SDWAEC1/SDWAEC2 of course. If using 8-byte PSW, XTL64 is not needed, the "normal" extent list will do. Further, I don't recall how you are actually thinking to locate the XTL64. If you're using CSVQUERY (such as based on the address that you seem to be interested in), I can say only that that is a bad thing to do in a "general recovery routine" for all the reasons I laid out long ago to one of your earlier posts, including making sure that your recovery routine actually gets the opportunity to do the things that recovery routines must do (and not get short-circuited by calling an unnecessary routine that (just because of the nature of things) might unexpectedly fail). You might survive if you have established nested recovery to catch such a failure (which would surely be the minimum you have to do). But if you do provide CSVQUERY with an address and it finds it (based on such things as your search criteria - JPALPA or just JPA, for example), then you have a change to get an XTL64. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
