>Yes.The expand of common area will surely 'steal' a portion of every address space's private area.In practice it usually causes little problem for >application above the line. (partly because there is big enough space above the line) However,as for application below the line,sometims it does cause >problems.The reason that makes difference is that the size below the line is just 16M,too small space.
>For example,at the beginning the common area size below the line is 5M,which leaves 11M private area below the line.Then a user executes a program which >must execute below the line.If the program occupies all 11M private area,when you dynamically add modules to LPA which requres common area below the line >to expand one more 1M,the system suddently faces two choices:fail the expand or abend the user's program. Correct, except that the system will NOT fail the expansion at IPL time. Also note that the CSA boundary will NOT dynamically change during the life of an IPL. The expansion is set at IPL time based on the definitions for SQA and CSA in IEASYSxx and the size of LPA. Based on these values, the system will determine how much storage is required to satisfy the "common" requirement. Whatever is leftover is available for user address spaces. In fact, a little more information may help you see how some of this works. Since LPA contains programs, it's size can only be determined when it is loaded at IPL time. The SQA definition will take the space necessary for the fixed storage frames it needs. CSA will then take it's defined allocation and round it to the 1MB segment boundary. If SQA should fill up, it will dynamically expand into the CSA defined area. If CSA fills up you have a problem. You can see this virtual storage map in most of the performance monitors on the market. In addition if you examine the GDA control block (from CVT+X'230') you will see the boundary definitions as they apply for this IPL (if you aren't familiar with these control blocks, you can find them documented in the Data Areas manuals). If there isn't enough space available within the address space to start a unit of work, that work will fail with a GETMAIN-type of failure. This is not an uncommon problem with environments where there is a heavy 24-bit requirement in subsystems like CICS. In those cases, an installation is usually quite sensitive to changes in the boundary alignment of CSA and can experience problems if that changes. The solution, of course, is to convert the resident programs to 31-bit mode so they don't have the dependency. Hope this helps. Adam ---------------------------------------------------------------------- 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
