It used to be, most of a single CICS region other than some DB2-related work was single threaded. Don't know if that has improved in the last five years, but am sure there must still be significant parts of CICS that are single thread. The only way to give more CPU to a CICS that was CPU-constrained, required splitting the load to multiple CICS Regions.
Over the years, the main reasons we used multiple CICS regions under MVS was for application isolation, downtime isolation, and increased CPU resources -- not merely because of virtual memory constraints. I know some of our application code relies on the VL bit to detect end of parameter lists. You cannot depend on existing code being trivial to convert. Like Y2K, it is not that individual fixes are complicated, but there can be massive amounts of code to review to find where the fixes are required. There would inevitably be bugs introduced in both application code and the OS. Not worth the effort and risk for a measly doubling of virtual address space. Joel C. Ewing On 4/5/19 11:43 PM, Mike Schwab wrote: > Actually, they started under MVS with 8MiB user memory or so. Plus > splitting different applications into their own regions to isolate, > close certain partition at specified times for batch and backup > processing, etc. > > On Fri, Apr 5, 2019 at 11:55 AM Paul Edwards <mutazi...@gmail.com> wrote: >> Hi Mike. >> >> I'm trying to understand why some sites >> are running multiple CICS regions because >> 2 GiB is not enough. Yet they haven't >> gone to AM64. I want to know if they >> would be interested in going to AM32 >> instead, if it were available. Can you >> elaborate? If AM32 was more practical >> for them, they would be able to halve >> the number of CICS regions they have. >> >> BTW, Rob Prins recently updated his >> 47,000-line RPF assembler program to >> make it AM32-clean, and it required >> very little effort. He was using "VL" in >> a variety of places, but the things he >> was calling were not actually variable >> parameter functions, so he just needed >> to delete the VL. No rewrite was >> necessary, as would be required if >> moving to AM64. >> >> Thanks. Paul. >> >> >> >> >> On Fri, 5 Apr 2019 02:41:15 -0500, Mike Schwab <mike.a.sch...@gmail.com> >> wrote: >> >>> If you are wanting to run in AM64 and use 32 bit constants, that is >>> certainly possible. You will then be limited to incrementing >>> registers by 4GiB or less. Just establishing addressability will need >>> to set all 64 bits. >>> >>> On Thu, Apr 4, 2019 at 2:40 PM Paul Edwards <mutazi...@gmail.com> wrote: >>>> On Thu, 4 Apr 2019 19:32:01 +0000, Martin Packer >>>> <martin_pac...@uk.ibm.com> wrote: >>>> >>>>> They will be (running 64-bit). However, apart from Db2*, much of their >>>>> virtual storage components can't tolerate being above the bar. >>>> Which virtual storage components can't tolerate >>>> being above the bar, and why is that and what >>>> would need to change? >>>> >>>> Thanks. Paul. >>>> >>>> ... >>>> >>>> -- >>>> Mike A Schwab, Springfield IL USA >>>> Where do Forest Rangers go to get away from it all? >>>> >>>> ... -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
