ECBRM to limit z/TPF File System INODE usages

The recovery log throttling APAR, PJ46026, helps control the recovery log resource, which is similar to system blocks (SWBs, ECBs, etc). The recovery log (#RLOGxx records) are processor unique and are used in the course of some processing and returned to the pool of available resources when that processing completes. Typically, when these types of system resources run low, letting normal processing continue results in these types of resources to be returned to the system.

#INODE records don't fit that model because they are not necessarily released during the normal course of processing. Applications or the operator would have to explicitly delete files in order to make #INODE records available again. Our concern is adding something like this to an automatic resource check like LODIC would result in the entire complex being stuck in a low-resource state, and the only way out would be through operator intervention. As a result, IBM does not consider the #INODE record to be a good fit for the model used in APAR PJ46206 with the recovery log.

As stated in a previous reply, based on resources and priorities, IBM does not intend to implement this requirement (ECBRM to limit z/TPF #INODE use) in the foreseeable future.
Note that we still recommend the following:
1) Use the DIRSIZEMAX to limit the maximum number of files that can be created in a directory.
2) Consider increasing the number of #INODE allocated in your system. With the increased use of common deployment files (DFDL schemas, service descriptors, etc.), the Java runtime environment, and Java programs, you may want to consider increasing your systems #INODE capacity to support those items.

This is from PJ46026:
“Due to the importance of the recovery log, the 00C117 catastrophic system error will occur if the recovery log does not have any available space for normal processing. This new support adds
enhancements to existing system resource monitors to collect and display recovery log usage at both system-level and ECB-level. A new resource check in the LODIC resource priority classes and input list shutdown monitor can be used to throttle certain workload based on current recovery log usage.”

While we understand PJ46026 is about the integrity of Recovery Log, we wonder if a similar approach can be considered to control or monitor z/TPF File System INODE usage.

FILE0005W will occur and disrupt systems and applications when the file system tries to create new files when it runs out of available #INODE and #FLOCK fixed file records. Can a new support be added to existing system resource monitors to check #INODE usage at either system-level or ECB-level? A new resource check in the LODIC resource monitor could be used to kick out a run-away application that creates excessive file system files leading to the depletion of #NODE blocks.

Thanks for the support.

Based on resources and priorities, IBM does not intend to implement this requirement in the foreseeable future.

The DIRSIZEMAX file attribute can be used to limit the maximum number of files that can be created in a directory.
The errno return value when the dir size max has been exceeded is EDQUOT (disk quota exceeded).

Console showing dir size max attribute usage......
zfile attr ?
CSMP0097I 09.05.04 CPU-B SS-BSS SSU-HPN IS-01
FILE0002I 09.05.04 START OF ERROR DISPLAY FROM attr ?
Usage: attr -s file name=value
attr -a file
attr -r file name
attr -d file name
END OF DISPLAY+
zfile attr -s /test1 'dir size max=3'
CSMP0097I 09.05.45 CPU-B SS-BSS SSU-HPN IS-01
FILE0001I 09.05.45 START OF DISPLAY FROM attr -s /test1 'dir size max=3'
dir size max=3 set
END OF DISPLAY+
zfile attr -a /test1
CSMP0097I 09.05.53 CPU-B SS-BSS SSU-HPN IS-01
FILE0001I 09.05.53 START OF DISPLAY FROM attr -a /test1
ddname=
servicelevel=0
data record id=0000
object record id=0000
index record id=0000
directory record id=0000
shadow collections=0
file size max=2147483647
dir size max=3 _
backup collection=1
write restrict=
search restrict=
END OF DISPLAY+
zfile echo hello > /test1/f1
CSMP0097I 09.06.18 CPU-B SS-BSS SSU-HPN IS-01
FILE0003I 09.06.18 echo hello ... COMPLETED SUCCESSFULLY. NO OUTPUT TO DISPLAY+
zfile echo hello > /test1/f2
CSMP0097I 09.06.21 CPU-B SS-BSS SSU-HPN IS-01
FILE0002I 09.06.21 START OF ERROR DISPLAY FROM echo hello . /test1/f2
cannot create /test1/f2: disk quota exceeded <-- note the "." and ".." dirs count towards the total (So ".", ".." and "f1" filled the dir to the max of 3 causing the create of f2 to fail)
END OF DISPLAY+

We appreciate the explanation. We are actually concerned about applications only, not systems such as Java or ZFILE etc.. We've had a case where an application created thousands of files in /temp and filled up inodes. Is there a chance systems s/w get excluded in implementing ECBRM limit of INODEs? And from my testing, DIRSIZEMAX is not inherited by child directories. Could you also confirm that?
Thanks for the support.

We use ECB Resource Monitor, and 1st FILE limit is at 400K. We only have 15K inode blocks total.

We use ECB Resource Monitor to monitor the number of record files per ECB. But it's not really applicable to INODE blocks, as we have currently 15K allocated in total. Are you suggesting we increase the allocation to millions?

This will not stop an application that has spawned off other child ECBs or processes to do the work.
When we allocate/dispense a #INODE record we typically do two record files (we file the #INODE record and the dispensing #IZERO record).
The current ECB resource monitor will allow you to monitor the number of record files per ECB.
Are you using this currently to monitor ECBs ?