Creating server data sets (CCASERVR)

Overview

The CCASERVR file provides temporary space for storage of user work tables when the user has been moved (swapped) out of the server.

The system manager can enable server swapping simply by setting the NSERVS parameter to a value less than the value of NUSERS. Efficient use of swapping, however, requires careful attention to sizing and device-dependent considerations.

This page describes server swapping; discusses server sizing, disk storage requirements, and device dependencies; and explains how to allocate server data sets and implement swapping.

Server swapping and the CCASERVR file

Server swapping is a shared access method that the Model 204 ONLINE configuration can use to reduce server-area main-memory requirements. When a user is temporarily idle, Model 204 copies that user's tables and server data into a CCASERVR file. The server area is then freed to process another user.

Shared servers are divided into different sizes. An internal server pushdown list automatically assigns a user the smallest size that satisfies processing requirements. The LSERVPD parameter controls the size of the pushdown list.

The system manager can create as many as 101 server data sets in any operating environment. This can improve performance by spreading I/O activity across several disk devices. Naming and sizing rules for multiple server data sets are described in detail in Requirements for server swapping.

CCASERVR in Storage feature

This feature is for sites for which one of the following is true:

• Run z/OS in 64-bit mode and have real storage larger than 2-gigabytes
• Run z/OS in 31-bit mode and have enough expanded storage to support dataspaces with no excessive paging. A dataspace is an address space in z/OS with none of the control structures for tasks; it is simply data.

Other operating system configurations will begin excessive paging, and serious performance degradation of the entire system is likely to occur.

If you have enough real storage on your system, you can place either or both CCATEMP file and CCASERVR file in storage. The benefit to you of activating the CCASERVR in Storage feature depends on how much latent wait time is spent by your jobs waiting for the CCASERVR file I/O to complete.

• Users may server swap to CCASERVR file in-memory instead of to disk data set CCASERVR.
• There is no CYLINDER size restriction on SERVSIZE, which is limited only by available memory.
• An additional benefit is that relief is provided on I/O subsystems. Because there is less contention, channels and disks are free to perform other services and jobs run faster.
• The APSYPAGE parameter may compliment the CCASERVR in Storage feature.

System programmers consideration

To use the CCASERVR in Storage feature, be aware that the maximum number of data- or hiperspaces and the total cumulative size of data- or hiperspaces for a given job may be controlled by the SMF IEFUSI exit.

In this exit, the parameter description shows that subwords 2 and 3 of the word 7 parameter are the keys, where:

• Word 7 subword 2 controls the maximum cumulative data- or hiperspace size
• Word 7 subword 3 controls the maximum number of data- or hiperspaces that a job may allocate

Check the IBM-supplied settings and change them, if necessary.

Information regarding this exit routine is found in the z/OS Installation Exits Document Number SC28-1753.

Tracking dataspaces and hiperspaces

See the MONITOR DATASPACE command.

Activating the CCASERVR in Storage feature for a job

To activate the CCASERVR in Storage feature, comment out the CCASERV DD statements in a job. Model 204 will allocate the correct amount of storage based on the SERVSIZE and NSERVS parameters.

Sizing and storage considerations

Preparation for implementing server swapping involves calculating appropriate values for:

• SERVSIZE parameter, which determines the largest server in the input stream
• Disk storage requirements, given the chosen value of SERVSIZE and the device types available at your installation

For detailed instructions for estimating SERVSIZE, see Sizing user server areas. This section explains sizing and storage calculations that have to do with the physical devices in use at your installation.

Physical devices and server size

The size of each server is likely to be limited by the physical device used for swapping.

When an FBA device is used, the server size is limited by the amount of virtual memory available to Model 204. All the servers defined for the run must fit, along with many other blocks of storage, in virtual memory.

When a CKD device is used, the server size is limited by the device's cylinder size, as shown in the "Server swapping constants for CKD devices" table:

Server swapping constants for CKD devices

Device type	Device constant	Tracks per cylinder	Maximum server size
3380	47476	15	712140
3390	56664	15	849960
9345	46456	15	696840

Calculating CKD disk storage requirements

Use the "Server swapping constants for CKD devices" table, above, to make the following calculation for CKD disk storage:

