Have you analyzed the file sizes? Do they arrive all at once? How many files are exceptionally large and when they arrive they take up most of the space? I have seen in multiple places I worked about less than 10% of the files make up more than 90% of the storage foot print. So, start with analyzing the data and finding the "inflection point" for when the spool could fill up if these files arrive at once. Once largest files are identified, load them via custom JCLs without sending them to spool at all. Others could still go to spool if you are already set up to process with ARSLOAD started task. You can also talk to your z/OS systems programmers to beef up the spool to max allowed. I have done that in one of the migrations where we used z/OS download via spool to feed a parallel processing non-mainframe system that we were newly building.
Solution sometimes is a mitigation where multiple methods are used and not one is chosen versus the others.
Also, I have seen a lot of times that many files of similar content go into same AG/APP. You need to analyze that as well. If you see clusters of files with very similar naming pattern and content all go into same AG/APP, you can isolate these as well even if they are small files and feed them directly to CMOD with a JCL triggered by arrival of such files. This way, you can reduce number of JCLs you need to set up while bypassing the spool for as many files as you can.
In our business, data drives the process. You must analyze the data and determine best approach with what you find out.
