Re: Will z/OS be obsolete in 5 years?
My experience with Linux (RHEL) under zVM is that Linux tries to cache as much of the file system(s) as it can. To me this is a waste of RAM. So here is an interesting situation: Linux has its file systems and then MOUNTS a read only system via IP that is on another platform (NFS?). So this is being cached -- but it is read only, so if any data gets updated, it was updated by the platform that owns that file structure. I tried to get the Linux people to do an experiment: turn off file caching in Linux. See if the z/Arch caching would be just as fast or nearly so. Why was I pushing for this? Because ACE (replacement for IIB) is a CORE HOG as we used to say. In migrating to it, it immediately needed 1 GB more of RAM at a minimum. So in running production we had those servers using 16-32GB of RAM (eventually some were out at 64GB!!), with us also specifying VDISK for swap space (VDisk is actually c-Store or RAM being used as disk as far as Linux could tell, so that it was effectively E-Store for paging). Just getting Linux to stop caching file systems could possibly get us back 20% of the RAM in an LPAR running Linux for z. (Long story to explain this but yes, we could reduce the RAM in those servers by 1-2 GB each if we could prove no impact to production response). Oh, and you do not page Linux -- You have it do all its own paging. Why? Paging paging is like going back to shadow tables and the like for running MVS under VM/370 prior to IEF/SIE. (this being Assembler and not specifically a VM group, IEF is the Interpretive Execution Facility, which has a single instruction, SIE (Start Interpretive Execution)). With that instruction, any time the guest does something that would affect all users, SIE takes an interrupt, drops out to CP, CP then figures out what really needs to be done, does it, and then returns back to the guest via SIE so that the O/S thinks it did whatever. This is the short explanation. Since I never had access to IEF at Amdahl I only know this much of SIE and since those days we are several versions of IEF beyond what we did back then. -- Any one know of anyone that has done this experiment to see if z/Arch caching worked as well as Linux caching a file system? Steve Thompson On 8/8/2023 4:30 AM, dave.g4...@gmail.com wrote: -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jon Perryman Sent: Monday, August 7, 2023 11:05 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Will z/OS be obsolete in 5 years? On Thu, 20 Jul 2023 at 09:01, Rob van der Heij wrote: It would be interesting to see your evidence of IBM Z not performing well with Linux. Linux on z performs better than Linux on most other hardware. My point is that Linux wastes much of z hardware. Since I haven't seen Linux on z, I have to make some assumptions. It's probably fair to say the Linux filesystem still uses block allocation. Let's say it's a 10 disk filesystem and 100 people are writing 1 block repeatedly at the same time. After each writes 10 blocks, where are the 10 blocks for a specific user. In z/OS you know exactly where those blocks would be in the file. If you read that file are these blocks located sequentially. While the filesystem can make a few decisions, it's nothing close to the planning provided by SMS, HSM, SRM and other z/OS tools. Yes but do you really? If you allocate a fixed file size you are wasting the un-used space at the end of the file, or if you run out of space its going elsewhere. I would argue that Linux is better at using disk capacity as you only ever waste half a block. Yes they might be scattered but how much data is on spinning disk and how much on SSD? Like MS Windows disks, Linux filesystems can benefit from defrag. Also consider when Linux needs more CPUs than available. Clustering must be implemented on Linux to increase the number of CPU which does not share the filesystem. In z/OS, a second box has full access to all files because of Sysplex. If the data is in a SAN multiple systems can access them without a SYSPLEX... I'm sure IBM has made improvements but some design limitations will be difficult to resolve without the correct tools. For instance, can DB2 for Linux on z share a database across multiple z frames. It's been a while since I last looked but DB2 for z/OS was used because it outperformed DB2 for Linux on z. Why use DB2? Dave
Re: Will z/OS be obsolete in 5 years?
> -Original Message- > From: IBM Mainframe Assembler List > On Behalf Of Jon Perryman > Sent: Monday, August 7, 2023 11:05 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Will z/OS be obsolete in 5 years? > > > On Thu, 20 Jul 2023 at 09:01, Rob van der Heij wrote: > > It would be interesting to see your evidence of IBM Z not performing well > > with > Linux. > > Linux on z performs better than Linux on most other hardware. My point is that > Linux wastes much of z hardware. > > Since I haven't seen Linux on z, I have to make some assumptions. It's > probably > fair to say the Linux filesystem still uses block allocation. Let's say it's > a 10 disk > filesystem and 100 people are writing 1 block repeatedly at the same time. > After > each writes 10 blocks, where are the 10 blocks for a specific user. > > In z/OS you > know exactly where those blocks would be in the file. If you read that file > are > these blocks located sequentially. While the filesystem can make a few > decisions, it's nothing close to the planning provided by SMS, HSM, SRM and > other z/OS tools. Yes but do you really? If you allocate a fixed file size you are wasting the un-used space at the end of the file, or if you run out of space its going elsewhere. I would argue that Linux is better at using disk capacity as you only ever waste half a block. Yes they might be scattered but how much data is on spinning disk and how much on SSD? > Like MS Windows disks, Linux filesystems can benefit from > defrag. Also consider when Linux needs more CPUs than available. Clustering > must be implemented on Linux to increase the number of CPU which does not > share the filesystem. In z/OS, a second box has full access to all files > because of > Sysplex. > If the data is in a SAN multiple systems can access them without a SYSPLEX... > I'm sure IBM has made improvements but some design limitations will be > difficult to resolve without the correct tools. For instance, can DB2 for > Linux on > z share a database across multiple z frames. It's been a while since I last > looked > but DB2 for z/OS was used because it outperformed DB2 for Linux on z. Why use DB2? Dave
Re: Will z/OS be obsolete in 5 years?
On Tue, 8 Aug 2023 at 00:06, Jon Perryman wrote: > > On Thu, 20 Jul 2023 at 09:01, Rob van der Heij > wrote: > > It would be interesting to see your evidence of IBM Z not performing > well with Linux. > > Linux on z performs better than Linux on most other hardware. My point is > that Linux wastes much of z hardware. > > Since I haven't seen Linux on z, I have to make some assumptions. It's > probably fair to say the Linux filesystem still uses block allocation. > Let's say it's a 10 disk filesystem and 100 people are writing 1 block > repeatedly at the same time. After each writes 10 blocks, where are the 10 > blocks for a specific user. In z/OS you know exactly where those blocks > would be in the file. If you read that file are these blocks located > sequentially. While the filesystem can make a few decisions, it's nothing > close to the planning provided by SMS, HSM, SRM and other z/OS tools. Like > MS Windows disks, Linux filesystems can benefit from defrag. Also consider > when Linux needs more CPUs than available. Clustering must be implemented > on Linux to increase the number of CPU which does not share the filesystem. > In z/OS, a second box has full access to all files because of Sysplex. > I used to say that with several layers of virtualization, performance is rarely intuitive, and often counterintuitive to the uninformed. The famous case is where Linux "CPU wait" goes down when you give it *less* virtual CPUs. Not having looked at it may not give you the best foundation for an opinion. Linux (on any platform) uses a "lazy write" approach where data is kept in memory (page cache) briefly after a change, to see whether it's going to be changed again. A typical case would be where you're copying a lot of files in a directory, and for each file added, the operating system modifies the (in memory) directory. Eventually, the "dirty" blocks are written to disk (we may worry about data loss around an outage, but that's a different discussion - there are mechanisms to ensure data is persistent before you continue with destructive changes). Because Linux will write out blocks at its own convenience, the device driver can order the data to create runs of consecutive blocks in a single I/O operation. Most serious use cases use journaling file systems on Linux and stripe the file systems over multiple disks, so I'm not entirely sure what you aim at with the blocks of a single extent being close together. Yes, I used to worry about the typical stripe that does not align with the 3390 track length, but as 3390 stopped rotating 30 years ago, the control unit cache is not aligned by track either. I don't think anyone on Linux will defrag a file system, especially not because a lot is either on SSD or virtualized on RAID devices. The data-heavy applications often use FCP (SCSI) rather than FICON attached disk because the logical I/O model doesn't take full advantage of the complexity and cost of running your own channel programs. The common scenario is to run Linux in a guest on z/VM so you can size the virtual machine to meet the application requirements. And z/VM Single System Image lets you move the running virtual machine from one member of the cluster to the other to exploit the full capacity available in multiple physically separate IBM Z hardware configurations. Since Linux is popular on small devices, a lot of applications scale horizontally rather than vertically: when your web traffic increases, you fire up a few more Linux guests to spread the load, rather than triple the size of a single Linux instance and expect everything in the application to scale. It is rare to have a Linux application that can consume a full IBM Z configuration. > I'm sure IBM has made improvements but some design limitations will be > difficult to resolve without the correct tools. For instance, can DB2 for > Linux on z share a database across multiple z frames. It's been a while > since I last looked but DB2 for z/OS was used because it outperformed DB2 > for Linux on z. > I expect "outperformed" depends on the type of workload and the API. When you have a COBOL application intimately connected to DB2 to the point where they share the same buffers and such, that's different from an API that is transaction based and communicates through DRDA over TCP/IP as if the application and the data could be in different places.You get away with a lot of bad things in the application design when latency is neglectable. Customers have Linux applications use DB2 on z/OS because the data is there, not because of performance. Rob
Re: Will z/OS be obsolete in 5 years?
These days disks are virtualized. I think the unit is the track. Two "adjacent" tracks from a data set perspective could be on different PC sized disks in the disk subsystem. The "disks" are usually irrelevant as the data is usually in cache!. These days a "defrag" equivalent might be to free unused space in an over allocated dataset. On Mon, 7 Aug 2023 at 23:06, Jon Perryman wrote: > > On Thu, 20 Jul 2023 at 09:01, Rob van der Heij > wrote: > > It would be interesting to see your evidence of IBM Z not performing > well with Linux. > > Linux on z performs better than Linux on most other hardware. My point is > that Linux wastes much of z hardware. > > Since I haven't seen Linux on z, I have to make some assumptions. It's > probably fair to say the Linux filesystem still uses block allocation. > Let's say it's a 10 disk filesystem and 100 people are writing 1 block > repeatedly at the same time. After each writes 10 blocks, where are the 10 > blocks for a specific user. In z/OS you know exactly where those blocks > would be in the file. If you read that file are these blocks located > sequentially. While the filesystem can make a few decisions, it's nothing > close to the planning provided by SMS, HSM, SRM and other z/OS tools. Like > MS Windows disks, Linux filesystems can benefit from defrag. Also consider > when Linux needs more CPUs than available. Clustering must be implemented > on Linux to increase the number of CPU which does not share the filesystem. > In z/OS, a second box has full access to all files because of Sysplex. > > I'm sure IBM has made improvements but some design limitations will be > difficult to resolve without the correct tools. For instance, can DB2 for > Linux on z share a database across multiple z frames. It's been a while > since I last looked but DB2 for z/OS was used because it outperformed DB2 > for Linux on z. >
Re: Will z/OS be obsolete in 5 years?
> On Thu, 20 Jul 2023 at 09:01, Rob van der Heij wrote: > It would be interesting to see your evidence of IBM Z not performing well > with Linux. Linux on z performs better than Linux on most other hardware. My point is that Linux wastes much of z hardware. Since I haven't seen Linux on z, I have to make some assumptions. It's probably fair to say the Linux filesystem still uses block allocation. Let's say it's a 10 disk filesystem and 100 people are writing 1 block repeatedly at the same time. After each writes 10 blocks, where are the 10 blocks for a specific user. In z/OS you know exactly where those blocks would be in the file. If you read that file are these blocks located sequentially. While the filesystem can make a few decisions, it's nothing close to the planning provided by SMS, HSM, SRM and other z/OS tools. Like MS Windows disks, Linux filesystems can benefit from defrag. Also consider when Linux needs more CPUs than available. Clustering must be implemented on Linux to increase the number of CPU which does not share the filesystem. In z/OS, a second box has full access to all files because of Sysplex. I'm sure IBM has made improvements but some design limitations will be difficult to resolve without the correct tools. For instance, can DB2 for Linux on z share a database across multiple z frames. It's been a while since I last looked but DB2 for z/OS was used because it outperformed DB2 for Linux on z.
Re: Will z/OS be obsolete in 5 years?
You are wrong again. https://www.ibm.com/linuxone The latest iteration is version 4, a z16. The first was a z13. See also https://en.wikipedia.org/wiki/Linux_on_IBM_Z -- Tom Marchant On Thu, 20 Jul 2023 00:15:14 +, Jon Perryman wrote: >IBM will never discount an entire z16 just for Linux.
Re: Will z/OS be obsolete in 5 years?
That is your evidence that "for many years IBM has withheld its own changes to GCC for private sale to its own customers"? LOL! -- Tom Marchant On Thu, 20 Jul 2023 07:11:11 +, Ian Worthington wrote: >There is no secret, see >https://www.ibm.com/docs/en/ztpf/2022?topic=tasks-build-gnu-compiler-collection-ztpf-system, > third bullet point. Have your check book handy when you call.
Re: Will z/OS be obsolete in 5 years?
There is no secret, see https://www.ibm.com/docs/en/ztpf/2022?topic=tasks-build-gnu-compiler-collection-ztpf-system, third bullet point. Have your check book handy when you call. My prior belief also didn't agree with those who are saying the rh move is legal under the gpl. But, as I keep saying, I am NAL. Best wishes / Mejores deseos / Meilleurs vœux Ian ... On Wednesday, July 19, 2023 at 11:38:30 PM GMT+2, Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: Yes? That's all you have? Secret claims have no value. Your belief doesn't agree with the GPL version 3, which is the license for GCC. https://www.gnu.org/licenses/gpl-3.0.en.html 5. Conveying Modified Source Versions. You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions: a) The work must carry prominent notices stating that you modified it, and giving a relevant date. b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”. c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. "Released under this License" includes providing source. Providing source does not necessarily mean making it available to anyone. 6. Conveying Non-Source Forms. You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange. b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge. c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b. d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements. e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d. -- Tom Marchant On Wed, 19 Jul 2023 20:42:52 +, Ian Worthington wrote: >Yes.. But, as I said, I believe that they are allowed to do so. > > >Best wishes / Mejores deseos / Meilleurs vœux > >Ian ... > > On Wednesday, July 19, 2023 at 10:36:08 PM GMT+2, Tom Marchant ><00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: > > Do you have evidence that IBM has withheld their changes to GCC? > >-- >Tom Marchant > >On Wed, 19 Jul 2023 1
Re: Will z/OS be obsolete in 5 years?
On Thu, 20 Jul 2023 at 02:15, Jon Perryman wrote: > > Why do that. It would result in a huge loss of hardware revenue. > > IFLs for running UNIX are much cheaper than the CPUs needed to run z/OS. > > IFL's are discounted because Linux runs poorly on z16. Every CPU in a z16 > is the same so IBM will never discount an entire z16 just for Linux. Linux > customers don't want z/OS so z16 is not an option for Linux only customers. > If IBM wants to increase the z16 market share, they must make RHEL perform > as well as z/OS and charge full price for CPUs. It would be interesting to see your evidence of IBM Z not performing well with Linux. That was probably true 20 years ago with the early CMOS CPUs, but not anymore. My experience is that z16 CPUs are very effective running enterprise application workloads in Linux at high levels of utilization. IBM contributions to the various open source projects like the gcc toolchain let you generate code that is optimized to take advantage of the CPU architecture, the zlib compression library takes advantage of the built-in compression instruction, the openssl libraries exploit CPACF instructions when compiled for s390x, java applications in Linux and in z/OS compete well with other platforms, the entire machine learning suite exploits the built-in neural network instruction of the Telum chip. Pricing is too complicated for techies. You get a CPU rather than IFL to run licensed IBM software, which suggests that the price difference for the hardware is for operating system software revenue not recovered by MLC. The same holds for the other specialty engine types that run workloads that do not have to contribute to the operating system software revenue; java runs as fast on a zIIP as on a CP, so that's no reason for the rebate on a zIIP. If you don't need any licensed IBM software to run, you get a machine with only IFL. Rob
Re: Will z/OS be obsolete in 5 years?
> surely only the largest players need Z. When should Google have moved its 5,500,000 servers to z? A mechanic only need 2 tools. A hammer when something should move but won't and duct tape when it moves but shouldn't. Medium players should be using z servers. One IBM z16 can have 2,500 PCIe slots compared to the 8 that the biggest non-IBM motherboards. If Linux were efficient, then more than 8 PCIe slots would be needed. Manufacturers would build it if there were demand. Surely Google alone with 5,500,000 servers would make it profitable. > although Amazon, E-Bay, Microsoft Cloud Services seem to manage without it What alternative do these companies have? Their employees refuse to become z/OS programmers where they don't have control over security, optimization and every other aspect of the computer. They feel it's better to use Big-O instead of relying on Intune to identify program bottlenecks. IBM programmers are business experts whereas Linux programmers are computer experts proud of the tools they use and build. > Did they really "move" TCP/IP & UNIX? If it came from VM, then why did use USS dubbing and a USS RACF segment? TCP/IP 3.1 was from BSD Unix and it was very apparent. 3.2 was better but the 3.4 rework made a world of difference. As for USS, the wiki you mentioned says "not be derived from the AT&T source code". USS was derived from something which I think was BSD. Some of the kernel would be rewritten but there is a lot of code they wouldn't rewrite and obtained from somewhere. The kernel is a small part of what we think of as Unix and many parts were retained. Shells, script and more was carried over from somewhere. >> I think IBM wants to integrate z/OS products to retain their investments and >> expand their customer base.. > Why do that. It would result in a huge loss of hardware revenue. > IFLs for running UNIX are much cheaper than the CPUs needed to run z/OS. IFL's are discounted because Linux runs poorly on z16. Every CPU in a z16 is the same so IBM will never discount an entire z16 just for Linux. Linux customers don't want z/OS so z16 is not an option for Linux only customers. If IBM wants to increase the z16 market share, they must make RHEL perform as well as z/OS and charge full price for CPUs. IBM has a huge investment in z/OS software that if compatible with RHEL would bring in the same revenues as z/OS. On Wednesday, July 19, 2023 at 02:03:10 AM PDT, dave.g4...@gmail.com wrote: > -Original Message- > From: IBM Mainframe Assembler List > On Behalf Of Jon Perryman > Sent: Wednesday, July 19, 2023 1:47 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Will z/OS be obsolete in 5 years? > > IBM RHEL announced it's move to closed source (IBM RedHat Enterprise Linux). > With some changes, DB2, RACF and other z/OS products could run in Linux on > z16 in one sysplexed Linux image. A heck of a lot of changes, for a start z/OS is EBCDIC and Linux is some modern descendant of ASCII ... ... and if they ran on Linux on Z than why won't they run on Linux on some other platform, surely only the largest players need Z.. .. although Amazon, E-Bay, Microsoft Cloud Services seem to manage without it > We know it's possible because IBM moved > Unix and TCP into z/OS. Did they really "move" TCP/IP & UNIX? The original TCP/IP in MVS came from VM and was written in PASCAL so not UNIX based. >From what I remember USS was written from scratch. The entry in Wikipedia >seems to confirm this, it says :- https://en.wikipedia.org/wiki/UNIX_System_Services " ... It is the first UNIX 95 to not be derived from the AT&T source code. " So freshly created, not moved > IBM RHEL said closed source would force non-paying > customers to buy RHEL licenses but this makes no sense. As a statement, it makes perfect sense. If all else is equal it means they will receive money for something they don't at present. > Something else must be in play. Ah, a conspiracy theory. Of course other things are in play, but I believe they are more about protecting the image that "z" is different, in a good way to other platforms than moving zOS to Linux. In fact moving components from z/OS into Linux would, I believe devalue them and reduce their USPs > I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain insights > into > IBM's decision to close source RHEL. You can skip the survey if you don't > want to > take it and view the survey results through this website. Feel free to pass > this > along. > I think IBM wants to integrate z/OS products to retain their investments and > expand their customer base.. Why do that. It would result in a huge loss of hardware revenue. IFLs for running UNIX are much cheaper than the CPUs needed to run z/OS. > Why is the z/OS community ignoring IBM RHEL closed source? Because its not relevant.? Is it ignoring it? > Are software vendors preparing their products for Linux? I
Re: Will z/OS be obsolete in 5 years?
Indeed the changes I'm aware of do not affect generic gcc but a specific ibm product that requires a custom gcc for which ibm will sell you the custom changes. Best wishes / Mejores deseos / Meilleurs vœux Ian ... On Wednesday, July 19, 2023 at 11:32:52 PM GMT+2, Jon Perryman wrote: > Do you have evidence that IBM has withheld their changes to GCC? While hardware specific changes can be maintained with GCC, is there a real purpose? I doubt that IBM modifies anything that affects generic GCC. On Wednesday, July 19, 2023 at 01:36:10 PM PDT, Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: Do you have evidence that IBM has withheld their changes to GCC? -- Tom Marchant On Wed, 19 Jul 2023 19:35:09 +, Ian Worthington wrote: >That's what I had though, but apparently it's not correct. In fact, for many >years IBM has withheld its own changes to GCC for private sale to its own >customers, apparently quite legally.
Re: Will z/OS be obsolete in 5 years?
Yes? That's all you have? Secret claims have no value. Your belief doesn't agree with the GPL version 3, which is the license for GCC. https://www.gnu.org/licenses/gpl-3.0.en.html 5. Conveying Modified Source Versions. You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions: a) The work must carry prominent notices stating that you modified it, and giving a relevant date. b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”. c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. "Released under this License" includes providing source. Providing source does not necessarily mean making it available to anyone. 6. Conveying Non-Source Forms. You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange. b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge. c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b. d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements. e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d. -- Tom Marchant On Wed, 19 Jul 2023 20:42:52 +, Ian Worthington wrote: >Yes.. But, as I said, I believe that they are allowed to do so. > > >Best wishes / Mejores deseos / Meilleurs vœux > >Ian ... > >On Wednesday, July 19, 2023 at 10:36:08 PM GMT+2, Tom Marchant > <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: > > Do you have evidence that IBM has withheld their changes to GCC? > >-- >Tom Marchant > >On Wed, 19 Jul 2023 19:35:09 +, Ian Worthington wrote: > >>That's what I had though, but apparently it's not correct. In fact, for many >>years IBM has withheld its own changes to GCC for private sale to its own >>customers, apparently quite legally. >
Re: Will z/OS be obsolete in 5 years?
You think, Michael, the same as I used to think. But I'm informed that the changes to rhel open-sourcing of rh's secret sauce are legal under the gpl and, thus, changes to the gcc compiler do not have to be made freely available either. I don't claim to understand this. Best wishes / Mejores deseos / Meilleurs vœux Ian ... On Wednesday, July 19, 2023 at 11:01:59 PM GMT+2, Schmitt, Michael wrote: I Am Not A GPL Expert but... My understanding is... * A company can create closed source products using the GCC toolchain * A company can make changes to the GCC toolchain, and then use it to create closed source products (but maybe this is different in GPL3) But * If you sold a compiler that was derived from GCC source now your product is open source and you must make the source available * Same if you found some cool logic in the GCC source and incorporated that source code into your source. So if IBM is changing GCC and the improved GCC in RHEL as closed source, that's bad. But if IBM is changing GCC and using it to compile other things, that's OK. I think. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ian Worthington Sent: Wednesday, July 19, 2023 2:35 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Will z/OS be obsolete in 5 years? That's what I had though, but apparently it's not correct. In fact, for many years IBM has withheld its own changes to GCC for private sale to its own customers, apparently quite legally. (Caveat: The absence of any yacht clearly indicates I am not a lawyer. Nor do I play one on TV.) Best wishes / Mejores deseos / Meilleurs vœux Ian ... On Wednesday, July 19, 2023 at 07:43:38 PM GMT+2, Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: The terms of the GNU General Purpose License do not allow the source to be restricted in any way. The Linux kernel is licensed under GPL v2 https://www.gnu.org/licenses/old-licenses/gpl-2.0.html AFAIK, most of the rest of the GNU operating system (colloquially known as "Linux", although Linux is actually just the kernel) is licensed under GPL v3 https://www.gnu.org/licenses/gpl-3.0.en.html -- Tom Marchant On Wed, 19 Jul 2023 07:03:05 +, Ian Worthington wrote: >Is this correct? My understanding is that the source is still available but >now only to customers in order to prevent downstream suppliers from using rhel >as their base. >Of course I've slept since I saw this discussion so caveat emptor... > > On Wednesday, July 19, 2023 at 02:47:32 AM GMT+2, Jon Perryman > wrote: > >> IBM RHEL announced it's move to closed source (IBM RedHat Enterprise Linux). >> With some changes, DB2, RACF and other z/OS products could run in Linux on >> z16 in one sysplexed Linux image. We know it's possible because IBM moved >> Unix and TCP into z/OS. IBM RHEL said closed source would force non-paying >> customers to buy RHEL licenses but this makes no sense. Something else must >> be in play. >>I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain insights >>into IBM's decision to close source RHEL. You can skip the survey if you >>don't want to take it and view the survey results through this website. Feel >>free to pass this along. >> I think IBM wants to integrate z/OS products to retain their investments and >> expand their customer base.. >>Why is the z/OS community ignoring IBM RHEL closed source? Are software >>vendors preparing their products for Linux?
Re: Will z/OS be obsolete in 5 years?
> Do you have evidence that IBM has withheld their changes to GCC? While hardware specific changes can be maintained with GCC, is there a real purpose? I doubt that IBM modifies anything that affects generic GCC. On Wednesday, July 19, 2023 at 01:36:10 PM PDT, Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: Do you have evidence that IBM has withheld their changes to GCC? -- Tom Marchant On Wed, 19 Jul 2023 19:35:09 +, Ian Worthington wrote: >That's what I had though, but apparently it's not correct. In fact, for many >years IBM has withheld its own changes to GCC for private sale to its own >customers, apparently quite legally.
Re: Will z/OS be obsolete in 5 years?
I Am Not A GPL Expert but... My understanding is... * A company can create closed source products using the GCC toolchain * A company can make changes to the GCC toolchain, and then use it to create closed source products (but maybe this is different in GPL3) But * If you sold a compiler that was derived from GCC source now your product is open source and you must make the source available * Same if you found some cool logic in the GCC source and incorporated that source code into your source. So if IBM is changing GCC and the improved GCC in RHEL as closed source, that's bad. But if IBM is changing GCC and using it to compile other things, that's OK. I think. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ian Worthington Sent: Wednesday, July 19, 2023 2:35 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Will z/OS be obsolete in 5 years? That's what I had though, but apparently it's not correct. In fact, for many years IBM has withheld its own changes to GCC for private sale to its own customers, apparently quite legally. (Caveat: The absence of any yacht clearly indicates I am not a lawyer. Nor do I play one on TV.) Best wishes / Mejores deseos / Meilleurs vœux Ian ... On Wednesday, July 19, 2023 at 07:43:38 PM GMT+2, Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: The terms of the GNU General Purpose License do not allow the source to be restricted in any way. The Linux kernel is licensed under GPL v2 https://www.gnu.org/licenses/old-licenses/gpl-2.0.html AFAIK, most of the rest of the GNU operating system (colloquially known as "Linux", although Linux is actually just the kernel) is licensed under GPL v3 https://www.gnu.org/licenses/gpl-3.0.en.html -- Tom Marchant On Wed, 19 Jul 2023 07:03:05 +, Ian Worthington wrote: >Is this correct? My understanding is that the source is still available but >now only to customers in order to prevent downstream suppliers from using rhel >as their base. >Of course I've slept since I saw this discussion so caveat emptor... > >On Wednesday, July 19, 2023 at 02:47:32 AM GMT+2, Jon Perryman > wrote: > >> IBM RHEL announced it's move to closed source (IBM RedHat Enterprise Linux). >> With some changes, DB2, RACF and other z/OS products could run in Linux on >> z16 in one sysplexed Linux image. We know it's possible because IBM moved >> Unix and TCP into z/OS. IBM RHEL said closed source would force non-paying >> customers to buy RHEL licenses but this makes no sense. Something else must >> be in play. >>I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain insights >>into IBM's decision to close source RHEL. You can skip the survey if you >>don't want to take it and view the survey results through this website. Feel >>free to pass this along. >> I think IBM wants to integrate z/OS products to retain their investments and >> expand their customer base.. >>Why is the z/OS community ignoring IBM RHEL closed source? Are software >>vendors preparing their products for Linux?
Re: Will z/OS be obsolete in 5 years?
Yes.. But, as I said, I believe that they are allowed to do so. Best wishes / Mejores deseos / Meilleurs vœux Ian ... On Wednesday, July 19, 2023 at 10:36:08 PM GMT+2, Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: Do you have evidence that IBM has withheld their changes to GCC? -- Tom Marchant On Wed, 19 Jul 2023 19:35:09 +, Ian Worthington wrote: >That's what I had though, but apparently it's not correct. In fact, for many >years IBM has withheld its own changes to GCC for private sale to its own >customers, apparently quite legally.
Re: Will z/OS be obsolete in 5 years?
Do you have evidence that IBM has withheld their changes to GCC? -- Tom Marchant On Wed, 19 Jul 2023 19:35:09 +, Ian Worthington wrote: >That's what I had though, but apparently it's not correct. In fact, for many >years IBM has withheld its own changes to GCC for private sale to its own >customers, apparently quite legally.
Re: Will z/OS be obsolete in 5 years?
On Wed, Jul 19, 2023 at 2:35 PM Ian Worthington < 0c9b78d54aea-dmarc-requ...@listserv.uga.edu> wrote: > That's what I had though, but apparently it's not correct. In fact, for > many years IBM has withheld its own changes to GCC for private sale to its > own customers, apparently quite legally. > (Caveat: The absence of any yacht clearly indicates I am not a lawyer. > Nor do I play one on TV.) > Best wishes / Mejores deseos / Meilleurs vœux > > Ian ... > For those who are curious, the good folks at https://lwn.net/ have been covering some of these issues. I believe that these are the articles (most of which I haven't even glanced at):: Red Hat cutting back RHEL source availability: https://lwn.net/Articles/935592/ AlmaLinux's response to Red Hat's policy change: https://lwn.net/Articles/935918/ Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model: https://lwn.net/Articles/936127/ McGrath: Red Hat’s commitment to open source: https://lwn.net/Articles/936405/ Brockmeier: Red Hat and the Clone Wars III: The dawn of CentOS: https://lwn.net/Articles/937317/ AlmaLinux to diverge (slightly) from RHEL: https://lwn.net/Articles/938165/ Please be sure to enjoy the day -- we won't get another chance! ;-) Paul On Wednesday, July 19, 2023 at 07:43:38 PM GMT+2, Tom Marchant < > 00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: > > The terms of the GNU General Purpose License do not allow the source to > be restricted in any way. The Linux kernel is licensed under GPL v2 > https://www.gnu.org/licenses/old-licenses/gpl-2.0.html > AFAIK, most of the rest of the GNU operating system (colloquially known as > "Linux", although Linux is actually just the kernel) is licensed under GPL > v3 > https://www.gnu.org/licenses/gpl-3.0.en.html > > -- > Tom Marchant > > On Wed, 19 Jul 2023 07:03:05 +, Ian Worthington wrote: > > >Is this correct? My understanding is that the source is still available > but now only to customers in order to prevent downstream suppliers from > using rhel as their base. > >Of course I've slept since I saw this discussion so caveat emptor... > > > >On Wednesday, July 19, 2023 at 02:47:32 AM GMT+2, Jon Perryman < > jperr...@pacbell.net> wrote: > > > >> IBM RHEL announced it's move to closed source (IBM RedHat Enterprise > Linux). With some changes, DB2, RACF and other z/OS products could run in > Linux on z16 in one sysplexed Linux image. We know it's possible because > IBM moved Unix and TCP into z/OS. IBM RHEL said closed source would force > non-paying customers to buy RHEL licenses but this makes no sense. > Something else must be in play. > >>I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain > insights into IBM's decision to close source RHEL. You can skip the survey > if you don't want to take it and view the survey results through this > website. Feel free to pass this along. > >> I think IBM wants to integrate z/OS products to retain their > investments and expand their customer base.. > >>Why is the z/OS community ignoring IBM RHEL closed source? Are software > vendors preparing their products for Linux? > >
Re: Will z/OS be obsolete in 5 years?
That's what I had though, but apparently it's not correct. In fact, for many years IBM has withheld its own changes to GCC for private sale to its own customers, apparently quite legally. (Caveat: The absence of any yacht clearly indicates I am not a lawyer. Nor do I play one on TV.) Best wishes / Mejores deseos / Meilleurs vœux Ian ... On Wednesday, July 19, 2023 at 07:43:38 PM GMT+2, Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: The terms of the GNU General Purpose License do not allow the source to be restricted in any way. The Linux kernel is licensed under GPL v2 https://www.gnu.org/licenses/old-licenses/gpl-2.0.html AFAIK, most of the rest of the GNU operating system (colloquially known as "Linux", although Linux is actually just the kernel) is licensed under GPL v3 https://www.gnu.org/licenses/gpl-3.0.en.html -- Tom Marchant On Wed, 19 Jul 2023 07:03:05 +, Ian Worthington wrote: >Is this correct? My understanding is that the source is still available but >now only to customers in order to prevent downstream suppliers from using rhel >as their base. >Of course I've slept since I saw this discussion so caveat emptor... > > On Wednesday, July 19, 2023 at 02:47:32 AM GMT+2, Jon Perryman > wrote: > >> IBM RHEL announced it's move to closed source (IBM RedHat Enterprise Linux). >> With some changes, DB2, RACF and other z/OS products could run in Linux on >> z16 in one sysplexed Linux image. We know it's possible because IBM moved >> Unix and TCP into z/OS. IBM RHEL said closed source would force non-paying >> customers to buy RHEL licenses but this makes no sense. Something else must >> be in play. >>I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain insights >>into IBM's decision to close source RHEL. You can skip the survey if you >>don't want to take it and view the survey results through this website. Feel >>free to pass this along. >> I think IBM wants to integrate z/OS products to retain their investments and >>expand their customer base.. >>Why is the z/OS community ignoring IBM RHEL closed source? Are software >>vendors preparing their products for Linux?
Re: Will z/OS be obsolete in 5 years?
The terms of the GNU General Purpose License do not allow the source to be restricted in any way. The Linux kernel is licensed under GPL v2 https://www.gnu.org/licenses/old-licenses/gpl-2.0.html AFAIK, most of the rest of the GNU operating system (colloquially known as "Linux", although Linux is actually just the kernel) is licensed under GPL v3 https://www.gnu.org/licenses/gpl-3.0.en.html -- Tom Marchant On Wed, 19 Jul 2023 07:03:05 +, Ian Worthington wrote: >Is this correct? My understanding is that the source is still available but >now only to customers in order to prevent downstream suppliers from using rhel >as their base. >Of course I've slept since I saw this discussion so caveat emptor... > >On Wednesday, July 19, 2023 at 02:47:32 AM GMT+2, Jon Perryman > wrote: > >> IBM RHEL announced it's move to closed source (IBM RedHat Enterprise Linux). >> With some changes, DB2, RACF and other z/OS products could run in Linux on >> z16 in one sysplexed Linux image. We know it's possible because IBM moved >> Unix and TCP into z/OS. IBM RHEL said closed source would force non-paying >> customers to buy RHEL licenses but this makes no sense. Something else must >> be in play. >>I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain insights >>into IBM's decision to close source RHEL. You can skip the survey if you >>don't want to take it and view the survey results through this website. Feel >>free to pass this along. >> I think IBM wants to integrate z/OS products to retain their investments and >>expand their customer base.. >>Why is the z/OS community ignoring IBM RHEL closed source? Are software >>vendors preparing their products for Linux?
Re: Will z/OS be obsolete in 5 years?
> -Original Message- > From: IBM Mainframe Assembler List > On Behalf Of Jon Perryman > Sent: Wednesday, July 19, 2023 1:47 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Will z/OS be obsolete in 5 years? > > IBM RHEL announced it's move to closed source (IBM RedHat Enterprise Linux). > With some changes, DB2, RACF and other z/OS products could run in Linux on > z16 in one sysplexed Linux image. A heck of a lot of changes, for a start z/OS is EBCDIC and Linux is some modern descendant of ASCII ... ... and if they ran on Linux on Z than why won't they run on Linux on some other platform, surely only the largest players need Z.. .. although Amazon, E-Bay, Microsoft Cloud Services seem to manage without it > We know it's possible because IBM moved > Unix and TCP into z/OS. Did they really "move" TCP/IP & UNIX? The original TCP/IP in MVS came from VM and was written in PASCAL so not UNIX based. >From what I remember USS was written from scratch. The entry in Wikipedia >seems to confirm this, it says :- https://en.wikipedia.org/wiki/UNIX_System_Services " ... It is the first UNIX 95 to not be derived from the AT&T source code. " So freshly created, not moved > IBM RHEL said closed source would force non-paying > customers to buy RHEL licenses but this makes no sense. As a statement, it makes perfect sense. If all else is equal it means they will receive money for something they don't at present. > Something else must be in play. Ah, a conspiracy theory. Of course other things are in play, but I believe they are more about protecting the image that "z" is different, in a good way to other platforms than moving zOS to Linux. In fact moving components from z/OS into Linux would, I believe devalue them and reduce their USPs > I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain insights > into > IBM's decision to close source RHEL. You can skip the survey if you don't > want to > take it and view the survey results through this website. Feel free to pass > this > along. > I think IBM wants to integrate z/OS products to retain their investments and > expand their customer base.. Why do that. It would result in a huge loss of hardware revenue. IFLs for running UNIX are much cheaper than the CPUs needed to run z/OS. > Why is the z/OS community ignoring IBM RHEL closed source? Because its not relevant.? Is it ignoring it? > Are software vendors preparing their products for Linux? I assume that those that are relevant already have, but for any that were using free RHEL on Z to develop will now face extra charges. Will their prices go up? Will they exit the Z market. ... one last point, my question would be, is this likely to back-fire on IBM? Will it deter any one in a University or Academia from buying Z if they have to pay, or will IBM offer them a discount of 100%? Dave
Re: Will z/OS be obsolete in 5 years?
Is this correct? My understanding is that the source is still available but now only to customers in order to prevent downstream suppliers from using rhel as their base. Of course I've slept since I saw this discussion so caveat emptor... Best wishes / Mejores deseos / Meilleurs vœux Ian ... On Wednesday, July 19, 2023 at 02:47:32 AM GMT+2, Jon Perryman wrote: IBM RHEL announced it's move to closed source (IBM RedHat Enterprise Linux). With some changes, DB2, RACF and other z/OS products could run in Linux on z16 in one sysplexed Linux image. We know it's possible because IBM moved Unix and TCP into z/OS. IBM RHEL said closed source would force non-paying customers to buy RHEL licenses but this makes no sense. Something else must be in play. I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain insights into IBM's decision to close source RHEL. You can skip the survey if you don't want to take it and view the survey results through this website. Feel free to pass this along. I think IBM wants to integrate z/OS products to retain their investments and expand their customer base.. Why is the z/OS community ignoring IBM RHEL closed source? Are software vendors preparing their products for Linux?
Re: Will z/OS be obsolete in 5 years?
Linux in VM is a non-starter for hyperscale Linux computing. You might as well by PC servers. On Tuesday, July 18, 2023 at 05:59:54 PM PDT, David Kreuter wrote: Stick it in a Linux container in a Linux virtual machine under z/VM. Done. From: IBM Mainframe Assembler List on behalf of James H Sent: Tuesday, July 18, 2023 8:52:01 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Will z/OS be obsolete in 5 years? Wow, thats interesting. I will have to research this more. My first thought is this is just a move by IBM to get more money. J-| On Tue, Jul 18, 2023, 19:47 Jon Perryman wrote: > IBM RHEL announced it's move to closed source (IBM RedHat Enterprise > Linux). With some changes, DB2, RACF and other z/OS products could run in > Linux on z16 in one sysplexed Linux image. We know it's possible because > IBM moved Unix and TCP into z/OS. IBM RHEL said closed source would force > non-paying customers to buy RHEL licenses but this makes no sense. > Something else must be in play. > I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain > insights into IBM's decision to close source RHEL. You can skip the survey > if you don't want to take it and view the survey results through this > website. Feel free to pass this along. > I think IBM wants to integrate z/OS products to retain their investments > and expand their customer base.. > Why is the z/OS community ignoring IBM RHEL closed source? Are software > vendors preparing their products for Linux? >
Re: Will z/OS be obsolete in 5 years?
IBM is driven by profits but a single sysplexed Linux server could have 7,000 cores. Google has 5,500,000 Linux servers with an army to maintain it. 25 cores is less cores than the smallest IBM z16 (max 39 with 39 cores enabled). Google admits they have equipment failing all the time. They have a disk drive shredder on site to keep up with the disk drive failures. Linux is designed for small computers. On Tuesday, July 18, 2023 at 05:52:37 PM PDT, James H wrote: Wow, thats interesting. I will have to research this more. My first thought is this is just a move by IBM to get more money. J-| On Tue, Jul 18, 2023, 19:47 Jon Perryman wrote: > IBM RHEL announced it's move to closed source (IBM RedHat Enterprise > Linux). With some changes, DB2, RACF and other z/OS products could run in > Linux on z16 in one sysplexed Linux image. We know it's possible because > IBM moved Unix and TCP into z/OS. IBM RHEL said closed source would force > non-paying customers to buy RHEL licenses but this makes no sense. > Something else must be in play. > I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain > insights into IBM's decision to close source RHEL. You can skip the survey > if you don't want to take it and view the survey results through this > website. Feel free to pass this along. > I think IBM wants to integrate z/OS products to retain their investments > and expand their customer base.. > Why is the z/OS community ignoring IBM RHEL closed source? Are software > vendors preparing their products for Linux? >
Re: Will z/OS be obsolete in 5 years?
Stick it in a Linux container in a Linux virtual machine under z/VM. Done. From: IBM Mainframe Assembler List on behalf of James H Sent: Tuesday, July 18, 2023 8:52:01 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Will z/OS be obsolete in 5 years? Wow, thats interesting. I will have to research this more. My first thought is this is just a move by IBM to get more money. J-| On Tue, Jul 18, 2023, 19:47 Jon Perryman wrote: > IBM RHEL announced it's move to closed source (IBM RedHat Enterprise > Linux). With some changes, DB2, RACF and other z/OS products could run in > Linux on z16 in one sysplexed Linux image. We know it's possible because > IBM moved Unix and TCP into z/OS. IBM RHEL said closed source would force > non-paying customers to buy RHEL licenses but this makes no sense. > Something else must be in play. > I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain > insights into IBM's decision to close source RHEL. You can skip the survey > if you don't want to take it and view the survey results through this > website. Feel free to pass this along. > I think IBM wants to integrate z/OS products to retain their investments > and expand their customer base.. > Why is the z/OS community ignoring IBM RHEL closed source? Are software > vendors preparing their products for Linux? >
Re: Will z/OS be obsolete in 5 years?
Wow, thats interesting. I will have to research this more. My first thought is this is just a move by IBM to get more money. J-| On Tue, Jul 18, 2023, 19:47 Jon Perryman wrote: > IBM RHEL announced it's move to closed source (IBM RedHat Enterprise > Linux). With some changes, DB2, RACF and other z/OS products could run in > Linux on z16 in one sysplexed Linux image. We know it's possible because > IBM moved Unix and TCP into z/OS. IBM RHEL said closed source would force > non-paying customers to buy RHEL licenses but this makes no sense. > Something else must be in play. > I created a survey at https://forms.gle/ZTPXsDJo8Z4H93sv7 to gain > insights into IBM's decision to close source RHEL. You can skip the survey > if you don't want to take it and view the survey results through this > website. Feel free to pass this along. > I think IBM wants to integrate z/OS products to retain their investments > and expand their customer base.. > Why is the z/OS community ignoring IBM RHEL closed source? Are software > vendors preparing their products for Linux? >
