Spooler Plus Utilities Reference Manual

Introduction to the Spooler Plus Subsystem
Spooler Plus Utilities Reference Manual—522294-002
1-6
Collectors
Index blocks are used to keep track of the units of space allocated to a job. The
current index block for a job is kept in memory during collection so that there is no
overhead as entries are being made. The collector chooses the addresses of the first
allocated unit in the collection file for a job in such a way as to minimize the contention
for the same units by different jobs. It also attempts to keep the units for a job as
contiguous as possible.
The first index block for a job can contain up to 198 entries. Subsequent index blocks
for the job can contain up to 207 entries. When an index block fills, another is
established and two additional disk input-output (I/O) operations will result. Each entry
in an index block can depict from 1 to 512 units of contiguous space. For example, if a
job has 500 units of space allocated to it and all that space is contiguous, only a single
entry in a single index block is required to account for the job’s use of space. This
ability to combine multiple allocations into a single entry minimizes the number of index
entries required and therefore minimizes the number of index blocks required for a job.
When PRINTREAD is requested to start reading at a specific page within a job (for
example, from the Peruse JOB LIST page-num and Spoolcom DEV SKIPTO page-num
commands), the range of pages represented by an entire index block is used to
determine if another index block must be read. The number of additional I/O
operations required for the start of the operation will be, on average, half of the number
of additional index blocks for the job.
The worst-case performance impact of index blocks is no more than .5 percent during
collection. This can occur where the unit size is 1K bytes and every allocated unit is
not contiguous to the previous unit. For jobs containing 500 units or less, there should
be no noticeable impact on performance.
For random page access, the worst case performance impact is an additional I/O per
index block before the read can begin. Reading a job from the beginning, or reading
the job after the selected page has been found, does not involve index blocks.
The large number of entries per index, the tendency toward allocating contiguous units,
and the combining of contiguous allocations combine to greatly reduce the impact of
index blocks on performance because there will generally be no need for extra index
blocks.
As a general rule, unit sizes should be small to enable more efficient use of collector
space. Unless the typical job is much less than 4K bytes, a unit size of 4K is
recommended along with a 4K buffer size. The impact of too small a unit size (jobs
with 50 or more index blocks) is not noticeable during collection and is nonexistent
during delivery. Too-small unit size should be considered as a potential performance
problem only when performance of Peruse JOB LIST or Spoolcom DEV SKIPTO
performance is especially important.
The collector monitors space usage when units are allocated and deallocated. If a
change of .5 percent or greater has occurred since the last usage report, a special
report is sent to the supervisor.
Each collector process handles as many as 1024 simultaneous users. Consider
employing a smaller number of collector processes.