Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
I find a great deal of value in reading your posts, Steve. Knowing that you have experience with Amdahl in hardware adds to my respect for your insights. > On 29 Aug 2023, at 8:35 am, Steve Thompson wrote: > > Back in the day, we worked on RAS. So we put in error detection hardware > (sometimes that was "firmware, or macrocode) and IBM and all our competitors > were doing the same. And the idea was to have redundant power supplies so > that a CE could do maint, and not take down the system. And if possible, > redundant channel paths to a device controller so that you could pull a > channel cable and replace it. > > Today, with IBM, you can add or subtract CPUs while the machine is running. > But, at least with the z15s, you could not add RAM without taking the system > down, as in power it down. > > So that would be a RAS hit, or, cause you to miss your 99.999 target. > > For people who do hardware and to some degree software (O/S stuff), you do > all you can to recover from any problem. I like VM and its ability to see it > is injured and it will IPL itself. But, to keep those SLAs, there is SSI. So > an LPAR can move its workload to another LPAR (PAIRs determined in advance > here) and keep that work running. We did this at a large health insurer so > that we could do VM upgrades with no outages. > > So how you measure that up time depends on the equipment and ability to do > HOT SWAP, and related so you do not take an outage. > > What happens if a WINTEL server running MQ buys the farm? Those inflight > transactions going through that server may time out and have to be re-driven. > Is this considered an outage? Not if you have a second one handling the load > and it takes over. But that one or 10(?) users may see an error message. Does > that count as an outage if the user only loses a few seconds in getting an > answer? Or a Pharmacy getting info? Or an OR getting info on drug > interactions? > > Need some perspective. > > Steve Thompson > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
On 29/8/2023 8:35 am, Steve Thompson wrote: What happens if a WINTEL server running MQ buys the farm? Those inflight transactions going through that server may time out and have to be re-driven. Is this considered an outage? Not if you have a second one handling the load and it takes over. But that one or 10(?) users may see an error message. Does that count as an outage if the user only loses a few seconds in getting an answer? Or a Pharmacy getting info? Or an OR getting info on drug interactions? Distributed systems are very different beasts. Mitigating network partitions has lead to the CAP theorem. Apache Kafka is a popular message broker on distributed systems and it's highly available if you run it on a least 3 nodes, which can tolerate the loss of 1 broker. 5 nodes for 2 brokers. Orchestration platforms such as Kubernetes and Open Shift make it quite easy to deploy clusters, even using availability zones for replicate to a remote data center. All brokers replicate with each other and are coordinated on the control plane using a consensus algorithm like Raft. As a mainframe guy I was blown away how anybody would find eventual consistency acceptable, but they do. https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/Raft_(algorithm) z is the king of CA systems as it's not susceptible to network partitions. That's why I find it odd why people would want to run systems like Kafka on z/OS when it's architecture is designed to run on unreliable commodity hardware. Need some perspective. Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Back in the day, we worked on RAS. So we put in error detection hardware (sometimes that was "firmware, or macrocode) and IBM and all our competitors were doing the same. And the idea was to have redundant power supplies so that a CE could do maint, and not take down the system. And if possible, redundant channel paths to a device controller so that you could pull a channel cable and replace it. Today, with IBM, you can add or subtract CPUs while the machine is running. But, at least with the z15s, you could not add RAM without taking the system down, as in power it down. So that would be a RAS hit, or, cause you to miss your 99.999 target. For people who do hardware and to some degree software (O/S stuff), you do all you can to recover from any problem. I like VM and its ability to see it is injured and it will IPL itself. But, to keep those SLAs, there is SSI. So an LPAR can move its workload to another LPAR (PAIRs determined in advance here) and keep that work running. We did this at a large health insurer so that we could do VM upgrades with no outages. So how you measure that up time depends on the equipment and ability to do HOT SWAP, and related so you do not take an outage. What happens if a WINTEL server running MQ buys the farm? Those inflight transactions going through that server may time out and have to be re-driven. Is this considered an outage? Not if you have a second one handling the load and it takes over. But that one or 10(?) users may see an error message. Does that count as an outage if the user only loses a few seconds in getting an answer? Or a Pharmacy getting info? Or an OR getting info on drug interactions? Need some perspective. Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
This is easy. Another company offering 5 9’s. https://www.sdxcentral.com/articles/sponsored/syndicated/why-five-nines-of-service-availability-matters-for-sase/2023/02/ Sent from Yahoo Mail for iPhone On Monday, August 28, 2023, 8:12 PM, David Crayford wrote: > On 29 Aug 2023, at 8:05 am, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > You’re the weakest link here. How can IBM guarantee 99.999 uptime for systems > they don’t make or support? I’ve worked for numerous companies that didn’t > have outages of the mainframe for years. Health insurance companies can get > huge fines if their systems are unavailable. I also looked on LinkedIn and > there are resumes there that claim they managed systems to 99.999 > availability. Google it. It’s promised and delivered quite often. In fact > 99.999 isn’t all that amazing any longer. > > So your claim is, if my phone dies and I can’t get to my JP Morgan accounts, > then JP Morgan doesn’t have 99.999 uptime? There is nothing more tedious than a straw man argument. It’s a good indication that somebody is trying to argue a lost cause. > No wonder they aren’t buying your crappy software. Actually, they do run our software. Almost every mainframe site runs our software. Most of them think it’s IBM software as it’s badged IBM. > > > Sent from Yahoo Mail for iPhone > > > On Monday, August 28, 2023, 7:47 PM, David Crayford > wrote: > >> On 29 Aug 2023, at 7:41 am, Bill Johnson >> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: >> >> You’re ASSuming Zelle is on the mainframe. > > Why does it matter where it’s running. Banking applications are only as > reliable as their weakest link. > >> Multiple 9’s is a fact and many companies are running it. > > Prove it. Provide a link to a bank offering a 99.999% SLA on their banking > services. > >> You’re an idiot. More truth. Looks like you threaten people on the internet >> too. > > > >> >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, August 28, 2023, 7:27 PM, David Crayford >> wrote: >> >> On 28/8/2023 10:21 pm, Bill Johnson wrote: >>> LOL, there’s Crayfish making stupid comments again. The difference between >>> me and Perryman is I tell the truth. IBM does offer multiple 9’s uptime. >>> And numerous banks have the setup necessary. >> >>> JP Morgan (a REAL bank) spends BILLIONS per year on IT. >> >> Yes. And they still have outages >> >> https://piunikaweb.com/2023/08/24/chase-bank-app-website-down-servers-not-working-online-and-mobile-banking-suffers/ >> https://www.americanbanker.com/news/zelle-outage-at-jpmorgan-chase-is-red-flag-for-banks >> https://piunikaweb.com/2023/08/25/wells-fargo-website-and-app-down-not-working-online-banking-suffers/ >> >> As banks rush to modernize their services the applications have become >> far more compex. Especially integrating new technologies into legacy >> systems. More points of failure. 99.999% service availability is a myth. >> >> >> >>> >>> Sent from Yahoo Mail for iPhone >>> >>> >>> On Monday, August 28, 2023, 7:15 AM, David Crayford >>> wrote: >>> >>> On 27/8/2023 11:05 am, Tom Brennan wrote: A bigger problem is Jon says things like this with such conviction and authority that other people reading these posts, perhaps years from now, will think they are true. >>> Don't engage with him! There's no point in debating with a troll. >>> >>> Lately, he's been banging on about the 99.99% availability on the >>> z16. It's clear he's either deeply ignorant or gullible. In any case, it >>> seems he missed the fine print: >>> https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's willing to spend tens >>> of millions of dollars to run a small Linux rack?) >>> >>> "DISCLAIMER: IBM internal data based on measurements and projections was >>> used in calculating the expected value. Necessary components include IBM >>> z16; IBM z/VM V7.2 systems collected in a Single System Image, each >>> running RHOCP 4.10 or above; >>> IBM Operations Manager; GDPS 4.5 for management of data recovery and >>> virtual machine recovery across metro distance systems and storage, >>> including Metro Multi-site workload and GDPS Global; and IBM DS8000 >>> series storage with IBM HyperSwap. A >>> MongoDB v4.2 workload was used. Necessary resiliency technology must be >>> enabled, including z/VM Single System Image clustering, GDPS xDR Proxy >>> for z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management >>> of local storage devices. >>> Application-induced outages are not included in the above measurements. >>> Other configurations (hardware or software) may provide different >>> availability characteristics." >>> >>> Could it be that Jon Perryman is actually Bill Johnson in disguise, >>> using ChatGPT to compose his posts? Does he have a Linkedin profile >>> where we can read he's credentials? >>> On 8/26/2023 7:31 PM, David Spiegel wrote: > Hi Jon, > You said: ".
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Welcome to 7 9’s idiot. https://www.itmanagement101.co.uk/who-commits-to-five-nines-99-999-availability/ Sent from Yahoo Mail for iPhone On Monday, August 28, 2023, 8:12 PM, David Crayford wrote: > On 29 Aug 2023, at 8:05 am, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > You’re the weakest link here. How can IBM guarantee 99.999 uptime for systems > they don’t make or support? I’ve worked for numerous companies that didn’t > have outages of the mainframe for years. Health insurance companies can get > huge fines if their systems are unavailable. I also looked on LinkedIn and > there are resumes there that claim they managed systems to 99.999 > availability. Google it. It’s promised and delivered quite often. In fact > 99.999 isn’t all that amazing any longer. > > So your claim is, if my phone dies and I can’t get to my JP Morgan accounts, > then JP Morgan doesn’t have 99.999 uptime? There is nothing more tedious than a straw man argument. It’s a good indication that somebody is trying to argue a lost cause. > No wonder they aren’t buying your crappy software. Actually, they do run our software. Almost every mainframe site runs our software. Most of them think it’s IBM software as it’s badged IBM. > > > Sent from Yahoo Mail for iPhone > > > On Monday, August 28, 2023, 7:47 PM, David Crayford > wrote: > >> On 29 Aug 2023, at 7:41 am, Bill Johnson >> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: >> >> You’re ASSuming Zelle is on the mainframe. > > Why does it matter where it’s running. Banking applications are only as > reliable as their weakest link. > >> Multiple 9’s is a fact and many companies are running it. > > Prove it. Provide a link to a bank offering a 99.999% SLA on their banking > services. > >> You’re an idiot. More truth. Looks like you threaten people on the internet >> too. > > > >> >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, August 28, 2023, 7:27 PM, David Crayford >> wrote: >> >> On 28/8/2023 10:21 pm, Bill Johnson wrote: >>> LOL, there’s Crayfish making stupid comments again. The difference between >>> me and Perryman is I tell the truth. IBM does offer multiple 9’s uptime. >>> And numerous banks have the setup necessary. >> >>> JP Morgan (a REAL bank) spends BILLIONS per year on IT. >> >> Yes. And they still have outages >> >> https://piunikaweb.com/2023/08/24/chase-bank-app-website-down-servers-not-working-online-and-mobile-banking-suffers/ >> https://www.americanbanker.com/news/zelle-outage-at-jpmorgan-chase-is-red-flag-for-banks >> https://piunikaweb.com/2023/08/25/wells-fargo-website-and-app-down-not-working-online-banking-suffers/ >> >> As banks rush to modernize their services the applications have become >> far more compex. Especially integrating new technologies into legacy >> systems. More points of failure. 99.999% service availability is a myth. >> >> >> >>> >>> Sent from Yahoo Mail for iPhone >>> >>> >>> On Monday, August 28, 2023, 7:15 AM, David Crayford >>> wrote: >>> >>> On 27/8/2023 11:05 am, Tom Brennan wrote: A bigger problem is Jon says things like this with such conviction and authority that other people reading these posts, perhaps years from now, will think they are true. >>> Don't engage with him! There's no point in debating with a troll. >>> >>> Lately, he's been banging on about the 99.99% availability on the >>> z16. It's clear he's either deeply ignorant or gullible. In any case, it >>> seems he missed the fine print: >>> https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's willing to spend tens >>> of millions of dollars to run a small Linux rack?) >>> >>> "DISCLAIMER: IBM internal data based on measurements and projections was >>> used in calculating the expected value. Necessary components include IBM >>> z16; IBM z/VM V7.2 systems collected in a Single System Image, each >>> running RHOCP 4.10 or above; >>> IBM Operations Manager; GDPS 4.5 for management of data recovery and >>> virtual machine recovery across metro distance systems and storage, >>> including Metro Multi-site workload and GDPS Global; and IBM DS8000 >>> series storage with IBM HyperSwap. A >>> MongoDB v4.2 workload was used. Necessary resiliency technology must be >>> enabled, including z/VM Single System Image clustering, GDPS xDR Proxy >>> for z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management >>> of local storage devices. >>> Application-induced outages are not included in the above measurements. >>> Other configurations (hardware or software) may provide different >>> availability characteristics." >>> >>> Could it be that Jon Perryman is actually Bill Johnson in disguise, >>> using ChatGPT to compose his posts? Does he have a Linkedin profile >>> where we can read he's credentials? >>> On 8/26/2023 7:31 PM, David Spiegel wrote: > Hi Jon, > You said: "...The M in SMP/e stands for Maintenance ..." > This statem
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
> On 29 Aug 2023, at 8:05 am, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > You’re the weakest link here. How can IBM guarantee 99.999 uptime for systems > they don’t make or support? I’ve worked for numerous companies that didn’t > have outages of the mainframe for years. Health insurance companies can get > huge fines if their systems are unavailable. I also looked on LinkedIn and > there are resumes there that claim they managed systems to 99.999 > availability. Google it. It’s promised and delivered quite often. In fact > 99.999 isn’t all that amazing any longer. > > So your claim is, if my phone dies and I can’t get to my JP Morgan accounts, > then JP Morgan doesn’t have 99.999 uptime? There is nothing more tedious than a straw man argument. It’s a good indication that somebody is trying to argue a lost cause. > No wonder they aren’t buying your crappy software. Actually, they do run our software. Almost every mainframe site runs our software. Most of them think it’s IBM software as it’s badged IBM. > > > Sent from Yahoo Mail for iPhone > > > On Monday, August 28, 2023, 7:47 PM, David Crayford > wrote: > >> On 29 Aug 2023, at 7:41 am, Bill Johnson >> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: >> >> You’re ASSuming Zelle is on the mainframe. > > Why does it matter where it’s running. Banking applications are only as > reliable as their weakest link. > >> Multiple 9’s is a fact and many companies are running it. > > Prove it. Provide a link to a bank offering a 99.999% SLA on their banking > services. > >> You’re an idiot. More truth. Looks like you threaten people on the internet >> too. > > > >> >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, August 28, 2023, 7:27 PM, David Crayford >> wrote: >> >> On 28/8/2023 10:21 pm, Bill Johnson wrote: >>> LOL, there’s Crayfish making stupid comments again. The difference between >>> me and Perryman is I tell the truth. IBM does offer multiple 9’s uptime. >>> And numerous banks have the setup necessary. >> >>> JP Morgan (a REAL bank) spends BILLIONS per year on IT. >> >> Yes. And they still have outages >> >> https://piunikaweb.com/2023/08/24/chase-bank-app-website-down-servers-not-working-online-and-mobile-banking-suffers/ >> https://www.americanbanker.com/news/zelle-outage-at-jpmorgan-chase-is-red-flag-for-banks >> https://piunikaweb.com/2023/08/25/wells-fargo-website-and-app-down-not-working-online-banking-suffers/ >> >> As banks rush to modernize their services the applications have become >> far more compex. Especially integrating new technologies into legacy >> systems. More points of failure. 99.999% service availability is a myth. >> >> >> >>> >>> Sent from Yahoo Mail for iPhone >>> >>> >>> On Monday, August 28, 2023, 7:15 AM, David Crayford >>> wrote: >>> >>> On 27/8/2023 11:05 am, Tom Brennan wrote: A bigger problem is Jon says things like this with such conviction and authority that other people reading these posts, perhaps years from now, will think they are true. >>> Don't engage with him! There's no point in debating with a troll. >>> >>> Lately, he's been banging on about the 99.99% availability on the >>> z16. It's clear he's either deeply ignorant or gullible. In any case, it >>> seems he missed the fine print: >>> https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's willing to spend tens >>> of millions of dollars to run a small Linux rack?) >>> >>> "DISCLAIMER: IBM internal data based on measurements and projections was >>> used in calculating the expected value. Necessary components include IBM >>> z16; IBM z/VM V7.2 systems collected in a Single System Image, each >>> running RHOCP 4.10 or above; >>> IBM Operations Manager; GDPS 4.5 for management of data recovery and >>> virtual machine recovery across metro distance systems and storage, >>> including Metro Multi-site workload and GDPS Global; and IBM DS8000 >>> series storage with IBM HyperSwap. A >>> MongoDB v4.2 workload was used. Necessary resiliency technology must be >>> enabled, including z/VM Single System Image clustering, GDPS xDR Proxy >>> for z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management >>> of local storage devices. >>> Application-induced outages are not included in the above measurements. >>> Other configurations (hardware or software) may provide different >>> availability characteristics." >>> >>> Could it be that Jon Perryman is actually Bill Johnson in disguise, >>> using ChatGPT to compose his posts? Does he have a Linkedin profile >>> where we can read he's credentials? >>> On 8/26/2023 7:31 PM, David Spiegel wrote: > Hi Jon, > You said: "...The M in SMP/e stands for Maintenance ..." > This statement has NEVER been true. > The M is an abbreviation of Modification and it has ALWAYS been this > way. > > Regards, > David > -
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Simple Google search turned up this company who promises 99.999. LOL https://www.serviceobjects.com/blog/weve-raised-the-bar-99-999-uptime-guarantee/ Sent from Yahoo Mail for iPhone On Monday, August 28, 2023, 7:47 PM, David Crayford wrote: > On 29 Aug 2023, at 7:41 am, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > You’re ASSuming Zelle is on the mainframe. Why does it matter where it’s running. Banking applications are only as reliable as their weakest link. > Multiple 9’s is a fact and many companies are running it. Prove it. Provide a link to a bank offering a 99.999% SLA on their banking services. > You’re an idiot. More truth. Looks like you threaten people on the internet > too. > > > Sent from Yahoo Mail for iPhone > > > On Monday, August 28, 2023, 7:27 PM, David Crayford > wrote: > > On 28/8/2023 10:21 pm, Bill Johnson wrote: >> LOL, there’s Crayfish making stupid comments again. The difference between >> me and Perryman is I tell the truth. IBM does offer multiple 9’s uptime. And >> numerous banks have the setup necessary. > >> JP Morgan (a REAL bank) spends BILLIONS per year on IT. > > Yes. And they still have outages > > https://piunikaweb.com/2023/08/24/chase-bank-app-website-down-servers-not-working-online-and-mobile-banking-suffers/ > https://www.americanbanker.com/news/zelle-outage-at-jpmorgan-chase-is-red-flag-for-banks > https://piunikaweb.com/2023/08/25/wells-fargo-website-and-app-down-not-working-online-banking-suffers/ > > As banks rush to modernize their services the applications have become > far more compex. Especially integrating new technologies into legacy > systems. More points of failure. 99.999% service availability is a myth. > > > >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, August 28, 2023, 7:15 AM, David Crayford >> wrote: >> >> On 27/8/2023 11:05 am, Tom Brennan wrote: >>> A bigger problem is Jon says things like this with such conviction and >>> authority that other people reading these posts, perhaps years from >>> now, will think they are true. >> Don't engage with him! There's no point in debating with a troll. >> >> Lately, he's been banging on about the 99.99% availability on the >> z16. It's clear he's either deeply ignorant or gullible. In any case, it >> seems he missed the fine print: >> https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's willing to spend tens >> of millions of dollars to run a small Linux rack?) >> >> "DISCLAIMER: IBM internal data based on measurements and projections was >> used in calculating the expected value. Necessary components include IBM >> z16; IBM z/VM V7.2 systems collected in a Single System Image, each >> running RHOCP 4.10 or above; >> IBM Operations Manager; GDPS 4.5 for management of data recovery and >> virtual machine recovery across metro distance systems and storage, >> including Metro Multi-site workload and GDPS Global; and IBM DS8000 >> series storage with IBM HyperSwap. A >> MongoDB v4.2 workload was used. Necessary resiliency technology must be >> enabled, including z/VM Single System Image clustering, GDPS xDR Proxy >> for z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management >> of local storage devices. >> Application-induced outages are not included in the above measurements. >> Other configurations (hardware or software) may provide different >> availability characteristics." >> >> Could it be that Jon Perryman is actually Bill Johnson in disguise, >> using ChatGPT to compose his posts? Does he have a Linkedin profile >> where we can read he's credentials? >> >>> On 8/26/2023 7:31 PM, David Spiegel wrote: Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David >>> -- >>> 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 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 > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: I
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
You’re the weakest link here. How can IBM guarantee 99.999 uptime for systems they don’t make or support? I’ve worked for numerous companies that didn’t have outages of the mainframe for years. Health insurance companies can get huge fines if their systems are unavailable. I also looked on LinkedIn and there are resumes there that claim they managed systems to 99.999 availability. Google it. It’s promised and delivered quite often. In fact 99.999 isn’t all that amazing any longer. So your claim is, if my phone dies and I can’t get to my JP Morgan accounts, then JP Morgan doesn’t have 99.999 uptime? No wonder they aren’t buying your crappy software. Sent from Yahoo Mail for iPhone On Monday, August 28, 2023, 7:47 PM, David Crayford wrote: > On 29 Aug 2023, at 7:41 am, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > You’re ASSuming Zelle is on the mainframe. Why does it matter where it’s running. Banking applications are only as reliable as their weakest link. > Multiple 9’s is a fact and many companies are running it. Prove it. Provide a link to a bank offering a 99.999% SLA on their banking services. > You’re an idiot. More truth. Looks like you threaten people on the internet > too. > > > Sent from Yahoo Mail for iPhone > > > On Monday, August 28, 2023, 7:27 PM, David Crayford > wrote: > > On 28/8/2023 10:21 pm, Bill Johnson wrote: >> LOL, there’s Crayfish making stupid comments again. The difference between >> me and Perryman is I tell the truth. IBM does offer multiple 9’s uptime. And >> numerous banks have the setup necessary. > >> JP Morgan (a REAL bank) spends BILLIONS per year on IT. > > Yes. And they still have outages > > https://piunikaweb.com/2023/08/24/chase-bank-app-website-down-servers-not-working-online-and-mobile-banking-suffers/ > https://www.americanbanker.com/news/zelle-outage-at-jpmorgan-chase-is-red-flag-for-banks > https://piunikaweb.com/2023/08/25/wells-fargo-website-and-app-down-not-working-online-banking-suffers/ > > As banks rush to modernize their services the applications have become > far more compex. Especially integrating new technologies into legacy > systems. More points of failure. 99.999% service availability is a myth. > > > >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, August 28, 2023, 7:15 AM, David Crayford >> wrote: >> >> On 27/8/2023 11:05 am, Tom Brennan wrote: >>> A bigger problem is Jon says things like this with such conviction and >>> authority that other people reading these posts, perhaps years from >>> now, will think they are true. >> Don't engage with him! There's no point in debating with a troll. >> >> Lately, he's been banging on about the 99.99% availability on the >> z16. It's clear he's either deeply ignorant or gullible. In any case, it >> seems he missed the fine print: >> https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's willing to spend tens >> of millions of dollars to run a small Linux rack?) >> >> "DISCLAIMER: IBM internal data based on measurements and projections was >> used in calculating the expected value. Necessary components include IBM >> z16; IBM z/VM V7.2 systems collected in a Single System Image, each >> running RHOCP 4.10 or above; >> IBM Operations Manager; GDPS 4.5 for management of data recovery and >> virtual machine recovery across metro distance systems and storage, >> including Metro Multi-site workload and GDPS Global; and IBM DS8000 >> series storage with IBM HyperSwap. A >> MongoDB v4.2 workload was used. Necessary resiliency technology must be >> enabled, including z/VM Single System Image clustering, GDPS xDR Proxy >> for z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management >> of local storage devices. >> Application-induced outages are not included in the above measurements. >> Other configurations (hardware or software) may provide different >> availability characteristics." >> >> Could it be that Jon Perryman is actually Bill Johnson in disguise, >> using ChatGPT to compose his posts? Does he have a Linkedin profile >> where we can read he's credentials? >> >>> On 8/26/2023 7:31 PM, David Spiegel wrote: Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David >>> -- >>> 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 i
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
> On 29 Aug 2023, at 7:41 am, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > You’re ASSuming Zelle is on the mainframe. Why does it matter where it’s running. Banking applications are only as reliable as their weakest link. > Multiple 9’s is a fact and many companies are running it. Prove it. Provide a link to a bank offering a 99.999% SLA on their banking services. > You’re an idiot. More truth. Looks like you threaten people on the internet > too. > > > Sent from Yahoo Mail for iPhone > > > On Monday, August 28, 2023, 7:27 PM, David Crayford > wrote: > > On 28/8/2023 10:21 pm, Bill Johnson wrote: >> LOL, there’s Crayfish making stupid comments again. The difference between >> me and Perryman is I tell the truth. IBM does offer multiple 9’s uptime. And >> numerous banks have the setup necessary. > >> JP Morgan (a REAL bank) spends BILLIONS per year on IT. > > Yes. And they still have outages > > https://piunikaweb.com/2023/08/24/chase-bank-app-website-down-servers-not-working-online-and-mobile-banking-suffers/ > https://www.americanbanker.com/news/zelle-outage-at-jpmorgan-chase-is-red-flag-for-banks > https://piunikaweb.com/2023/08/25/wells-fargo-website-and-app-down-not-working-online-banking-suffers/ > > As banks rush to modernize their services the applications have become > far more compex. Especially integrating new technologies into legacy > systems. More points of failure. 99.999% service availability is a myth. > > > >> >> Sent from Yahoo Mail for iPhone >> >> >> On Monday, August 28, 2023, 7:15 AM, David Crayford >> wrote: >> >> On 27/8/2023 11:05 am, Tom Brennan wrote: >>> A bigger problem is Jon says things like this with such conviction and >>> authority that other people reading these posts, perhaps years from >>> now, will think they are true. >> Don't engage with him! There's no point in debating with a troll. >> >> Lately, he's been banging on about the 99.99% availability on the >> z16. It's clear he's either deeply ignorant or gullible. In any case, it >> seems he missed the fine print: >> https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's willing to spend tens >> of millions of dollars to run a small Linux rack?) >> >> "DISCLAIMER: IBM internal data based on measurements and projections was >> used in calculating the expected value. Necessary components include IBM >> z16; IBM z/VM V7.2 systems collected in a Single System Image, each >> running RHOCP 4.10 or above; >> IBM Operations Manager; GDPS 4.5 for management of data recovery and >> virtual machine recovery across metro distance systems and storage, >> including Metro Multi-site workload and GDPS Global; and IBM DS8000 >> series storage with IBM HyperSwap. A >> MongoDB v4.2 workload was used. Necessary resiliency technology must be >> enabled, including z/VM Single System Image clustering, GDPS xDR Proxy >> for z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management >> of local storage devices. >> Application-induced outages are not included in the above measurements. >> Other configurations (hardware or software) may provide different >> availability characteristics." >> >> Could it be that Jon Perryman is actually Bill Johnson in disguise, >> using ChatGPT to compose his posts? Does he have a Linkedin profile >> where we can read he's credentials? >> >>> On 8/26/2023 7:31 PM, David Spiegel wrote: Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David >>> -- >>> 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 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 > > > > > -- > 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
You’re ASSuming Zelle is on the mainframe. Multiple 9’s is a fact and many companies are running it. You’re an idiot. More truth. Looks like you threaten people on the internet too. Sent from Yahoo Mail for iPhone On Monday, August 28, 2023, 7:27 PM, David Crayford wrote: On 28/8/2023 10:21 pm, Bill Johnson wrote: > LOL, there’s Crayfish making stupid comments again. The difference between me > and Perryman is I tell the truth. IBM does offer multiple 9’s uptime. And > numerous banks have the setup necessary. > JP Morgan (a REAL bank) spends BILLIONS per year on IT. Yes. And they still have outages https://piunikaweb.com/2023/08/24/chase-bank-app-website-down-servers-not-working-online-and-mobile-banking-suffers/ https://www.americanbanker.com/news/zelle-outage-at-jpmorgan-chase-is-red-flag-for-banks https://piunikaweb.com/2023/08/25/wells-fargo-website-and-app-down-not-working-online-banking-suffers/ As banks rush to modernize their services the applications have become far more compex. Especially integrating new technologies into legacy systems. More points of failure. 99.999% service availability is a myth. > > Sent from Yahoo Mail for iPhone > > > On Monday, August 28, 2023, 7:15 AM, David Crayford > wrote: > > On 27/8/2023 11:05 am, Tom Brennan wrote: >> A bigger problem is Jon says things like this with such conviction and >> authority that other people reading these posts, perhaps years from >> now, will think they are true. > Don't engage with him! There's no point in debating with a troll. > > Lately, he's been banging on about the 99.99% availability on the > z16. It's clear he's either deeply ignorant or gullible. In any case, it > seems he missed the fine print: > https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's willing to spend tens > of millions of dollars to run a small Linux rack?) > > "DISCLAIMER: IBM internal data based on measurements and projections was > used in calculating the expected value. Necessary components include IBM > z16; IBM z/VM V7.2 systems collected in a Single System Image, each > running RHOCP 4.10 or above; > IBM Operations Manager; GDPS 4.5 for management of data recovery and > virtual machine recovery across metro distance systems and storage, > including Metro Multi-site workload and GDPS Global; and IBM DS8000 > series storage with IBM HyperSwap. A > MongoDB v4.2 workload was used. Necessary resiliency technology must be > enabled, including z/VM Single System Image clustering, GDPS xDR Proxy > for z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management > of local storage devices. > Application-induced outages are not included in the above measurements. > Other configurations (hardware or software) may provide different > availability characteristics." > > Could it be that Jon Perryman is actually Bill Johnson in disguise, > using ChatGPT to compose his posts? Does he have a Linkedin profile > where we can read he's credentials? > >> On 8/26/2023 7:31 PM, David Spiegel wrote: >>> Hi Jon, >>> You said: "...The M in SMP/e stands for Maintenance ..." >>> This statement has NEVER been true. >>> The M is an abbreviation of Modification and it has ALWAYS been this >>> way. >>> >>> Regards, >>> David >>> >> -- >> 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 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
On 28/8/2023 10:21 pm, Bill Johnson wrote: LOL, there’s Crayfish making stupid comments again. The difference between me and Perryman is I tell the truth. IBM does offer multiple 9’s uptime. And numerous banks have the setup necessary. JP Morgan (a REAL bank) spends BILLIONS per year on IT. Yes. And they still have outages https://piunikaweb.com/2023/08/24/chase-bank-app-website-down-servers-not-working-online-and-mobile-banking-suffers/ https://www.americanbanker.com/news/zelle-outage-at-jpmorgan-chase-is-red-flag-for-banks https://piunikaweb.com/2023/08/25/wells-fargo-website-and-app-down-not-working-online-banking-suffers/ As banks rush to modernize their services the applications have become far more compex. Especially integrating new technologies into legacy systems. More points of failure. 99.999% service availability is a myth. Sent from Yahoo Mail for iPhone On Monday, August 28, 2023, 7:15 AM, David Crayford wrote: On 27/8/2023 11:05 am, Tom Brennan wrote: A bigger problem is Jon says things like this with such conviction and authority that other people reading these posts, perhaps years from now, will think they are true. Don't engage with him! There's no point in debating with a troll. Lately, he's been banging on about the 99.99% availability on the z16. It's clear he's either deeply ignorant or gullible. In any case, it seems he missed the fine print: https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's willing to spend tens of millions of dollars to run a small Linux rack?) "DISCLAIMER: IBM internal data based on measurements and projections was used in calculating the expected value. Necessary components include IBM z16; IBM z/VM V7.2 systems collected in a Single System Image, each running RHOCP 4.10 or above; IBM Operations Manager; GDPS 4.5 for management of data recovery and virtual machine recovery across metro distance systems and storage, including Metro Multi-site workload and GDPS Global; and IBM DS8000 series storage with IBM HyperSwap. A MongoDB v4.2 workload was used. Necessary resiliency technology must be enabled, including z/VM Single System Image clustering, GDPS xDR Proxy for z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management of local storage devices. Application-induced outages are not included in the above measurements. Other configurations (hardware or software) may provide different availability characteristics." Could it be that Jon Perryman is actually Bill Johnson in disguise, using ChatGPT to compose his posts? Does he have a Linkedin profile where we can read he's credentials? On 8/26/2023 7:31 PM, David Spiegel wrote: Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David -- 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 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
What do you think inspired this verse: Those folks at Sterling Forrest I envy not one bit, For every single PUT cycle they're certain to get hit; There' a way they could help themselves and fill my heart with glee: Take the damn JES2 change team and teach it SMP! Mañana, mañana, mañana is soon enough for me. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jay Maynard [jaymayn...@gmail.com] Sent: Monday, August 28, 2023 9:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?] Am I the only one who remembers JES2 level sets? On Mon, Aug 28, 2023 at 8:30 AM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
My credentials are impeccable. And I don’t embellish mine like most LinkedIn accounts. Google it, fraudulent resumes are a big problem on LinkedIn. I’ve had no problem getting jobs over my 40+ years in IT. Sent from Yahoo Mail for iPhone On Monday, August 28, 2023, 10:13 AM, David Crayford wrote: > On 28 Aug 2023, at 9:22 pm, David Spiegel > <0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > > Hi David, > You said: "... he's been banging on ..." > This reminds me of a Yiddish expression that fits with this theme (and is > said to the "bang"er): Hack Mir Nisht Kain Chainik! > (In English, Don't bang the tea kettle for me! (i.e. stop blathering)) That's actually pretty interesting, and I hadn't really thought about it before. I grew up in North West London, an area with a big Yiddish community spread across places like Saint John’s Wood, Hampstead, and especially Golders Green and Stamford Hill. When we were kids, we'd often take the 32 bus to the Bagel Bar in Hendon for some delicious salt beef and mustard bagels. The London slang we use, like Cockney, has been shaped by Yiddish over the years. I've got loads of Jewish friends from back in the day, so maybe I picked up the expression from them? > On 2023-08-28 07:15, David Crayford wrote: >> On 27/8/2023 11:05 am, Tom Brennan wrote: >>> A bigger problem is Jon says things like this with such conviction and >>> authority that other people reading these posts, perhaps years from now, >>> will think they are true. >> >> Don't engage with him! There's no point in debating with a troll. >> >> Lately, he's been banging on about the 99.99% availability on the z16. >> It's clear he's either deeply ignorant or gullible. In any case, it seems he >> missed the fine print: https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's >> willing to spend tens of millions of dollars to run a small Linux rack?) >> >> "DISCLAIMER: IBM internal data based on measurements and projections was >> used in calculating the expected value. Necessary components include IBM >> z16; IBM z/VM V7.2 systems collected in a Single System Image, each running >> RHOCP 4.10 or above; >> IBM Operations Manager; GDPS 4.5 for management of data recovery and virtual >> machine recovery across metro distance systems and storage, including Metro >> Multi-site workload and GDPS Global; and IBM DS8000 series storage with IBM >> HyperSwap. A >> MongoDB v4.2 workload was used. Necessary resiliency technology must be >> enabled, including z/VM Single System Image clustering, GDPS xDR Proxy for >> z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management of >> local storage devices. >> Application-induced outages are not included in the above measurements. >> Other configurations (hardware or software) may provide different >> availability characteristics." >> >> Could it be that Jon Perryman is actually Bill Johnson in disguise, using >> ChatGPT to compose his posts? Does he have a Linkedin profile where we can >> read he's credentials? >> >>> >>> On 8/26/2023 7:31 PM, David Spiegel wrote: Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Maybe I’m Jerzy! What’s this about Dave? “As with many other people who have been warned in the past, you will find yourself constantly looking over your shoulders for an undefined period of time. That is a promise, not a threat.” Regards, David P. Crayford Sent from Yahoo Mail for iPhone On Monday, August 28, 2023, 10:13 AM, David Crayford wrote: > On 28 Aug 2023, at 9:22 pm, David Spiegel > <0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > > Hi David, > You said: "... he's been banging on ..." > This reminds me of a Yiddish expression that fits with this theme (and is > said to the "bang"er): Hack Mir Nisht Kain Chainik! > (In English, Don't bang the tea kettle for me! (i.e. stop blathering)) That's actually pretty interesting, and I hadn't really thought about it before. I grew up in North West London, an area with a big Yiddish community spread across places like Saint John’s Wood, Hampstead, and especially Golders Green and Stamford Hill. When we were kids, we'd often take the 32 bus to the Bagel Bar in Hendon for some delicious salt beef and mustard bagels. The London slang we use, like Cockney, has been shaped by Yiddish over the years. I've got loads of Jewish friends from back in the day, so maybe I picked up the expression from them? > On 2023-08-28 07:15, David Crayford wrote: >> On 27/8/2023 11:05 am, Tom Brennan wrote: >>> A bigger problem is Jon says things like this with such conviction and >>> authority that other people reading these posts, perhaps years from now, >>> will think they are true. >> >> Don't engage with him! There's no point in debating with a troll. >> >> Lately, he's been banging on about the 99.99% availability on the z16. >> It's clear he's either deeply ignorant or gullible. In any case, it seems he >> missed the fine print: https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's >> willing to spend tens of millions of dollars to run a small Linux rack?) >> >> "DISCLAIMER: IBM internal data based on measurements and projections was >> used in calculating the expected value. Necessary components include IBM >> z16; IBM z/VM V7.2 systems collected in a Single System Image, each running >> RHOCP 4.10 or above; >> IBM Operations Manager; GDPS 4.5 for management of data recovery and virtual >> machine recovery across metro distance systems and storage, including Metro >> Multi-site workload and GDPS Global; and IBM DS8000 series storage with IBM >> HyperSwap. A >> MongoDB v4.2 workload was used. Necessary resiliency technology must be >> enabled, including z/VM Single System Image clustering, GDPS xDR Proxy for >> z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management of >> local storage devices. >> Application-induced outages are not included in the above measurements. >> Other configurations (hardware or software) may provide different >> availability characteristics." >> >> Could it be that Jon Perryman is actually Bill Johnson in disguise, using >> ChatGPT to compose his posts? Does he have a Linkedin profile where we can >> read he's credentials? >> >>> >>> On 8/26/2023 7:31 PM, David Spiegel wrote: Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
> On 28 Aug 2023, at 10:21 pm, Bill Johnson > <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > And numerous banks have the setup necessary. JP Morgan (a REAL bank) spends > BILLIONS per year on IT. I hope so. They’re doing a PoC for one of our products at the moment. But they think it’s too expensive :( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
LOL, there’s Crayfish making stupid comments again. The difference between me and Perryman is I tell the truth. IBM does offer multiple 9’s uptime. And numerous banks have the setup necessary. JP Morgan (a REAL bank) spends BILLIONS per year on IT. Sent from Yahoo Mail for iPhone On Monday, August 28, 2023, 7:15 AM, David Crayford wrote: On 27/8/2023 11:05 am, Tom Brennan wrote: > A bigger problem is Jon says things like this with such conviction and > authority that other people reading these posts, perhaps years from > now, will think they are true. Don't engage with him! There's no point in debating with a troll. Lately, he's been banging on about the 99.99% availability on the z16. It's clear he's either deeply ignorant or gullible. In any case, it seems he missed the fine print: https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's willing to spend tens of millions of dollars to run a small Linux rack?) "DISCLAIMER: IBM internal data based on measurements and projections was used in calculating the expected value. Necessary components include IBM z16; IBM z/VM V7.2 systems collected in a Single System Image, each running RHOCP 4.10 or above; IBM Operations Manager; GDPS 4.5 for management of data recovery and virtual machine recovery across metro distance systems and storage, including Metro Multi-site workload and GDPS Global; and IBM DS8000 series storage with IBM HyperSwap. A MongoDB v4.2 workload was used. Necessary resiliency technology must be enabled, including z/VM Single System Image clustering, GDPS xDR Proxy for z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management of local storage devices. Application-induced outages are not included in the above measurements. Other configurations (hardware or software) may provide different availability characteristics." Could it be that Jon Perryman is actually Bill Johnson in disguise, using ChatGPT to compose his posts? Does he have a Linkedin profile where we can read he's credentials? > > On 8/26/2023 7:31 PM, David Spiegel wrote: >> Hi Jon, >> You said: "...The M in SMP/e stands for Maintenance ..." >> This statement has NEVER been true. >> The M is an abbreviation of Modification and it has ALWAYS been this >> way. >> >> Regards, >> David >> > > -- > 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
> On 28 Aug 2023, at 9:22 pm, David Spiegel > <0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > > Hi David, > You said: "... he's been banging on ..." > This reminds me of a Yiddish expression that fits with this theme (and is > said to the "bang"er): Hack Mir Nisht Kain Chainik! > (In English, Don't bang the tea kettle for me! (i.e. stop blathering)) That's actually pretty interesting, and I hadn't really thought about it before. I grew up in North West London, an area with a big Yiddish community spread across places like Saint John’s Wood, Hampstead, and especially Golders Green and Stamford Hill. When we were kids, we'd often take the 32 bus to the Bagel Bar in Hendon for some delicious salt beef and mustard bagels. The London slang we use, like Cockney, has been shaped by Yiddish over the years. I've got loads of Jewish friends from back in the day, so maybe I picked up the expression from them? > On 2023-08-28 07:15, David Crayford wrote: >> On 27/8/2023 11:05 am, Tom Brennan wrote: >>> A bigger problem is Jon says things like this with such conviction and >>> authority that other people reading these posts, perhaps years from now, >>> will think they are true. >> >> Don't engage with him! There's no point in debating with a troll. >> >> Lately, he's been banging on about the 99.99% availability on the z16. >> It's clear he's either deeply ignorant or gullible. In any case, it seems he >> missed the fine print: https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's >> willing to spend tens of millions of dollars to run a small Linux rack?) >> >> "DISCLAIMER: IBM internal data based on measurements and projections was >> used in calculating the expected value. Necessary components include IBM >> z16; IBM z/VM V7.2 systems collected in a Single System Image, each running >> RHOCP 4.10 or above; >> IBM Operations Manager; GDPS 4.5 for management of data recovery and virtual >> machine recovery across metro distance systems and storage, including Metro >> Multi-site workload and GDPS Global; and IBM DS8000 series storage with IBM >> HyperSwap. A >> MongoDB v4.2 workload was used. Necessary resiliency technology must be >> enabled, including z/VM Single System Image clustering, GDPS xDR Proxy for >> z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management of >> local storage devices. >> Application-induced outages are not included in the above measurements. >> Other configurations (hardware or software) may provide different >> availability characteristics." >> >> Could it be that Jon Perryman is actually Bill Johnson in disguise, using >> ChatGPT to compose his posts? Does he have a Linkedin profile where we can >> read he's credentials? >> >>> >>> On 8/26/2023 7:31 PM, David Spiegel wrote: Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
We affectionately knew them as "JES2 maintenance: My crash course in IEBUPDTE." Bill Hitefield > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jay Maynard > Sent: Monday, August 28, 2023 9:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?] > > Am I the only one who remembers JES2 level sets? > > On Mon, Aug 28, 2023 at 8:30 AM Allan Staller < 0387911dea17-dmarc- > requ...@listserv.ua.edu> wrote: > > > Classification: Confidential > > > > "You never see a PTF that is 1MB" > > > > JAVA SDK's ? > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Jon Perryman > > Sent: Friday, August 25, 2023 8:56 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: RPMs for installs and Maint: [WAS SMP/E needed for > > installs?] > > > > [CAUTION: This Email is from outside the Organization. Unless you > > trust the sender, Don’t click links or open attachments as it may be a > > Phishing email, which can steal your Information and compromise your > > Computer.] > > > > > On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson < > > ste...@wkyr.net> wrote: > > > With Linux distros there are a few maint systems. The one I am most > > > familiar with is RPM. > > > > Linux (nor Unix) does NOT have any maint systems. P in RPM stands for > > Package which is the z/OS equivalent of product / component. Complete > > packages are replaced regardless of the problems you want to fix. > > Every package has a version number which is indentifies all the > > maintenance included in that package. > > > > > To me YAST (the Linux equivalent of SMP/E) handles upgrades > > > > YAST and SMP/e have nothing in common. YAST tells you it's about > > installation and configuration. It's about replacing the entire > > package and nothing to do with maintaining that package. The M in > > SMP/e stands for Maintenance. You never see a PTF that is 1MB. The > > only reason SMP/e installs, is to create a maintenance environment for > > the product / component. If installation is your only requirement, > > then use a different tool like IEBCOPY, DFDSS or ???. > > > > > Each product/component has its own main entry and dependencies. > > > > Unix dependencies are by version number and have nothing to do with > > the package (product/component) in question. The package is completely > > replaced. SMP/e dependencies can be for entities within the same > > function, other functions, PTFs and APARs. A function is the SMP/e > > equivalent of a Unix package. > > > > > I thought it was a fairly good replacement for SMP/E for the Linux > > > side of things. > > > I can see how it could be used to do z/OS and related. > > > > YAST, RPM and other Unix package installers are unacceptable > > replacements for SMP/e. Name 1 z/OS customer that is willing to risk > > reinstalling an entire product/component because they need 1 PTF. Add > > to that cascading product installs because of dependencies. Worse than > > that, testing must include everything that changed in those installs > > and every product/component that interacts with all the installed > products/components. > > > > I think z/OS uptime is 99.%. You get what you pay for. Unix maint > > philosophy may be acceptable on $10,000 computers but highly > > unacceptable on multi-million $ computers. We don't tolerate unintentional > downtime. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ::DISCLAIMER:: > > > > The contents of this e-mail and any attachment(s) are confidential and > > intended for the named recipient(s) only. E-mail transmission is not > > guaranteed to be secure or error-free as information could be > > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or > > may contain viruses in transmission. The e mail and its contents (with > > or without referred errors) shall therefore not attach any liability > > on the originator or HCL or its affiliates. Views or opinions, if any, > > presented in this email are solely those of the author and may not > > necessarily reflect the views or opinions of HCL or its affiliates. > > Any form o
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Am I the only one who remembers JES2 level sets? On Mon, Aug 28, 2023 at 8:30 AM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > "You never see a PTF that is 1MB" > > JAVA SDK's ? > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Jon Perryman > Sent: Friday, August 25, 2023 8:56 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?] > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > > On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson < > ste...@wkyr.net> wrote: > > With Linux distros there are a few maint systems. The one I am most > > familiar with is RPM. > > Linux (nor Unix) does NOT have any maint systems. P in RPM stands for > Package which is the z/OS equivalent of product / component. Complete > packages are replaced regardless of the problems you want to fix. Every > package has a version number which is indentifies all the maintenance > included in that package. > > > To me YAST (the Linux equivalent of SMP/E) handles upgrades > > YAST and SMP/e have nothing in common. YAST tells you it's about > installation and configuration. It's about replacing the entire package and > nothing to do with maintaining that package. The M in SMP/e stands for > Maintenance. You never see a PTF that is 1MB. The only reason SMP/e > installs, is to create a maintenance environment for the product / > component. If installation is your only requirement, then use a different > tool like IEBCOPY, DFDSS or ???. > > > Each product/component has its own main entry and dependencies. > > Unix dependencies are by version number and have nothing to do with the > package (product/component) in question. The package is completely > replaced. SMP/e dependencies can be for entities within the same function, > other functions, PTFs and APARs. A function is the SMP/e equivalent of a > Unix package. > > > I thought it was a fairly good replacement for SMP/E for the Linux > > side of things. > > I can see how it could be used to do z/OS and related. > > YAST, RPM and other Unix package installers are unacceptable replacements > for SMP/e. Name 1 z/OS customer that is willing to risk reinstalling an > entire product/component because they need 1 PTF. Add to that cascading > product installs because of dependencies. Worse than that, testing must > include everything that changed in those installs and every > product/component that interacts with all the installed products/components. > > I think z/OS uptime is 99.%. You get what you pay for. Unix maint > philosophy may be acceptable on $10,000 computers but highly unacceptable > on multi-million $ computers. We don't tolerate unintentional downtime. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this > email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, distribution and / or > publication of this message without the prior written consent of authorized > representative of HCL is strictly prohibited. If you have received this > email in error please delete it and notify the sender immediately. Before > opening any email and/or attachments, please check them for viruses and > other defects. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Classification: Confidential "You never see a PTF that is 1MB" JAVA SDK's ? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Friday, August 25, 2023 8:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?] [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] > On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson > wrote: > With Linux distros there are a few maint systems. The one I am most > familiar with is RPM. Linux (nor Unix) does NOT have any maint systems. P in RPM stands for Package which is the z/OS equivalent of product / component. Complete packages are replaced regardless of the problems you want to fix. Every package has a version number which is indentifies all the maintenance included in that package. > To me YAST (the Linux equivalent of SMP/E) handles upgrades YAST and SMP/e have nothing in common. YAST tells you it's about installation and configuration. It's about replacing the entire package and nothing to do with maintaining that package. The M in SMP/e stands for Maintenance. You never see a PTF that is 1MB. The only reason SMP/e installs, is to create a maintenance environment for the product / component. If installation is your only requirement, then use a different tool like IEBCOPY, DFDSS or ???. > Each product/component has its own main entry and dependencies. Unix dependencies are by version number and have nothing to do with the package (product/component) in question. The package is completely replaced. SMP/e dependencies can be for entities within the same function, other functions, PTFs and APARs. A function is the SMP/e equivalent of a Unix package. > I thought it was a fairly good replacement for SMP/E for the Linux > side of things. > I can see how it could be used to do z/OS and related. YAST, RPM and other Unix package installers are unacceptable replacements for SMP/e. Name 1 z/OS customer that is willing to risk reinstalling an entire product/component because they need 1 PTF. Add to that cascading product installs because of dependencies. Worse than that, testing must include everything that changed in those installs and every product/component that interacts with all the installed products/components. I think z/OS uptime is 99.%. You get what you pay for. Unix maint philosophy may be acceptable on $10,000 computers but highly unacceptable on multi-million $ computers. We don't tolerate unintentional downtime. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Hi David, You said: "... he's been banging on ..." This reminds me of a Yiddish expression that fits with this theme (and is said to the "bang"er): Hack Mir Nisht Kain Chainik! (In English, Don't bang the tea kettle for me! (i.e. stop blathering)) Regards, David On 2023-08-28 07:15, David Crayford wrote: On 27/8/2023 11:05 am, Tom Brennan wrote: A bigger problem is Jon says things like this with such conviction and authority that other people reading these posts, perhaps years from now, will think they are true. Don't engage with him! There's no point in debating with a troll. Lately, he's been banging on about the 99.99% availability on the z16. It's clear he's either deeply ignorant or gullible. In any case, it seems he missed the fine print: https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's willing to spend tens of millions of dollars to run a small Linux rack?) "DISCLAIMER: IBM internal data based on measurements and projections was used in calculating the expected value. Necessary components include IBM z16; IBM z/VM V7.2 systems collected in a Single System Image, each running RHOCP 4.10 or above; IBM Operations Manager; GDPS 4.5 for management of data recovery and virtual machine recovery across metro distance systems and storage, including Metro Multi-site workload and GDPS Global; and IBM DS8000 series storage with IBM HyperSwap. A MongoDB v4.2 workload was used. Necessary resiliency technology must be enabled, including z/VM Single System Image clustering, GDPS xDR Proxy for z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management of local storage devices. Application-induced outages are not included in the above measurements. Other configurations (hardware or software) may provide different availability characteristics." Could it be that Jon Perryman is actually Bill Johnson in disguise, using ChatGPT to compose his posts? Does he have a Linkedin profile where we can read he's credentials? On 8/26/2023 7:31 PM, David Spiegel wrote: Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David -- 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
On 27/8/2023 11:05 am, Tom Brennan wrote: A bigger problem is Jon says things like this with such conviction and authority that other people reading these posts, perhaps years from now, will think they are true. Don't engage with him! There's no point in debating with a troll. Lately, he's been banging on about the 99.99% availability on the z16. It's clear he's either deeply ignorant or gullible. In any case, it seems he missed the fine print: https://www.ibm.com/downloads/cas/0MZVKEYJ. (Who's willing to spend tens of millions of dollars to run a small Linux rack?) "DISCLAIMER: IBM internal data based on measurements and projections was used in calculating the expected value. Necessary components include IBM z16; IBM z/VM V7.2 systems collected in a Single System Image, each running RHOCP 4.10 or above; IBM Operations Manager; GDPS 4.5 for management of data recovery and virtual machine recovery across metro distance systems and storage, including Metro Multi-site workload and GDPS Global; and IBM DS8000 series storage with IBM HyperSwap. A MongoDB v4.2 workload was used. Necessary resiliency technology must be enabled, including z/VM Single System Image clustering, GDPS xDR Proxy for z/VM, and RedHat OpenShift Data Foundation (ODF) 4.10 for management of local storage devices. Application-induced outages are not included in the above measurements. Other configurations (hardware or software) may provide different availability characteristics." Could it be that Jon Perryman is actually Bill Johnson in disguise, using ChatGPT to compose his posts? Does he have a Linkedin profile where we can read he's credentials? On 8/26/2023 7:31 PM, David Spiegel wrote: Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David -- 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
It is common for documentation to be in a separate package from the code. SMP provided documentation normally has the same FMID as the code. If you want an equivalence with SMP rather than just parallel roles, then you really need to factor in, e.g, cvs, svn, git. From: IBM Mainframe Discussion List on behalf of Joel C. Ewing Sent: Saturday, August 26, 2023 12:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?] Tthere isn't really any direct equivalence between RPM and SMP/E concepts of maintenance. Since a large Linux application (like LibreOffice) may be packaged as several interdependent packages, in that sense a package is similar to an FMID of a z/OS product; but the number of pieces/files contained in a package tends to vary more widely than for z/OS products, in some cases containing very few files. I expect the average Linux package contains many fewer elements than the typical z/OS product, so replacing the whole thing is not that big of a deal. The Linux systems I have seen also have many more packages installed than the typical number of FMIDs on a z/OS system. It is true that a package update must replace an entire package, not just changed sub components of a package; but new release levels of a package also occur with much greater frequency than new versions or release levels of a z/OS product. A new release level of a package typically contains a number of code fixes, and in that respect is more like a z/OS PTF that fixes multiple APARS. While all components of an updated package are re-installed, it is also true that current RPM download protocols also support just downloading the RPM delta from the previous package level if only a small part of a large package RPM file has changed. You can back out a package update by re-installing a previous package level, just like you can back out a z/OS PTF that fixes multiple APARs -- the dependency requirements are simpler to resolve when there are only package-level dependencies to consider. The frequency of occurrence of new package releases with minor changes definitely entitles this to be called a maintenance process. That the same RPM file can be used for new installation or maintenance is a nice simplification from the user's standpoint. The decentralized nature of Linux package maintenance and the extremely large number of combinations of packages that could be present on a Linux system does tend to make Linux platforms less predictable. It is not so much a factor of the complete package replacement strategy (changes at the source code level may be minor), as that the maintainers of one package simply cannot test with all other package combinations and may be unaware of some package combinations that are adversely affected by their changes. Linux is more dependent upon their user community to find non-obvious dependency issues. Joel C Ewing On 8/25/23 20:55, Jon Perryman wrote: >> On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson >> wrote: >> With Linux distros there are a few maint systems. The one I am >> most familiar with is RPM. > Linux (nor Unix) does NOT have any maint systems. P in RPM stands for Package > which is the z/OS equivalent of product / component. Complete packages are > replaced regardless of the problems you want to fix. Every package has a > version number which is indentifies all the maintenance included in that > package. > >> To me YAST (the Linux equivalent of SMP/E) handles upgrades > YAST and SMP/e have nothing in common. YAST tells you it's about installation > and configuration. It's about replacing the entire package and nothing to do > with maintaining that package. The M in SMP/e stands for Maintenance. You > never see a PTF that is 1MB. The only reason SMP/e installs, is to create a > maintenance environment for the product / component. If installation is your > only requirement, then use a different tool like IEBCOPY, DFDSS or ???. > >> Each product/component has its own main entry and dependencies. > Unix dependencies are by version number and have nothing to do with the > package (product/component) in question. The package is completely replaced. > SMP/e dependencies can be for entities within the same function, other > functions, PTFs and APARs. A function is the SMP/e equivalent of a Unix > package. > >> I thought it was a fairly good replacement for SMP/E for the >> Linux side of things. >> I can see how it could be used to do z/OS and related. > YAST, RPM and other Unix package installers are unacceptable replacements for > SMP/e. Name 1 z/OS customer that is willing to risk reinstalling an entire > product/component because they need 1 PTF. Add to that cascading product > installs because of dependen
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
I don’t pay attention to anyone but Kurt Quackenbush when it comes to SMPe. He’s the expert. Sent from Yahoo Mail for iPhone On Sunday, August 27, 2023, 12:16 AM, Tom Brennan wrote: By themselves, probably few here would care. But you used M=Maintenance and the 1MB limit as part of your comparison of SMP/E vs. Linux install methods. That's when it becomes more of a problem. On 8/26/2023 8:39 PM, Jon Perryman wrote: > I grant you that M stands for Modification and that some PTF's are greatly > exceeding 1MB but do you consider these consequential. -- 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
By themselves, probably few here would care. But you used M=Maintenance and the 1MB limit as part of your comparison of SMP/E vs. Linux install methods. That's when it becomes more of a problem. On 8/26/2023 8:39 PM, Jon Perryman wrote: I grant you that M stands for Modification and that some PTF's are greatly exceeding 1MB but do you consider these consequential. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
> On Saturday, August 26, 2023 at 08:05:31 PM PDT, Tom Brennan > wrote: > A bigger problem is Jon says things like this with such conviction and > authority that other people reading these posts, perhaps years from now, > will think they are true. I grant you that M stands for Modification and that some PTF's are greatly exceeding 1MB but do you consider these consequential. Sorry for thinking maintenance when manuals say installation and maintenance but only use the acronym. As for PTF's far greater than 1MB, the physical size is actually inconsequential. More to the point is that very rately bundles more than 1 problem into a PTF unless things have changed. I haven't seen IBM PTF's in many years. Tell us what you disagree with that is of actual consequences. I doubt that years from now, people will bother looking at these postings. On Saturday, August 26, 2023 at 08:05:31 PM PDT, Tom Brennan wrote: A bigger problem is Jon says things like this with such conviction and authority that other people reading these posts, perhaps years from now, will think they are true. On 8/26/2023 7:31 PM, David Spiegel wrote: > Hi Jon, > You said: "...The M in SMP/e stands for Maintenance ..." > This statement has NEVER been true. > The M is an abbreviation of Modification and it has ALWAYS been this way. > > Regards, > David > -- 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
He has a future in politics. Sent from Yahoo Mail for iPhone On Saturday, August 26, 2023, 11:05 PM, Tom Brennan wrote: A bigger problem is Jon says things like this with such conviction and authority that other people reading these posts, perhaps years from now, will think they are true. On 8/26/2023 7:31 PM, David Spiegel wrote: > Hi Jon, > You said: "...The M in SMP/e stands for Maintenance ..." > This statement has NEVER been true. > The M is an abbreviation of Modification and it has ALWAYS been this way. > > Regards, > David > -- 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
A bigger problem is Jon says things like this with such conviction and authority that other people reading these posts, perhaps years from now, will think they are true. On 8/26/2023 7:31 PM, David Spiegel wrote: Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Hi Jon, Another misspeak ... You said: " ...You never see a PTF that is 1MB. ..." I've seen PTFs that are a lot bigger than 1 Mb. Regards, David On 2023-08-25 21:55, Jon Perryman wrote: On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson wrote: With Linux distros there are a few maint systems. The one I am most familiar with is RPM. Linux (nor Unix) does NOT have any maint systems. P in RPM stands for Package which is the z/OS equivalent of product / component. Complete packages are replaced regardless of the problems you want to fix. Every package has a version number which is indentifies all the maintenance included in that package. To me YAST (the Linux equivalent of SMP/E) handles upgrades YAST and SMP/e have nothing in common. YAST tells you it's about installation and configuration. It's about replacing the entire package and nothing to do with maintaining that package. The M in SMP/e stands for Maintenance. You never see a PTF that is 1MB. The only reason SMP/e installs, is to create a maintenance environment for the product / component. If installation is your only requirement, then use a different tool like IEBCOPY, DFDSS or ???. Each product/component has its own main entry and dependencies. Unix dependencies are by version number and have nothing to do with the package (product/component) in question. The package is completely replaced. SMP/e dependencies can be for entities within the same function, other functions, PTFs and APARs. A function is the SMP/e equivalent of a Unix package. I thought it was a fairly good replacement for SMP/E for the Linux side of things. I can see how it could be used to do z/OS and related. YAST, RPM and other Unix package installers are unacceptable replacements for SMP/e. Name 1 z/OS customer that is willing to risk reinstalling an entire product/component because they need 1 PTF. Add to that cascading product installs because of dependencies. Worse than that, testing must include everything that changed in those installs and every product/component that interacts with all the installed products/components. I think z/OS uptime is 99.%. You get what you pay for. Unix maint philosophy may be acceptable on $10,000 computers but highly unacceptable on multi-million $ computers. We don't tolerate unintentional downtime. -- 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David On 2023-08-25 21:55, Jon Perryman wrote: On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson wrote: With Linux distros there are a few maint systems. The one I am most familiar with is RPM. Linux (nor Unix) does NOT have any maint systems. P in RPM stands for Package which is the z/OS equivalent of product / component. Complete packages are replaced regardless of the problems you want to fix. Every package has a version number which is indentifies all the maintenance included in that package. To me YAST (the Linux equivalent of SMP/E) handles upgrades YAST and SMP/e have nothing in common. YAST tells you it's about installation and configuration. It's about replacing the entire package and nothing to do with maintaining that package. The M in SMP/e stands for Maintenance. You never see a PTF that is 1MB. The only reason SMP/e installs, is to create a maintenance environment for the product / component. If installation is your only requirement, then use a different tool like IEBCOPY, DFDSS or ???. Each product/component has its own main entry and dependencies. Unix dependencies are by version number and have nothing to do with the package (product/component) in question. The package is completely replaced. SMP/e dependencies can be for entities within the same function, other functions, PTFs and APARs. A function is the SMP/e equivalent of a Unix package. I thought it was a fairly good replacement for SMP/E for the Linux side of things. I can see how it could be used to do z/OS and related. YAST, RPM and other Unix package installers are unacceptable replacements for SMP/e. Name 1 z/OS customer that is willing to risk reinstalling an entire product/component because they need 1 PTF. Add to that cascading product installs because of dependencies. Worse than that, testing must include everything that changed in those installs and every product/component that interacts with all the installed products/components. I think z/OS uptime is 99.%. You get what you pay for. Unix maint philosophy may be acceptable on $10,000 computers but highly unacceptable on multi-million $ computers. We don't tolerate unintentional downtime. -- 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
> On Friday, August 25, 2023 at 09:32:34 PM PDT, Joel C. Ewing > wrote: > in that sense a package is similar to an FMID of a z/OS product; A Unix package name combined with the version is an SMP/e FMID. Just like Unix, a z/OS will have 1 or more FMID. Like Unix, installing 1 of the FMIDs will automatically cause the related/dependant FMIDs to be installed. > There isn't really any direct equivalence between RPM and SMP/E > concepts of maintenance. I repeat, RPM installs packages that has nothing to do with maintenance. The Unix maintenance philosophy is to create multiple smaller packages in the hopes that a single package is less of an impact than reinstalling the entire product. In SMP/e, we can use 1 FMID instead of worrying about maintenance philosophy. > Since a large Linux application (like LibreOffice) may be packaged as > several interdependent packages, but the number of pieces/files contained in a > package tends to vary more widely than for z/OS products, in some cases > containing very few files. Ask yourself why a package with just a few files that could have been included with another package. The one question you don't answer is what goes into your packaging decisions. What are the benefits to creating multiple packages/FMIDs versus 1 large package/FMID? > but new release levels of a package also occur with much greater > frequency than new versions or release levels of a z/OS product. > A new release level of a package typically contains a number of code fixes, > and in that respect is more like a z/OS PTF that fixes multiple APARS. IBM is on a 2 year package / FMID release cycle. Are you saying that z/OS would be manageable where PTFs become available every 2 years? > current RPM download protocols also support just downloading the RPM delta > from the previous package level if only a small part of a large package RPM > file > has changed. Installing changed files versus installing the entire package doesn't change anything except speeding up the process. The new package has been installed completely. > the dependency requirements are simpler to resolve when there are > only package-level dependencies to consider. Dependency resolution is the same for RPM and SMP/e. Neither is complicated for the user. >The frequency of occurrence of new package releases with minor changes > definitely entitles this to be called a maintenance process. Frequency of packaging is the maintenance process. If you change to 20 year packaging frequency, you wouldn't call this maintenance. The process (not RPM) is the maintenance philosophy. > The decentralized nature of Linux package maintenance Linux and RPM are free. Both are basic solutions to a problem. Unlike z/OS, a Linux image is only active on 1 physical machine. Maintenance is applied directly to the active system. A $10,000 machine being down for a couple hours is trivial. Google has 5,500,000 servers so missing 10,000 servers would go unnoticed. On the other hand a multi-million $ sysplex will be catastrophic. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
> On 26 Aug 2023, at 9:55 am, Jon Perryman wrote: > > I think z/OS uptime is 99.%. I don’t think so. IBM claim 99.999% single server uptime for z and that’s just the hardware. That’s the same as they claim for POWER running either AIX or Linux on RedHat Open Shift and what HP claim for Superdomes running HP-UX. They all claim higher then five-nines running in clusters. What this boils down to is there is redundancy in the hardware for PDUs, Network card, I/O adapters. My bank runs a mainframe and I couldn’t use internet banking when abroad because they were running month-end scheduled maintenance. Many providers claiming five-nines availability will add small print to get around this problem. By excluding scheduled downtime, five-nines becomes a lot easier. > You get what you pay for. Unix maint philosophy may be acceptable on $10,000 > computers but highly unacceptable on multi-million $ computers. We don't > tolerate unintentional downtime. That doesn’t stand up to scrutiny! Just ask Air New Zealand in 2009, HSBC in 2011, or the Royal Bank of Scotland in 2013. The fact is that even five-nines availability for an entire computing service is impossible to guarantee. There is too little room for error and Black Swan or unexpected events are impossible to eliminate. If you have access to the IBM support portal go and do a search for z/OS Red Alerts. Software has bugs, applications and subsystems fail. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Tthere isn't really any direct equivalence between RPM and SMP/E concepts of maintenance. Since a large Linux application (like LibreOffice) may be packaged as several interdependent packages, in that sense a package is similar to an FMID of a z/OS product; but the number of pieces/files contained in a package tends to vary more widely than for z/OS products, in some cases containing very few files. I expect the average Linux package contains many fewer elements than the typical z/OS product, so replacing the whole thing is not that big of a deal. The Linux systems I have seen also have many more packages installed than the typical number of FMIDs on a z/OS system. It is true that a package update must replace an entire package, not just changed sub components of a package; but new release levels of a package also occur with much greater frequency than new versions or release levels of a z/OS product. A new release level of a package typically contains a number of code fixes, and in that respect is more like a z/OS PTF that fixes multiple APARS. While all components of an updated package are re-installed, it is also true that current RPM download protocols also support just downloading the RPM delta from the previous package level if only a small part of a large package RPM file has changed. You can back out a package update by re-installing a previous package level, just like you can back out a z/OS PTF that fixes multiple APARs -- the dependency requirements are simpler to resolve when there are only package-level dependencies to consider. The frequency of occurrence of new package releases with minor changes definitely entitles this to be called a maintenance process. That the same RPM file can be used for new installation or maintenance is a nice simplification from the user's standpoint. The decentralized nature of Linux package maintenance and the extremely large number of combinations of packages that could be present on a Linux system does tend to make Linux platforms less predictable. It is not so much a factor of the complete package replacement strategy (changes at the source code level may be minor), as that the maintainers of one package simply cannot test with all other package combinations and may be unaware of some package combinations that are adversely affected by their changes. Linux is more dependent upon their user community to find non-obvious dependency issues. Joel C Ewing On 8/25/23 20:55, Jon Perryman wrote: On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson wrote: With Linux distros there are a few maint systems. The one I am most familiar with is RPM. Linux (nor Unix) does NOT have any maint systems. P in RPM stands for Package which is the z/OS equivalent of product / component. Complete packages are replaced regardless of the problems you want to fix. Every package has a version number which is indentifies all the maintenance included in that package. To me YAST (the Linux equivalent of SMP/E) handles upgrades YAST and SMP/e have nothing in common. YAST tells you it's about installation and configuration. It's about replacing the entire package and nothing to do with maintaining that package. The M in SMP/e stands for Maintenance. You never see a PTF that is 1MB. The only reason SMP/e installs, is to create a maintenance environment for the product / component. If installation is your only requirement, then use a different tool like IEBCOPY, DFDSS or ???. Each product/component has its own main entry and dependencies. Unix dependencies are by version number and have nothing to do with the package (product/component) in question. The package is completely replaced. SMP/e dependencies can be for entities within the same function, other functions, PTFs and APARs. A function is the SMP/e equivalent of a Unix package. I thought it was a fairly good replacement for SMP/E for the Linux side of things. I can see how it could be used to do z/OS and related. YAST, RPM and other Unix package installers are unacceptable replacements for SMP/e. Name 1 z/OS customer that is willing to risk reinstalling an entire product/component because they need 1 PTF. Add to that cascading product installs because of dependencies. Worse than that, testing must include everything that changed in those installs and every product/component that interacts with all the installed products/components. I think z/OS uptime is 99.%. You get what you pay for. Unix maint philosophy may be acceptable on $10,000 computers but highly unacceptable on multi-million $ computers. We don't tolerate unintentional downtime. -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
> On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson > wrote: > With Linux distros there are a few maint systems. The one I am > most familiar with is RPM. Linux (nor Unix) does NOT have any maint systems. P in RPM stands for Package which is the z/OS equivalent of product / component. Complete packages are replaced regardless of the problems you want to fix. Every package has a version number which is indentifies all the maintenance included in that package. > To me YAST (the Linux equivalent of SMP/E) handles upgrades YAST and SMP/e have nothing in common. YAST tells you it's about installation and configuration. It's about replacing the entire package and nothing to do with maintaining that package. The M in SMP/e stands for Maintenance. You never see a PTF that is 1MB. The only reason SMP/e installs, is to create a maintenance environment for the product / component. If installation is your only requirement, then use a different tool like IEBCOPY, DFDSS or ???. > Each product/component has its own main entry and dependencies. Unix dependencies are by version number and have nothing to do with the package (product/component) in question. The package is completely replaced. SMP/e dependencies can be for entities within the same function, other functions, PTFs and APARs. A function is the SMP/e equivalent of a Unix package. > I thought it was a fairly good replacement for SMP/E for the > Linux side of things. > I can see how it could be used to do z/OS and related. YAST, RPM and other Unix package installers are unacceptable replacements for SMP/e. Name 1 z/OS customer that is willing to risk reinstalling an entire product/component because they need 1 PTF. Add to that cascading product installs because of dependencies. Worse than that, testing must include everything that changed in those installs and every product/component that interacts with all the installed products/components. I think z/OS uptime is 99.%. You get what you pay for. Unix maint philosophy may be acceptable on $10,000 computers but highly unacceptable on multi-million $ computers. We don't tolerate unintentional downtime. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
To clarify my previous reply: > To me YAST (the Linux equivalent of SMP/E) One component of Yast fills he same niche as SMP, but there are other components, e.g., partitioning, user administration. Is that also true of SMIT? > So you decide to download an ISO. Yast doesn't handle the install ISO, but the install process probably invokes Yast or zypper under the covers. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Thompson [ste...@wkyr.net] Sent: Thursday, August 24, 2023 2:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RPMs for installs and Maint: [WAS SMP/E needed for installs?] With Linux distros there are a few maint systems. The one I am most familiar with is RPM. To me YAST (the Linux equivalent of SMP/E) handles upgrades and user changes (if you know how to do them, I don't because I'm a SU in Linux -- Stupid User). Each product/component has its own main entry and then dependencies. You can override them if you dare. If you are a developer you would probably know if the override is a good idea. So you decide to download an ISO. If you have a fat pipe and the time, you download a NETWork install ISO. You fill in all the stuff (Upgrade install or "NEW" INSTALL are the primary options). The system loads and boots and if this is a "NEW" install, formats and load partitions etc. etc. Then it gets into all the stuff you said you want installed so it pulls down all the related/needed repositories and packages and goes to work. At a certain point it reboots to the system it has built and then continues with the applications level stuff. From time to time you get notified, or you just check it yourself, and see if there is maint to be added. Yast handles it. I thought it was a fairly good replacement for SMP/E for the Linux side of things. I can see how it could be used to do z/OS and related. Thoughts, and comments? Oh, and I still only do programming on IBM type Mainframes. Steve Thompson On 8/24/2023 2:34 PM, Jon Perryman wrote: > > On Thursday, August 24, 2023 at 11:06:43 AM PDT, Colin Paice > wrote: >> But this fix management would be done by IBM (or product owner). > > I'm guessing that IBM is still on a 2 year release cycle and they still have > a custom-built offering so you're not dealing with a lot of tapes and files. > With as many products that IBM deals with, packaging would be a nightmare. > IBM's RHEL and other Linux distros exists solely to simplify the process and > they don't deal with anywhere near the number of IBM z/OS products. SMP/e is > a good compromise that guarantees everything was performed correctly for your > needs. OEM vendors can easily provide choices because they don't deal with > the magnitude of IBM. > > > > On Thursday, August 24, 2023 at 11:06:43 AM PDT, Colin Paice > wrote: > > ITSchak, > But this fix management would be done by IBM (or product owner). We should > be able to download the image which has been tested by IBM Consolidated > Service Test in POK. > Only if you need >additional< fixes before the next download - do you need > to do any SMP/E work. It would still be there if you need it. > Colin > > On Thu, 24 Aug 2023 at 17:08, ITschak Mugzach wrote: > >> Kurt, >> >> I think the power of SMP/E is not the initial install, but the fix >> management (ptf chain management). Actually many deliveries from IBM have >> SMP/E already populated and technically this is a kind of DSS dump (or can >> be). >> >> ITschak >> >> >> ITschak Mugzach >> *|** IronSphere Platform* *|* *Information Security Continuous Monitoring >> for z/OS, x/Linux & IBM I **| z/VM coming soon * >> >> >> >> >> On Thu, Aug 24, 2023 at 6:48 PM Kurt Quackenbush wrote: >> >>> Yes, thanks for asking, we have thought about an alternative. And an >>> alternative exists in z/OSMF Software Management and Portable Software >>> Instances. In this form you can package, deliver, and install software >>> whether it is SMP/E managed or not. If it is SMP/E managed, as much of >> the >>> software on the z/OS platform is, then the package includes the SMP/E >>> artifacts like CSIs so you can install PTF fixes. You can of course >> choose >>> to ignore the SMP/E artifacts and just repeat the process to install an >>> updated Portable Software Instance in 3 months as you suggest. >>> >>> 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. >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List On Behalf >>> Of Colin Paice >>> Sent: Thursday, August 24, 2023 10:37 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: [EXTERNAL] Is SMP/E needed for installs? >>> >>> This week, I did my first SMP/E install since my previous one over 40 >> years >>> ago! The process hasn't changed much. It took me about half a day to
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
The list of OS and HW pairs ... AIX-powerpc (or "ppc") AIX-powerpc64 (or "ppc64") CYGWIN-i386 CYGWIN-x86_64 Darwin-i386 Darwin-x86_64 Darwin-arm64 FreeBSD-i386 FreeBSD-amd64 HPUX-parisc HPUX-ia64 Linux-i386 (or i486, i586, i686) Linux-x86_64 Linux-s390 Linux-s390x Linux-alpha Linux-arm Linux-arm64 (Linux-aarch64) Linux-m68k Linux-mips Linux-mips64 Linux-ppc Linux-ppc64 Linux-ppc64le Linux-sparc Linux-sparc64 Minix-i386 NetBSD-i386 NetBSD-amd64 OpenBSD-i386 OpenBSD-amd64 OS390-s390 OS390-s390x SunOS-i386 (Solaris-i386) SunOS-x86_64 (Solaris-x86_64 or Solaris-amd64) SunOS-sparc (Solaris-sparc) SunOS-sparc64 (Solaris-sparc64) Windows-x86 (Windows-i386) Windows-amd64 This is not an exhaustive list, just the pairs I've worked with. And some are old: I haven't touched Linux-alpha in a lllooonnnggg time. I also really only use one of the BSDs. Some of the systems are bi-modal: AIX, Linux-s390x, and OS390 are all 64-bit systems these days, but usually still support 32-bit "user space" programs. The names, both left and right, are taken from 'uname' output. I regularly butt heads with a good friend over names like "powerpc", but that's what the systems say about themselves. -- R; <>< On 8/24/23 15:23, Rick Troth wrote: This topic has gotten fun. RPM has an advantage over some installer methods that it includes the architecture (e.g., "x86_64" or "s390x"). Sadly, it does *not* include the operating system (e.g., "Linux" or "OS/390"). But, yeah, effective and widely used. Tools like YUM (for RedHat) and ZYPPER (for SUSE) sit on top of RPM. (YAST is another layer up from ZYPPER and is SUSE's equivalent to AIX's SMIT, but less painful.) In my experience, they're well done. (YAST is excellent.) You can still install packages directly with 'rpm' and either YUM or ZYPPER/YAST will figure things out, not break nor crash. We're skipping the tools used in AIX, Slolaris, HP-UX, and others. It's not rocket surgery. Dependencies are always a problem when you stray outside the distributor/vendor collection. Many times 'rpm' has complained about dependencies/pre-reqs/co-reqs. When I force the install, it usually works. Not always. Sometimes I have to manually sym-link a shared lib with an older name. For many years, I've used a point-n-shoot scheme, lately called Chicory. (Didn't originally have a name.) I use this for packages that I build from source. Once a package is built for a slightly older (e.g.) RedHat Linux, said packages work just fine on a slightly newer SUSE Linux or Debian Linux (of the same HW architecture). Not always, but I've learned to isolate co-reqs/pre-reqs/dependencies. Static linkage helps. In Chicory space, the OS (e.g., "Linux" or "OS/390") and the HW (e.g., "x86_64" or "s390x") are always indicated. This developed over more years than I should admit. I'll enumerate in a separate note. But I can't promote Chicory here: it's painfully close to TAR and ZIP for delivery. (Then again, those *do* work, and are stilled used today by vendors that I've worked for, so mebbe.) Right now it only handles RSYNC or NFS or removable media. Doesn't actually do TAR as such. (Acorse, if someone wants to contribute ...) -- R; <>< On 8/24/23 14:57, Steve Thompson wrote: With Linux distros there are a few maint systems. The one I am most familiar with is RPM. To me YAST (the Linux equivalent of SMP/E) handles upgrades and user changes (if you know how to do them, I don't because I'm a SU in Linux -- Stupid User). Each product/component has its own main entry and then dependencies. You can override them if you dare. If you are a developer you would probably know if the override is a good idea. So you decide to download an ISO. If you have a fat pipe and the time, you download a NETWork install ISO. You fill in all the stuff (Upgrade install or "NEW" INSTALL are the primary options). The system loads and boots and if this is a "NEW" install, formats and load partitions etc. etc. Then it gets into all the stuff you said you want installed so it pulls down all the related/needed repositories and packages and goes to work. At a certain point it reboots to the system it has built and then continues with the applications level stuff. From time to time you get notified, or you just check it yourself, and see if there is maint to be added. Yast handles it. I thought it was a fairly good replacement for SMP/E for the Linux side of things. I can see how it could be used to do z/OS and related. Thoughts, and comments? Oh, and I still only do programming on IBM type Mainframes. Steve Thompson On 8/24/2023 2:34 PM, Jon Perryman wrote: >
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
This topic has gotten fun. RPM has an advantage over some installer methods that it includes the architecture (e.g., "x86_64" or "s390x"). Sadly, it does *not* include the operating system (e.g., "Linux" or "OS/390"). But, yeah, effective and widely used. Tools like YUM (for RedHat) and ZYPPER (for SUSE) sit on top of RPM. (YAST is another layer up from ZYPPER and is SUSE's equivalent to AIX's SMIT, but less painful.) In my experience, they're well done. (YAST is excellent.) You can still install packages directly with 'rpm' and either YUM or ZYPPER/YAST will figure things out, not break nor crash. We're skipping the tools used in AIX, Slolaris, HP-UX, and others. It's not rocket surgery. Dependencies are always a problem when you stray outside the distributor/vendor collection. Many times 'rpm' has complained about dependencies/pre-reqs/co-reqs. When I force the install, it usually works. Not always. Sometimes I have to manually sym-link a shared lib with an older name. For many years, I've used a point-n-shoot scheme, lately called Chicory. (Didn't originally have a name.) I use this for packages that I build from source. Once a package is built for a slightly older (e.g.) RedHat Linux, said packages work just fine on a slightly newer SUSE Linux or Debian Linux (of the same HW architecture). Not always, but I've learned to isolate co-reqs/pre-reqs/dependencies. Static linkage helps. In Chicory space, the OS (e.g., "Linux" or "OS/390") and the HW (e.g., "x86_64" or "s390x") are always indicated. This developed over more years than I should admit. I'll enumerate in a separate note. But I can't promote Chicory here: it's painfully close to TAR and ZIP for delivery. (Then again, those *do* work, and are stilled used today by vendors that I've worked for, so mebbe.) Right now it only handles RSYNC or NFS or removable media. Doesn't actually do TAR as such. (Acorse, if someone wants to contribute ...) -- R; <>< On 8/24/23 14:57, Steve Thompson wrote: With Linux distros there are a few maint systems. The one I am most familiar with is RPM. To me YAST (the Linux equivalent of SMP/E) handles upgrades and user changes (if you know how to do them, I don't because I'm a SU in Linux -- Stupid User). Each product/component has its own main entry and then dependencies. You can override them if you dare. If you are a developer you would probably know if the override is a good idea. So you decide to download an ISO. If you have a fat pipe and the time, you download a NETWork install ISO. You fill in all the stuff (Upgrade install or "NEW" INSTALL are the primary options). The system loads and boots and if this is a "NEW" install, formats and load partitions etc. etc. Then it gets into all the stuff you said you want installed so it pulls down all the related/needed repositories and packages and goes to work. At a certain point it reboots to the system it has built and then continues with the applications level stuff. From time to time you get notified, or you just check it yourself, and see if there is maint to be added. Yast handles it. I thought it was a fairly good replacement for SMP/E for the Linux side of things. I can see how it could be used to do z/OS and related. Thoughts, and comments? Oh, and I still only do programming on IBM type Mainframes. Steve Thompson On 8/24/2023 2:34 PM, Jon Perryman wrote: > On Thursday, August 24, 2023 at 11:06:43 AM PDT, Colin Paice wrote: But this fix management would be done by IBM (or product owner). I'm guessing that IBM is still on a 2 year release cycle and they still have a custom-built offering so you're not dealing with a lot of tapes and files. With as many products that IBM deals with, packaging would be a nightmare. IBM's RHEL and other Linux distros exists solely to simplify the process and they don't deal with anywhere near the number of IBM z/OS products. SMP/e is a good compromise that guarantees everything was performed correctly for your needs. OEM vendors can easily provide choices because they don't deal with the magnitude of IBM. On Thursday, August 24, 2023 at 11:06:43 AM PDT, Colin Paice wrote: ITSchak, But this fix management would be done by IBM (or product owner). We should be able to download the image which has been tested by IBM Consolidated Service Test in POK. Only if you need >additional< fixes before the next download - do you need to do any SMP/E work. It would still be there if you need it. Colin On Thu, 24 Aug 2023 at 17:08, ITschak Mugzach wrote: Kurt, I think the power of SMP/E is not the initial install, but the fix management (ptf chain management). Actually many deliveries from IBM have SMP/E already populated and technically this is a kind of DSS dump (or can be). ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon *
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
YAST and SMP are very different animals, but they fit similar niches, for essentially the same reasons. One major difference is that there is no equivalent to RECEIVE; YAST and zypper install packages directly from the repositories. I assume that apt also fits that niche, but there's probably someone here that can give a definitive answer. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Thompson [ste...@wkyr.net] Sent: Thursday, August 24, 2023 2:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RPMs for installs and Maint: [WAS SMP/E needed for installs?] With Linux distros there are a few maint systems. The one I am most familiar with is RPM. To me YAST (the Linux equivalent of SMP/E) handles upgrades and user changes (if you know how to do them, I don't because I'm a SU in Linux -- Stupid User). Each product/component has its own main entry and then dependencies. You can override them if you dare. If you are a developer you would probably know if the override is a good idea. So you decide to download an ISO. If you have a fat pipe and the time, you download a NETWork install ISO. You fill in all the stuff (Upgrade install or "NEW" INSTALL are the primary options). The system loads and boots and if this is a "NEW" install, formats and load partitions etc. etc. Then it gets into all the stuff you said you want installed so it pulls down all the related/needed repositories and packages and goes to work. At a certain point it reboots to the system it has built and then continues with the applications level stuff. From time to time you get notified, or you just check it yourself, and see if there is maint to be added. Yast handles it. I thought it was a fairly good replacement for SMP/E for the Linux side of things. I can see how it could be used to do z/OS and related. Thoughts, and comments? Oh, and I still only do programming on IBM type Mainframes. Steve Thompson On 8/24/2023 2:34 PM, Jon Perryman wrote: > > On Thursday, August 24, 2023 at 11:06:43 AM PDT, Colin Paice > wrote: >> But this fix management would be done by IBM (or product owner). > > I'm guessing that IBM is still on a 2 year release cycle and they still have > a custom-built offering so you're not dealing with a lot of tapes and files. > With as many products that IBM deals with, packaging would be a nightmare. > IBM's RHEL and other Linux distros exists solely to simplify the process and > they don't deal with anywhere near the number of IBM z/OS products. SMP/e is > a good compromise that guarantees everything was performed correctly for your > needs. OEM vendors can easily provide choices because they don't deal with > the magnitude of IBM. > > > > On Thursday, August 24, 2023 at 11:06:43 AM PDT, Colin Paice > wrote: > > ITSchak, > But this fix management would be done by IBM (or product owner). We should > be able to download the image which has been tested by IBM Consolidated > Service Test in POK. > Only if you need >additional< fixes before the next download - do you need > to do any SMP/E work. It would still be there if you need it. > Colin > > On Thu, 24 Aug 2023 at 17:08, ITschak Mugzach wrote: > >> Kurt, >> >> I think the power of SMP/E is not the initial install, but the fix >> management (ptf chain management). Actually many deliveries from IBM have >> SMP/E already populated and technically this is a kind of DSS dump (or can >> be). >> >> ITschak >> >> >> ITschak Mugzach >> *|** IronSphere Platform* *|* *Information Security Continuous Monitoring >> for z/OS, x/Linux & IBM I **| z/VM coming soon * >> >> >> >> >> On Thu, Aug 24, 2023 at 6:48 PM Kurt Quackenbush wrote: >> >>> Yes, thanks for asking, we have thought about an alternative. And an >>> alternative exists in z/OSMF Software Management and Portable Software >>> Instances. In this form you can package, deliver, and install software >>> whether it is SMP/E managed or not. If it is SMP/E managed, as much of >> the >>> software on the z/OS platform is, then the package includes the SMP/E >>> artifacts like CSIs so you can install PTF fixes. You can of course >> choose >>> to ignore the SMP/E artifacts and just repeat the process to install an >>> updated Portable Software Instance in 3 months as you suggest. >>> >>> 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. >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List On Behalf >>> Of Colin Paice >>> Sent: Thursday, August 24, 2023 10:37 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: [EXTERNAL] Is SMP/E needed for installs? >>> >>> This week, I did my first SMP/E install since my previous one over 40 >> years >>> ago! The process hasn't changed much. It took me about half a day to >>> download the files and configu
