V5R1 - CCASERVR in a Dataspace or Hiperspace By James Damon
Understanding CCASERVR? Each logged-in user resides in a server. Nearly everything known about a user--parameters, table settings, active application, current file--is contained in that user’s server. The server resides either in memory in an NSERVS server or, if the user has been swapped out, resides in the CCASERVR dataset. Temporarily inactive users may be swapped out from their in-memory server to the CCASERVR dataset. However, to receive service from Model 204, a user must be swapped into one of the NSERVS-in-memory servers. These are part of the Model 204 address space.
CCASERVR is the Model 204 swap dataset and is similar to the swap/page datasets used by the OS/390 and z/OS operating systems to swap out entire address spaces. CCASERVR provides a facility for reducing the amount of real storage required to support a given number of users because an active user can occupy the in-memory server previously occupied by a now inactive user. However, swapping users in and out of in-memory servers to CCASERVR requires physical I/O to disk datasets: CCASERVR, CCASERV0, CCASERV1, and so on. If this I/O is eliminated, you may realize dramatic performance improvements and reduced response times in busy, production systems with large numbers of users. Eliminating this I/O also reduces device and channel busy times and further improves overall system performance.
In-memory CCASERVR essentially replaces the CCASERVR dataset or datasets with an in-memory copy of that dataset, either a dataspace or a hiperspace. Although users are still swapped between a server in-memory (NSERVS) and CCASERVR, when CCASERVR is in memory, server swaps are in-memory data movements and do not incur the electro-mechanical delays associated with swapping to disk.
Address Space Comments and Advice Before allocating CCASERVR in a dataspace or hiperspace, CCA first recommends that you consider setting NUSERS=NSERVS to eliminate server swapping altogether. This requires the same amount of storage as CCASERVR in a dataspace or hiperspace but is more efficient because the overhead of server swapping is completely eliminated. However, if NUSERS*largest.SERVSIZE bytes of virtual storage are not available in one address space, CCASERVR in a dataspace or hiperspace is the next best alternative. Use the following guidelines:
Regardless of which of these you chose, CCA strongly recommends that you enable page oriented movement for server swapping by setting DSPOPT=1 in CCAIN. The overhead of rounding servers on a page boundary is fairly small and produced significant performance improvement at a major Model 204 site. (Setting DSPOPT=1 is required for hiperspaces.)
Comparing Dataspace and Hiperspace
IBM Defines a Dataspace “A range of up to 2 gigabytes of contiguous virtual storage addresses that a program can directly manipulate through assembler instructions. Unlike an address space, a data space can hold only user data; it does not contain common areas, system data, or programs. Instructions do not execute in a data space.”
IBM Defines a Hiperspace “A range of up to 2 gigabytes of contiguous virtual storage addresses that a program can use as a buffer. A hiperspace is like a dataspace in the following ways: A hiperspace can hold user data; it does not contain common areas or system data. Instructions do not execute in a hiperspace. However, a hiperspace is unlike a dataspace (or an address space) in that data is not directly addressable in the hiperspace. To manipulate data in a hiperspace, the data must be brought into the address space in 4KB blocks.”
Although hiperspace means high performance dataspace, this may not always be the case. A dataspace that resides completely in real storage may, in fact, provide better performance than a hiperspace. The issue of hiperspaces, however, is about to become moot. Under z/OS running in 64-bit mode, hiperspaces no longer exist because expanded storage no longer exists. Dataspaces continue to be supported and are defined as above but are no longer backed by expanded storage.
CCASERVR in Memory On OS operating systems, OS/390 and z/OS, CCASERVR is allocated in memory if the CCASERVR DD statements are omitted from the Online JCL. Depending on the setting of DSPOPT, CCASERVR is created as a hiperspace or dataspace. If backed entirely by central storage with no paging required, allocating and formatting CCASERVR as a dataspace occurs nearly instantaneously, significantly reducing the amount of time required to bring up a large Online. Unless NUSERS*SERVSIZE bytes of expanded storage are available on your system, CCASERVR in a dataspace will probably provide better performance than CCASERVR in a hiperspace.
MONITOR DATASPACE Command Under V5R1, when you allocate CCASERVR in memory, a MONITOR DATASPACE command can provide additional information concerning memory allocation and the data movements required to support server swapping.
The Figure 1 display was obtained immediately after Model 204 initialization.
Figure 1. A VIEW parameters command and MONITOR DATASPACE command
VIEW DSPOPT,NSERVS,NUSERS,SERVSIZE,LSERVER DSPOPT X'00' DATA SPACE OPTIONSNSERVS 1000 NUMBER OF SERVERSNUSERS 2000 NUMBER OF USERSSERVSIZE 100000 MAXIMUM SIZE OF THIS SERVERLSERVER 87720 SERVER SIZE REQUIREMENT MONITOR DATASPACE03.337 DEC 03 19.13.37 PAGE 1NAME DATASPACE TYPE 4K PAGES PAGE HWM EXTRA DATASPACES-------- ------------------- ---------- ---------- ----------------CCASERVR DATASPACE 48829 48826 NAME READS WRITES PAGES READ PAGES WRITN SLOWRD SLOWWR PAGEF-------- ---------- ---------- ----------- ----------- ------ ------ ------CCASERVR 2001 3001 42854 64270 0 0 0
Use the following table to clarify what the values represent.
Note: these statistics are interpreted differently when the dataspace is CCATEMP (see the November 2003 issue of CCAPRINT for details)
In Summary As I mentioned in last month’s article, most organizations today have added considerable resources in real memory and expanded storage, not available just a few years ago. Allocating CCASERVR in memory provides yet another way to achieve a return on that investment by effectively using these new resources to improve Model 204 performance. However, as you begin your experimentation with dataspaces, you should first allocate CCATEMP in a dataspace. Then, if sufficient real storage is available and you are looking for additional performance gains, CCASERVR in a dataspace should be considered.
Coming Attractions In the next issue of CCAPRINT I will discuss CCAAPSY in memory.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
Contact CCA Webmaster Copyright 2008