Tracks-per-server = SERVSIZE / Device constant (rounded up) Servers-per-cyl = Tracks-per-cyl / Tracks-per-server (rounded down) Cylinders = NUSERS / Servers-per-cyl (rounded up) Total Tracks required = Cylinders * Tracks-per-cyl

Where:

• cyl represents cylinder.
• Device constant is taken from the "Server swapping constants for CKD devices" table for the appropriate device type.
• Tracks-per-cyl is taken from "Server swapping constants for CKD devices."

Example 2 in Disk storage calculation examples shows a CKD storage calculation.

Calculating FBA storage requirements

To calculate storage requirements for FBA devices, use the following formulas.

For FBA 3370 devices:

n = SERVSIZE/31744 (rounded up) Blocks per user = n * 62 FBA Blocks = NUSERS * Blocks per user

For FBA 9335 devices:

n = SERVSIZE / 36352 (rounded up) Blocks per user = n * 71 FBA Blocks=NUSERS * Blocks per user

For FBA 9332 devices:

n = SERVSIZE / 37376 (rounded up) Blocks per user = n * 73 FBA Blocks = NUSERS * Blocks per user

Disk storage calculation examples

1. The device is a CKD type (3380). The device constant from the "Server swapping constants for CKD devices" table is 47476, and there are 15 tracks per cylinder. SERVSIZE is 110000, and NUSERS is 9. The computation is:
2. The device is an FBA type (3370). SERVSIZE is 110000, and NUSERS is 9. The computation is:

   n = 110000 / 31744 = 3.46 (round to 4) Blocks per user = 4 * 62 = 248 FBA Blocks = 9 * 248 = 2232

Requirements for server swapping

Parameters

To implement server swapping:

• Set the number of servers (NSERVS) to a value less than the number of users (NUSERS).

  If NSERVS is equal to NUSERS, or is allowed to default to the value of NUSERS, server swapping is not initiated.

• Set the value of the SERVSIZE parameter specified for the largest server in the CCAIN input stream to be at least as large as the aggregate table size for the largest user. To calculate the SERVSIZE parameter, refer to the discussion of server areas.

Multiple server data sets

The system manager can specify up to 101 server data sets in any operating environment.

At z/OS and z/VM sites, server data set file names are CCASERVR, CCASERV0 through CCASERV9, and CCASRV10 through CCASRV99. At z/VSE sites, the file names are CCASRVR, CCASRV0 through CCASRV9, and CCASV10 through CCASV99.

The DD statements (or CMS FILEDEFs) are scanned first for CCASERVR, then for CCASERV0, CCASERV1, and so on. If a ddname is not found, then the system assumes that there are no more server data sets. For example, if there is no CCASERV4, Model 204 does not use CCASERV5, even if there is a DD statement for it.

Model 204 opens the data sets in consecutive order and makes allocations to users in round-robin fashion. As data sets fill up, they are dropped from the rotation.

Use multiple server data sets to spread the I/O activity across several disk devices. All the devices must be the same type (all FBA or all identical CKD devices).

Server data sets on CKD devices

If the server data sets are on CKD devices, they must begin on cylinder boundaries. Allocate each data set with contiguous space. The value of the SERVSIZE parameter is limited to the cylinder capacity of the device containing the CCASERVR data set. A server is not allowed to span a cylinder boundary for performance reasons: each server read or write requires at most one seek.

ECKD channel program support

Model 204 executes ECKD channel programs for CCATEMP, CCAGRP, CCASYS, and CCASERVR on ECKD capable devices, whether the devices are connected to ESCON or parallel channels. All models of IBM 3990 Storage Control, the IBM 3880 Model 23 Storage Control, and all models of the IBM 9340 Direct Access Storage Subsystem support ECKD channel programs. This improves performance, particularly if you are using ESCON channels and/or IOS branch entry (XMEMOPT=2) under z/OS.

Under both z/OS and z/VSE, Model 204 executes ECKD channel programs for CCASERVR data sets on ECKD capable devices.

Under z/OS, I/O to user database files, CCATEMP, CCAGRP, and CCASYS is also done using ECKD channel programs.

Note: Under z/OS, VIO support is not available for use with EXCPVR or IOSB. Do not use 9345 DASD with EXCPVR because of the potential for poor performance on writes.

