Using the system scratch file (CCATEMP): Difference between revisions

Latest revision as of 18:53, 8 June 2017

Overview

CCATEMP is a required temporary or permanent data set that is used as a system scratch file for a single job on one CPU.

Up to 11 CCATEMP data sets can be used in all operating system environments to accommodate a corresponding number of jobs.

In the course of a Model 204 run, CCATEMP pages are initialized and used as work areas to:

Store temporary procedures and edit procedures
Hold record set lists and the results of FIND statements
Store sorted record sets
Sort FIND and FOR EACH RECORD values
Store temporary groups, backpage images, screen, menu and image definitions, temporary group definitions, group field tables, and application subsystem precompiled procedures
Store back out and constraint logs for transaction back out files
Resolve IS LIKE pattern matching syntax

This page provides guidelines for CCATEMP space allocation, explains the role of CCATEMP in recovery, and summarizes job control information for z/OS and z/VSE environments.

Sizing CCATEMP

The space required by CCATEMP depends on the complexity of the retrievals executed. Do not increase the size of CCATEMP unless you need to for sort work or temporary tables. Overallocating CCATEMP wastes memory and disk space.

The maximum size of CCATEMP is 16,777,215 pages.

Model 204 functions are now divided into those that require 2-byte page numbers and those that can use 3-byte page numbers. If a function can use 3-byte page numbers, then its pages are allocated above the 64K line. If all such pages are already allocated, then it is assigned a 2-byte page number if one is available.

If a function requires 2-byte page numbers, then its pages are allocated below the 64K line. It is, therefore, possible to fill CCATEMP even if there are unused pages above the 64K line.

During Model 204 termination, a message is issued that summarizes CCATEMP usage:

CCATEMP PAGES USED = m OUT OF n

Many commonly used Model 204 features and facilities affect the size of CCATEMP. When allocating space for CCATEMP, take note of the special considerations described in the following sections.

Transaction back out in recovery

When the Transaction Back Out facility (TBO) is used in recovery, extra CCATEMP space is needed for reapplication of updates from the recovery data set. Use the following formula:

Pages of additional CCATEMP storage = 1 page/transactions * maximum number of concurrent transactions.

Note: Large transactions may require more than 1 page.

FLOD exits

