Model 204 SPCORE: What It Is and How You Set It
By James Damon
What is SPCORE?
SPCORE is a CCAIN parameter that specifies the minimum amount of virtual storage or spare core that Model 204 should leave unallocated following initialization. You set SPCORE based on your experience with previous runs. Spare core represents storage available for dynamic allocations of various control blocks, buffers, and tables based on the requirements of commands issued, and User Language requests evaluated as the run progresses.
The SPCORE parameter is not the only factor that determines the amount of available spare core. Usually, much more spare core is actually available than is indicated by the results of a VIEW SPCORE command.
For example, under OS/390 and z/OS, if REGION=512M is specified on the job card and the result displayed by a VIEW STORINIT command shows 180,000,000, then the amount of spare core actually available to Model 204 is roughly:
512,000,000 (REGION parameter)
- 180,000,000 (VIEW STORINIT)
- 2,800,000 (average ONLINE load module size in bytes)
329,200,000 bytes available as spare core
In other words, spare core is effectively whatever virtual storage remains available to the address space or virtual machine following Model 204 initialization. It may be considerably larger than the value specified by the SPCORE setting. If REGION=0M is specified on the job card, then the calculation would be:
2,147,483,647 (REGION parameter = 231 -1) - 180,000,000 (VIEW STORINIT) - 2,800,000 (average ONLINE load module size in bytes) 1,964,683,647 bytes available as spare core
2,147,483,647 (REGION parameter = 231 -1)
1,964,683,647 bytes available as spare core
Note: This storage is only available to Model 204; it has not been allocated, but is available if needed. Model 204 allocates storage, based on the operating system, using one of the following macros:
Setting SPCORE
Setting SPCORE to 500,000 is sufficient in virtually all production Onlines provided that:
This is not because 500,000 is all that is required in most Onlines. Rather, it is because the true amount of spare core available is effectively determined by operating system parameters and not by the SPCORE setting. The following VIEW command illustrates this point:
VIEW STORINIT, STORCUR, STORMAX, SPCORE STORINIT 26645632 STORAGE ACQUIRED DURING INITIALIZATION STORCUR 40280 CURRENT DYNAMIC STORAGE ALLOCATION STORMAX 1442064 DYNAMIC STORAGE HIGH WATER MARK SPCORE 5000 SPARE CORE RESERVED
VIEW STORINIT, STORCUR, STORMAX, SPCORE
STORINIT 26645632 STORAGE ACQUIRED DURING INITIALIZATION
STORCUR 40280 CURRENT DYNAMIC STORAGE ALLOCATION
STORMAX 1442064 DYNAMIC STORAGE HIGH WATER MARK
SPCORE 5000 SPARE CORE RESERVED
In this example, the high water mark of spare core used so far is 1,442,064 bytes, far above the value set by the SPCORE parameter. This is possible because this OS/390 job had REGION=0M specified on the job card, a setting which provides a nearly unlimited amount of available spare core: two gigabytes, minus STORINIT, minus 2.8M.
Setting constraints for SPCORE
If at your site you make heavy use of the Resident Request feature and set RESSIZE=20000000, typically you will see values of STORCUR and STORMAX well above ten megabytes and approaching twenty megabytes depending on:
However, values observed for STORMAX and STORCUR in these cases should not be used to determine a setting for SPCORE in subsequent runs
You cannot set SPCORE greater than about 4 - 5 megabytes due to the way SPCORE bytes are reserved. During initialization SPCORE bytes of storage must be available both above and below-the-line or initialization fails. Most sites and all operating systems generally have no more than 4 - 5 megabytes available below-the-line after accounting for the size of the Model 204 load module, which is why this constraint of 4 - 5 megabytes applies for SPCORE.
In summary
The actual setting of SPCORE is almost irrelevant. The true availability of spare core is determined largely by REGION size, machine size, or GETVIS size. The best way to ensure that no user requests are cancelled is to ensure that either no limits or very high limits are placed on the amount of virtual storage available to Model 204. Otherwise, users may have requests cancelled and receive the following message:
M204.0455: INSUFFICIENT SPCORE
System 1032 Query Efficiency: Part 4
By Kevin Fuller Updated by: Tym Stegner
Other commands that use keys
In Part 2 we saw how the FIND command processes queries by reading the key tables. The other commands that read the key tables do so in a similar fashion.
Commands that always use keys
The DFIND command starts processing queries exactly like the FIND command. The same blocks in the same key tables are read for a FIND command or a DFIND command. The process diverges when handling the deleted records. Instead of stripping out deleted records via an IMPLIES operation, only deleted records are included by using a logical AND.
The MAP command and joined PRINT command, which relies on MAP logic, also use the key tables to locate target records. Several approaches are used based on the data selected and the size of the source and target datasets. The target keys are read either as a series of top-down reads or with a scan-across read of the lower-level key blocks. In some cases, the MAP command is processed like a FIND command.
In other cases, the MAP command scans the lower-level key blocks. It decides for each value whether it should be included in the results.
The MAP command respects existing consider sets established in the target dataset. Like the FIND command, the MAP command processing is based on the entire key table. Then it strips out the records that are not in the consider set or that are deleted, at the end of processing the command.
The other command that always reads key tables is the VALUES command. The VALUES command does a scan-across read of the lower-level key blocks. Since the VALUES command does not affect the current selection set at all, but simply reports on the value distribution of the records already selected, it does not evaluate deleted records or consider sets. The current selection set determines whether a given record should be reported. If all the records in the dataset are selected, the VALUES command completes a full scan of the lower-level key blocks.
Figure 1: Full scan-across read of lower-level key blocks by VALUES command after FIND ALL
However, the VALUES command does not do unnecessary work. If all the values in the current selection set are near the beginning of the key table, then a full scan of the lower-level key blocks is not necessary. The VALUES command keeps track of how many records it has reported on. Since System 1032 always knows how many records are in the current selection set, as soon as the VALUES command reports on that number of records, it stops reading.
Figure 2: Partial scan-across from VALUES after FIND LAST-NAME beg "Ful'
In Figure 2, the FIND LAST_NAME beg "Ful" command is given to create the selection set. A top-down read of the key tables locates where "Ful" starts. The VALUES command starts reading the lower-level key blocks from the first-lower-level key block. The shaded region shows the blocks read by the VALUES command. (Figure 2 assumes that all values that start with "Ful" are contained in a single key block.) The block that contains the "Ful" values is read twice, as shown by the dark shading, but then the VALUES command stops reading because it knows it's found all the records in the current selection set.
Commands that sometimes use keys
The other processing that sometimes uses key tables are the sorting operations. The SORT, PRINT...BY, and SEARCH MIN/MAX commands sometimes access the key tables to perform their assigned tasks. System 1032 builds the sorted list by scanning the lower-level key blocks if:
Like the VALUES command, the lower-level key blocks are scanned and each record list is examined to determine if these records are in the current selection set. If so, those $IDs are added to the sorted selection set first. As the $IDs are located in the key table, their order is preserved, resulting in a sorted selection set.
Update Commands
The ADD, CHANGE, and APPEND commands all refer to the key tables. The ADD and APPEND commands must read the keys to locate the proper existing record list to insert the new $ID, or to locate the proper place to insert the new value/record list, if the value in the new record doesn't already exist. The CHANGE command, first selects the old value and removes the $ID from the current record list. Then the CHANGE command processes like the ADD and APPEND commands.
The details about updating key tables are at least as expansive. Summarily, these updates can result in reading the keys from the bottom upwards.
In conclusion
Part 4 discussed the other PL1032 commands that use the key blocks the same way that the FIND command uses them. In Part 5, we will discuss how you can use all this information about the key blocks and how they are processed by various PL1032 commands to enhance your applications.
Links to previous articles in this series
In Part 1 in the June 2001 CCAprint, We introduced key table internals:
In Part 2 in the July 2001 edition, We described how key tables work:
In Part 3 in the August 2001 edition, We discussed the "FIND Command Internal Processing":
Copyright © 2003 Computer Corporation of America. All right reserved. Published in the United States of America.
500 Old Connecticut Path, Framingham, MA 01701 Contact CCA Webmaster Copyright 2005
