Allocation functions and zFS
However, the product's behavior varies slightly when processing zFS allocations instead of non-zFS data sets. The following table lists Allocation functions that are affected by processing zFS allocation.
Allocation functions affected by processing zFS allocation
Add a secondary allocation quantity
Reduce the secondary allocation to the best fit
Reduce the secondary allocation to the largest extent
Reduce the initial allocation on a volume addition
Add a volume during allocation
Enforce VSAM allocation standards
Space extension takes place in zFS address space (called by the IBM colony).
Specifying a CISIZE other than 4096 causes zFS formatting to fail.
With the exception of the VSAMCNTL function, the previous table shows that the functions that are affected by zFS allocation are those that apply to the data set extensions. All zFS allocation and I/O activity is performed within the zFS-dedicated address space (colony). This address space affects the Allocation product in the following ways:
Instead of appearing in the user address space, Allocation messages appear in the zFS address space and in the operator log.
The following table lists the filtering FLST/RLST parameters that reflect the zFS Started Task, not the user's job.
FLST/RLST parameters in the zFS Started Task
Job, TSO, or STC name
Job account field, where n is 1, 2, or 3
Job start day
Job start time
Type of job STC|TSO|JOB
Programmer name job card field
Procedure step name
IBM RACF group
Value of the RACF user ID on a JOB card
Job step name
Step account field, where n is 1, 2, or 3
For the Allocation product to work with zFS extensions, an administrator must specify dynamic growth for aggregates that become full: the administrator can specify the aggrgrow PARM on the MOUNT command, or can globally specify the aggrgrow option of the IOEFSPRM file.
Also, the definition for the aggregate (that is, the VSAM Linear Data Set) must have secondary allocation specified.