On Sat, 30 Jun 2012 11:59:02 -0400, Edward Jaffe <[email protected]> wrote:
While there is one shrinking virtual 24-bit area per address space, there is ONLY ONE 24-bit real storage area shared by the ENTIRE SYSTEM! So, not only does growth of fixed, common 24-bit storage 'eat' into the total that is available, but private 24-bit addresses when they are fixed (such as during an I/O) are competing for an ever-shrinking pool of 4K frames in that singular system-wide area.
This would depend on how the buffer storage was allocated. If the buffers were allocated with LOC=(24,31) or even LOC=(24,64) or some moral equivalent the buffers will be fixed in 31 or 64-bit storage. From the DFSMS macro Instructions for datasets manual: ---------------------------------------------------------------------------------- Storage for all data areas and control blocks can be backed above the 2 GB bar even if your program is running in 24-bit mode. This means that you can code either of the following: * LOC=(BELOW,ANY) * LOC=(BELOW,64) on the GETMAIN or STORAGE macro. Recommendation: Code the second value as 64. Note: Code LOC=(BELOW,ANY) or LOC=(BELOW,24) when using tape devices that do not support 64-bit IDAWs. ----------------------------------------------------------------------------------- One can take this further and recommend that (almost) all GETMAINs and STORAGE macros, whether or not they're used for I/O, be changed to use 64 as the second LOC parameter. While I understand the backward-compatibility concerns that led IBM to not make this the default, the reality is that there is almost no storage in most applications that can't/shouldn't be backed in 64-bit storage. -- Cheers, Alex Kodat Sirius Software
