Another reason for separating CICS workloads is security. CICS transaction separation can only really be achieved through separate address spaces.
Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Martin Packer Sent: 07 April 2019 07:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] AMODE 32 I dodged the “why multiple CICS regions?” aspect as this thread has already got complex enough. The “CICS topology” topic is wonderfully complex, of course, and it’s one of the things my workshops with customers delve into. I would say “QR TCB Constraint” is still a live issue, but less of one. Certainly lots of things got offloaded to other TCBs, but lots didn’t. I also think Threadsafe plays into this quite a bit. But, to try to bring it back to the OP’s line of thinking a little, I would not consider 31-bit or 42-bit virtual storage to be a frequent issue in CICS estate design. It’s the sort of thing you check for, of course. Your point - “QR TCB Constraint” - is more prevalent. Cheers, Martin Sent from my iPad > On 6 Apr 2019, at 21:19, Joel C. Ewing <jcew...@acm.org> wrote: > > 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 >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- 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
