On 2 Dec 2010 05:33:58 -0800, in bit.listserv.ibm-main you wrote: >Martin, > >This was confirmed to me by a very senior, knowledgeable person at a large >manufacturing company in the Midwest. Originally, they had split CICS into >multiple regions for functional and operational reasons, but the number grew >from ten to over eight hundred because they kept running out of address space >for programs. > >In fact, it is all related. When you split CICS into multiple regions, many >items are duplicated in each region (such as buffer pools). When files are >shared across multiple regions, more CPU is burned serializing updates. You >can place all of the files into FORs, but then you have the cost of shipping >every file control request to another CICS region and all of the issues with >dispatching another address space. > >CICS has been a slow adaptor of 31-bit and 64-bit facilities. I wrote white >papers for SHARE for the CICS project (with lots of other contributors) for >CICS exploitation of XA, and a similar one for 64-bit. We analyzed many shops >to see what items were the easiest to relocate. It's a complex situation, and >there is no magic silver bullet. But programs are a large issue, and will need >to be addressed.
How much of this problem could be eliminated by COBOL and the access methods moving all data (Working Storage, data buffers, etc.) above the BAR? Would there be a good business justification for 64 bit COBOL based on your posting. This sounds like the sort of thing that is known at the systems programming techie level but not the buying level. Clark Morris > >Tom Harper >Neon Enterprise Software >Sugar Land, TX > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of >Martin Packer >Sent: Thursday, December 02, 2010 7:22 AM >To: [email protected] >Subject: Re: 64 bit mode disabled > >Tom Harper wrote: > >> I'm not so sure. Many CICS shops have pointed out to me that they >> are forced to run hundreds of CICS regions for the simple fact >> that 2G is not enough address space to contain all of their programs. >> This requires them to spend an inordinate amount of time managing >> regions for the sole reason of address space exhaustion. > >Tom, I'm not really disputing what you're saying but I'd be surprised if >many of those were limited by the program code - I'd be expecting >concurrency of transactions to be an issue but not the set of load >modules. Do you have examples where the CICS statistics (or other >instrumentation) confirms it's the loaded modules that are the problem? > >Thanks, Martin > >Martin Packer, >Mainframe Performance Consultant, zChampion >Worldwide Banking Center of Excellence, IBM > >+44-7802-245-584 > >email: [email protected] > >Twitter / Facebook IDs: MartinPacker > > > > > >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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
