> On 19 Jul 2023, at 12:44 pm, kekronbekron > <000002dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > > The "gift" is not containers but container tech... layering. > Just lifting and shifting distributed tech onto mainframe, with no > consideration of the extreme complexities is very wasteful. > Container orchestration exists because some of those containers (or the hosts > they may run on) may have a problem. > How likely is that to happen on Z? > I know there's also the thing about service boundary, isolation etc. but do > we really need all of that, totally ignoring equivalent patterns that already > exist in zOS?
There are a lot of very wise an experienced folks who have quite clearly stated that conatainers are critical to the future of z/OS. > > Yes, zCX lets you treat a container as just another address space. > But at the added complexity of container-related setup itself that needs to > happen within/across zCX. > With native containers being controlled with systemd (which will be possible > if LSS exists), we needn't touch kubernetes with a 100 foot poll. > Just because everyone is jumping about K doesn't mean it makes sense as a > universal solution. > > Anyway, there's already a lot of work from IBM indicating that zOS will > become just another dumb box that's controllable by the kuberlords (not using > this term in a derogatory manner, just referring to container people, usually > distributed folks). > I don’t have a a problem with that. I recently saw a demo from IBM where they spun up a z/OS system running on OCP on Linux for Z. IBM has written a large collection of Ansible modules to do useful things like define a DB2 system, IMS system gens, CICS stuff etc. I was impressed. We have Ansible where I work and can stand up development z/OS images on z/VM. Very handy if you doing systems level programming and don’t want to hose the LPAR you share with your team. This new stuff was next level. > - KB > > ------- Original Message ------- > On Wednesday, July 19th, 2023 at 9:39 AM, David Crayford > <dcrayf...@gmail.com> wrote: > > >>> On 19 Jul 2023, at 9:52 am, kekronbekron >>> 000002dee3fcae33-dmarc-requ...@listserv.ua.edu wrote: >>> >>> Here's a dumb and bold prediction - the guts of RHEL (CoreOS) will be laid >>> bare within zOS. >> >> >> Nice idea, but I doubt it. >> >>> USS becomes LSS. zOS native containers are actually normal containers that >>> you see in the linux world. >>> DSFS and zCX end up helping to blur the boundaries between zOS and LSS. >> >> >> Containers on their own are of limited use. You really need clusters and >> orchestration for it to be useful. We have z/CX Foundation for Red Hat >> OpenShift which requires 6 zIIPs just to idle. I’m sure it will get there in >> the end but it’s a dog at the moment. >> >>> zOS is not going away. But we could all use a total re-think of zOSMF. >>> >>> - KB >>> >>> ------- Original Message ------- >>> On Wednesday, July 19th, 2023 at 6:17 AM, 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? >>>> >>>> ---------------------------------------------------------------------- >>>> 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