Additional CCATEMP space is required when the FLOD exit (FLODXT#) program is run.

File groups

Open Model 204 file groups actively use CCATEMP and release used pages when the group is closed. If your run uses file groups, take note of the following requirements:

At least one page is required for each user who creates a temporary file group definition or opens a permanent group.
One scratch page is required for each permanent or temporary file group that has a field name referenced by a User Language request or IFAM call. The file group must have a BLDGFT=YES parameter setting.
For either a batch or an ONLINE run that uses file groups, a scratch file of at least 25 pages per user is suggested. Otherwise, 20 pages are generally sufficient.
An error message citing a file full condition for CCATEMP signifies the necessity of increasing the space allocation.

Ad hoc file groups do not build group field tables on disk.

Subsystem Management and precompiled requests

When the Subsystem Management facility (SUBSYSMGMT) is installed, CCATEMP requires additional space to accommodate the compiler tables for precompiled procedures. The data stored in CCATEMP consists of a header section and the contents of VTBL, QTBL, STBL, and NTBL. For example:

94 + (32 * VTBL HWM) + (12 * NTBL HWM) + (STBL HWM) + NFILES + NRMTFILE + (16 * QTBL HWM) + (ad hoc group FTBL space) + ((30 + (7 + NRMTLOCS)/8) * #groups) + (8 * (#fields referenced in group)) + (the sum of the length of the names of all the fields referenced in the group) + #screens + #images + (unavailable-file space) + (XVAR space)

Where:

HWM refers to the high-water mark found in the audit trail's since-last compilation statistic for the indicated table.
ad hoc group FTBL space depends on whether there are ad hoc scattered groups (Parallel Query Option/204) included. If no ad hoc groups are scattered, ad hoc group FTBL space is:
62 * (#ad hoc groups)

If some ad hoc groups are scattered, ad hoc group FTBL space is:

(62 + (#open files in ad hoc groups)) * (#ad hoc groups)
unavailable-file space is the following quantity, not knowable in advance, which you need to estimate (Parallel Query Option/204 only):
(4 + (#unavailable group files)) * (#groups with unavailable members)

XVAR space is required for these SOUL request elements: found sets, lists, FOR statements with a WHERE clause. The number of bytes per element depends on the file or group context, as follows:

Transaction context	Bytes required per element
Single file	8
Ad hoc or permanent group	8 * (#files in group)
Temporary group	4 + (8 * (#files in group))

The number of additional CCATEMP pages required is:

The result of the above calculation / (PAGESZ - 40)

CCATEMP in system recovery

Shared DASD

CCATEMP cannot be shared between jobs on a single CPU or placed on shared direct access devices (DASD) that might be accessed simultaneously by two CPUs. A shared DASD enqueue list protects CCATEMP in shared DASD situations. Because CCATEMP is opened as part of Model 204 initialization, you cannot use the ENQCTL command to modify the enqueue list.

After a system crash

In the event of a system crash, the following considerations apply:

If CCATEMP is defined as a permanent file and recovery is not run, you must reinitialize or overwrite CCATEMP from outside the Model 204 environment.
If CCATEMP is defined as a temporary file, overwrite it in a prior job step using IEBGENER (z/OS), DITTO (z/VSE), or the CMS FORMAT command to avoid the possibility of receiving an old scratch file from another job.
If recovery is run after a system crash, Model 204 automatically performs the required maintenance on CCATEMP.

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 CCATEMP data to be written directly to a controller's cache.

CCATEMP statistics

Statistics are kept for every file opened during the run, including CCATEMP. The number of CCATEMP pages used in a run appears in the journal (TFMX) at the end of the run.

The high-water mark of CCATEMP usage and the total number of pages allocated to CCATEMP is reported on the audit trail in the following statement:

CCATEMP PAGES USED=n OUT OF m

Handling 64-bit statistics

To support very long running Model 204 regions, Rocket Software has modified the capacity of statistical counters by increasing the size of some statistics and also exploiting 64-bit processing where appropriate. For any in-house or third-party support applications that process statistical counters you will need to review the statistics generated.

As some of the statistics fields are now double-words, check Using system statistics for the new layout of the System, Final and Partial statistics. Also, additional Disk Buffer Monitor, MP/204, and File statistics have been updated.

Look at your in-house or third-party support applications to see if you need to make changes because of the increased length of some of the statistics and make any changes necessary to your applications, then reassemble with this new release.

If your in-house or third party support applications don't reference any of these double word statistics, then you only need to reassemble your program with the new offsets documented in "Using system statistics."

CCATEMP statistics at termination

The M204:2622 message is printed twice at termination to report the high-water mark of the number of pages used in both the small model area and the expansion area.

M204.2622: HWM CCATEMP PAGES USED IN SMALL MODEL AREA = nnnnnn, MAX AVAILABLE = 65536 M204.2622: HWM CCATEMP PAGES USED IN EXPANSION AREA = nnnnnn, MAX AVAILABLE = nnnnnn

The two CCATEMP statistics, TEMPHIE and TEMPHIS, report the high-water mark of pages used in the CCATEMP expansion area and in the small model page pool, respectively.

z/OS considerations

In a z/OS environment:

The JCL must contain a DD statement for each CCATEMP data set.
If you specify more than one CCATEMP data set for a run, you must call the first data set CCATEMP, and the unit type must be compatible with the installation's page size:
//CCATEMP DD UNIT=3380,DISP=(NEW,DELETE),SPACE=(TRK,80)
You must name subsequent CCATEMP data sets CCATMP0, CCATMP1 through CCATMP9. The data sets are opened in numerical order during initialization. Any break in the order ends the open process. Only those data sets successfully opened are used as part of CCATEMP for the run.

Storing record set bit maps

Record set bit maps are stored in CCATEMP pages whether bit X'40' of SYSOPT2 is set or not. The X'40' setting will limit the CCATEMP page range that can hold these record set bit maps.

When the SYSOPT2 setting does not include X'40', then at any given time the bit maps corresponding to all users holding found sets of any kind must fit into CCATEMP pages in the page number range X'0000'-X'FFFF' (that is, page number 0-65,535, the small model page pool), no matter how many pages have been allocated to CCATEMP.
When the SYSOPT2 setting does include X'40', the off-restriction is removed and user found sets can be placed anywhere within CCATEMP. This includes both the small model page pool (pages 0-65,535) and the CCATEMP expansion area (page numbers 65,536 to 16,777,215), allowing for the possibility of a greater number of concurrent found sets being held by all users.

CCATEMP in Storage feature

This feature is for sites where either of these is true:

Have z/OS in 64-bit mode and 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 from activating CCATEMP in Storage depends on how much latent wait time is spent by your jobs waiting for the CCATEMP file to complete.

There is no CYLINDER size restriction on SERVSIZE, which is limited only by available memory.
The CCATEMP file initialization is not required with CCATEMP file in Storage feature. This significantly reduces the time required for Model 204 initialization when a large CCATEMP file is required.
Less CPU is consumed per logical CCATEMP I/O. A CCATEMP I/O, with this feature, is logical, since data is moved in-memory and not to or from an external device.
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.

Activating the CCATEMP in Storage feature for a job

To activate the CCATEMP in Storage feature in a job, you must set a new parameter in the User 0 CCAIN stream. This parameter is TEMPPAGE, the number of CCATEMP pages to allocate. You may comment out or remove the CCATEMP DD record(s), but this is not a requirement. If the TEMPPAGE parameter is set, the DDs for the CCATEMP file are ignored by Model 204, although not by the operating system.

System programmers consideration

To use the CCATEMP in Storage feature, be aware that the maximum number of data- or hyperspaces and the total cumulative size of data- or hyperspaces 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 hyperspace size.
Word 7 subword 3 controls the maximum number of data- or hyperspaces that a job may allocate.

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

Information regarding this exit routine is found in OS/390 z/OS Installation Exits, document number SC28-1753.

Tracking dataspaces and hyperspaces

See the MONITOR DATASPACE command documentation.

z/VSE and CCATEMP considerations

Allocating CCATEMP

In a z/VSE environment, CCATEMP must be allocated using the ALLOCATE utility before an ONLINE, BATCH204, or an IFAM1 program can be executed.

The Job Control Language statements required for the execution of the ALLOCATE program are:

// JOB ALLOCTMP ALLOCATE MODEL 204 SCRATCH FILE // DLBL M204LIB,'M204.PROD.LIBRARY' // EXTENT ,... // LIBDEF PHASE.SEARCH=M204LIB.V210 // DLBL CCATEMP,'M204.name.CCATEMP',99/365 // EXTENT SYS001,balance of extent information // ASSGN SYS001,X'cuu' // EXEC ALLOCATE,SIZE=AUTO ALLOCATE FILE(CCATEMP) /* /&

where the following statement applies to Model 204 z/VSE Version 2.1.0 or later:

// LIBDEF PHASE.SEARCH=M204CL.PROD

Label information

When executing the ONLINE, BATCH204, or user-written IFAM1 program that uses the CCATEMP file, you must provide the following label information in the execution job stream:

// DLBL CCATEMP,'M204.name.CCATEMP',,DA // EXTENT SYSnnn,balance of extent information // ASSGN SYSnnn,X'cuu'