This message appears in the log: 'IEC070I 209-220,NETMSTR,NETMSTR,NMLOG01'.
A '209-220' error occurs when the volume is full.
The NMLOG01 file had a DATA portion full and no secondary extent allocated. Is it ok to define secondary or leave with '0'?
S01LCALC JCL has:
============================================================================
DEFINE CLUSTER (NAME(hlq.NMLOG01) -
MGMTCLAS(DEFAULT) -
STORCLAS(strclass) -
INDEXED -
RECORDS(30000 0) -
============================================================================
Is there any technical restriction for NMLOG01 not having secondary space allocated in S01LCALC or is it ok to define secondary extents?
Secondary space allocation should not be defined for any of the NMLOGxx files.
The Log dataset is a KSDS and is unique in that it is usually allocated without the definition of secondary extents. This is because this file can 'wrap', and if secondary extents were allocated, the End Of file would never be reached. Therefore, it would never need to 'wrap' and could become very large.
There is also the performance consideration to take into account when allocating secondary extents. When the primary amount on the first volume is used up, a secondary amount is allocated on that volume by the end-of-volume (EOV) routine. VSAM acquires space in increments of Control Areas (CAs). Each time a new record does not fit in the allocated space, EOV allocates more space in the secondary space amount. This can be repeated until the volume is out of space or the extent limit is reached. Depending on the type of data set allocation request, a new volume may be used. If small amounts of secondary space allocation are specified, especially for a KSDS data set, there are a large number of I/O operations involved when the secondary allocation takes place, hence performance can become a big issue with KSDS's that have secondary space allocations.
Lastly, this is a Log file, so it is desirable to keep it to a certain size, although big enough to hold the required amount of data as needed. If secondary space allocations are defined, the size of this Log file can grow far beyond the required size, and again, this could have serious performance implications especially in times of frequent I/O to the Log file.
In conclusion, it is not advisable to define secondary extents. The Log allocation JCL must remain with a value of '0' for secondary extents.