|
While virtual memory limits do exist within MSO, they do not imply any kind of performance characteristic. With virtual memory, the site simply needs to ensure that adequate paging space is available on disk to hold the size of the MSO address space. It is the real memory requirements that dictate how much physical memory will be needed to support a given number of MSO users. Thus, even though MSO may require as much as 4MB of virtual memory per user, the entire 4MB need not be real in the sense that a site must purchase this much main memory per user. The actual real memory requirements are very different from the virtual memory requirements. |
In this section: |
The real memory requirement for MSO FOCUS use is essentially identical to the real memory requirement for TSO FOCUS use, and is roughly 1 to 1.5 MB per active user. An active user is not strictly defined, but can be loosely described as any user who has pressed the enter key on the terminal in the past five minutes or so.
Thus, to calculate how much real memory is required to support a given number of users, it is important to know what percentage of them will be active. If only two users are active out of a logged on population of 50, then only 2-3 MB of real memory will be required. On the other hand, if all 50 users are equally active, then 50 to 75 MB of real memory will be required to support them.
It is important to understand that real memory requirements for MSO can be fulfilled using either central or expanded storage. This means that the 1-1.5 MB can essentially all be expanded storage, which is much less expensive than central storage.
A certain amount of central storage will, of course, be needed to support individual transactions. A very rough rule of thumb would be 100K per active user, except for users running very long running jobs, which require the full 1-1.5 MB of central storage.
Experience has shown that typical FOCUS sites have roughly the same proportion of transaction types: 50% of users are using pre-written FOCUS programs as on-line transactions, 40% are doing essentially FOCUS development (such as writing a new report) and 10% may be executing long running tasks (such as large reports). In this type of site, perhaps one out of three logged on users is active. This means that to support 50 logged on users, 17 to 25 MB of expanded storage is required, along with 2 to 3 MB of main memory. For each long running job, we would add an additional 1 MB of main memory.
Another fairly common MSO FOCUS scenario would be a small number of data entry operators executing a transaction-oriented application. Here, all users are always active and thus each require 1-1.5 MB of expanded storage. To handle 15 such users in an MSO address space would require about 15-22 MB of expanded storage and 2 to 3 megabytes of central storage. Eighty users is a typical maximum number of users per address space.
If too many MSO users are competing for an inadequate amount of central or expanded storage, thrashing will result. When this happens, MVS tries to page in and out memory pages from auxiliary storage (DASD). If there is an inadequate number of paging actuators available to the system, the entire system can stall (except for those address spaces that are storage isolated). Since, unlike TSO FOCUS, MVS cannot distinguish between users in MSO, it is important not to allow too many MSO users to log onto the system when there is inadequate memory to support them. This is done via the MAXIMUM configuration file parameter.
It can be difficult to know under MVS how much expanded storage is actually available for use, because all the MVS address spaces share expanded storage. Thus, when planning for a certain number of active MSO users, the safest bet is to plan to add the required expanded storage if it appears to be needed. If paging rates dramatically increase while adding a few active MSO users, the extra-expanded storage is probably required.
| Information Builders |