Under z/VSE, CKD channel programs are used to perform I/O to user database files, CCATEMP, CCAGRP, and CCASYS. I/O performance is not affected, however, because Model 204 uses a "well-formed" CKD channel program for these I/O activities. The z/VSE I/O supervisor efficiently converts the channel program to an ECKD channel program for ECKD capable devices.

Using cache fast write

If you have cached DASD controllers (such as IBM 3990 models 3 and 6) you can use the CACHE parameter to allow CCASERVR data to be written directly to a controller's cache.

Allocation and job control

z/OS

z/OS JCL must contain at least one DD statement for CCASERVR. You can specify a disposition of either SHR or OLD. SHR is recommended for the ONLINE configuration.

z/VSE

In a z/VSE environment, prior to executing the ONLINE configuration, you must initialize one or more server data sets using the ALLOCATE utility. For example:

// JOB ALLOCSRV ALLOCATE MODEL 204 SERVER DATASET // DLBL M204LIB,'M204.PROD.LIBRARY' // EXTENT SYSnnn,... // LIBDEF PHASE.SEARCH=M204LIB.V210 // DLBL CCASRVR,'MODEL204.SERVER.DATASET.1' // EXTENT SYSnnn,balance of extent information // ASSGN SYSnnn,X'cuu' // EXEC ALLOCATE ALLOCATE FILE (CCASRVR) /* /&

Label information must be inserted into the ONLINE job stream.

• For FBA devices:

// DLBL CCASRVR,'MODEL204.SERVER.DATASET.1',,DA // EXTENT SYS021,SYSWK1,,,9000,1736 // DLBL CCASRV0,'MODEL204.SERVER.DATASET.2',,DA // EXTENT SYS022,SYSWK2,,,15032,496

• For CKD devices:

// DLBL CCASRVR,'MODEL204.SERVER.DATASET.1',,DA // EXTENT SYS021,SYSWK1,,,1500,xx

where xx is a value from the "Tracks per cylinder" column in the "Server swapping constants for CKD devices" table above in Physical devices and server size.

FTBL and above the bar storage

FTBL can reside in 64-bit storage (above the bar) when Model 204 runs on z/OS or z/VM and storage above the bar is available.

You can allocate designated server tables for each user in storage above the bar that will not be subject to server swapping. This feature enables you to divide the server storage into two parts: swappable and non-swappable. This makes the swappable part of the server storage smaller and faster to swap.

Parameters

The SERVNSSZ and SERVNSA parameters control non-swappable server areas.

• SERVNSSZ (server non-swappable size) is the amount of space in bytes required for the above the bar server tables per user. This is a user 0 parameter applicable to all users. The total amount of storage allocated for non-swappable server parts equals SERVNSSZ rounded to 4K and multiplied by NUSERS.

  When sizing SERVNSSZ, use the largest FTBL sizes that might be needed.

• SERVNSA (server non-swappable areas) indicates the tables that you want to be above the bar. At this time, only FTBL may be selected and its appropriate setting is x'02000000'.

Description

The non-swappable server part may be used with server swapping done in storage or on disk. It may also be used when there is no server swapping (NUSERS=NSERVS) to make servers below the bar smaller by using the non-swappable server part above the bar and saving storage below the bar.

To obtain below-the-bar storage savings when the non-swappable server part is used, decrease the value of the SERVSIZE parameter by the LFTBL value used in calculating the server size.

Note: When FTBL is placed in the non-swappable server part above the bar, the UTABLE command decreasing FTBL size will not free any storage in the regular server below the bar.

Usage notes

You will need to ensure that your user-written and third-party $functions can work with non-swappable server tables in 64-bit storage above the bar.

Messages

The following messages are associated with FTBL above the bar storage:

• M204.2916: SERVNSSZ REQUIRES AT LEAST ONE AREA TO BE SET IN SERVNSA
• M204.2920: Non zero SERVNSSZ is required
• M204.2921: Non swappable server areas are not supported in VSE
• M204.2922: SERVNSA bit setting is not valid
• M204.2923: Space required for non swappable server area is larger than SERVNSSZ

  M204.2923 is issued when the space problem occurs during initialization. M204.2923 sets the return code to 80, appears in the job log, and results in the Online being immediately terminated.

• M204.2932:Space required for non swappable server area is larger than SERVNSSZ

  M204.2932 is issued when the space problem is detected after initialization is complete, most likely during UTABLE command processing. It does not appear in the job log and does not result in the Online being terminated.