>1,MVS allow different task to have their own address space.While the number of address space increases in system,the total amount of virtual storage can become very big. >However,as I know,virtual storage is supported by real storage and auxiliary storage.With 31-bit addressing,the max size of real storage or auxiliary storage is 2G. > So,the max size of virtual storage=max real storage+max auxiliary storage=4G > Does this mean that the total size of all the address spaces cannot exceed 4G although in theory each address space can have a max size of 2G?
>2,Take a TSO user's address space for example.Suppose its size is 5M.Whenthe user logon to tso,the address space is established which means 5M virtual storage space is >allocated for this address space.So this 5M space is being mapped using real storage plus auxiliary storage even if the user doesn't do any job after logon? Each address space has up to 2 GB available (not in use) which will reside in a combination of real and auxiliary storage. Therefore the more address spaces running, the more real storage and auxiliary storage is committed to support them. If there are too many address spaces with large virtual storage requirements, then real storage may be over-committed and require more movement of pages between real and auxiliary storage. In this case, the "benefit" of allowing more work in the system is offset by the "cost" of moving storage between real and auxiliary. The maximum size of virtual storage (in 31-bit mode) is always 2 GB since that is the largest address that can be contained in 31-bits. Similarly, that is the reason why there can be no more than 2 GB's of real memory. In 31-bit mode there is simply no way to hold an address referencing anything larger. Using your example of the TSO user's address space; the 5MB only represents a "potential" use and therefore essentially defines a limit regarding how much virtual storage we're willing to allow this user to access. In a nutshell, the virtual storage limit is based on the amount that a user MIGHT allocate. Based on what they allocate (i.e. actually use), this translates into a requirement to hold these pages someplace; either in real memory or auxiliary storage. If all the virtual storage can't be held in real memory, then a potential exists requiring storage to be moved between real and auxiliary storage (i.e. paging). There is fundamentally no virtual storage limit regarding the number of address spaces other than those imposed by the z/OS operating system itself (which are based on boundaries regarding control block sizes). However, a practical limit is reached when the performance costs of moving pages between real and auxiliary become greater than the benefit of running that much concurrent work. In principle, if you can tolerate it, then you can do it. 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
