This advice applies to all platforms: try to keep the number of files in any one directory down to a reasonable number (ideally no more than a few hundred). If you let the number of files creep up into the thousands, the overhead for performing operations on that directory (such as adding, deleting, or finding a file) grows at an alarming rate. Even worse, it can become impossible to perform Unix wildcard operations because the shell runs out of memory while attempting to enumerate the wildcard list. A large number of print files can also cause severe fragmentation of the file system, which further slows things down.
This situation tends to occur in applications that create unique printfile names and which leave it to the users to delete print files periodically. Whereas under AMOS, with 32MB logical disks, they might have run out of space after accumulating several hundred print files, under Unix with a 20 GB logical disk, they may accumulate tens of thousands of print files and still not begin to notice the disk filling up. (They will notice the system slowing down, but will probably not recognize the cause.)
There are several ways to avoid this problem. The simplest would be to just delete (or archive) the print files on a periodic basis. If you want to leave them on the hard drive for archival purposes, then at least move them to another directory which is not accessed constantly by A-Shell. Better yet, tar all of the print files for the period into one tar file (ideally a compressed one). If you ever need to get one, you can list the contents of the tar files and extract individual files as needed.
Another approach would be to use the COMMAND=SBX: feature in the printer ini files, along with a custom SBX routine, to archive or relocate the print files as they are printed.
Ideally, you would not only keep your print files and related output files in their own directories (outside of the directories holding the permanent data and program files), but you would even put them on a separate file system (or disk partition). That way, you insulate the more important part of the application from the potential dangers of large numbers of output files, such as filling up the file system, excessive fragmentation, etc.
