If users encounter a situation where a very large number of Jobs are running per day through JAMS (i.e. 10's of thousands to 100's of thousands), Users may want to think about how the log files for those Jobs are being stored, as well as the SQL database back-end edition being used, to avoid potential problems from rising.
JAMS Job Log Files:
By default, JAMS stores all Job log files in a default directory that is assigned in the Configuration Settings within the JAMS Client. To see this setting, go to the Configuration shortcut in the JAMS Shortcut Bar and then navigate to the Configuration Tab. The Default Log Location setting can be modified to be any directory available to the JAMS Server.
However, users can have too many files in a directory, as an NTFS file directory will not function properly if it has hundreds of thousands of files in that directory. In this case, it is best to spread out the log files for JAMS Jobs into multiple directories. Users can specify a log location in Folder definitions or Job definitions by going to the Properties of either and accessing the "Properties" tab. Setting the log location at the Folder level will set that location as the default for all Jobs and Setups within that Folder. This can then be overridden at the individual Job level by setting an alternate location in the "Properties" tab.
Even when spreading log files out over multiple directories, keeping them in check may require the use of the JAMSPurgeHistory Job that installs with JAMS. This Job will remove all history records and log files for any items that do not fall within the specified Parameter values when a user runs the Job. The parameters used are as follows:
MINROWS (default value = 1) - The minimum number of history records to keep for each job.
MAXROWS (default value = 30) - The maximum number of history records to keep for each job.
DAYS (default value = 30) - The maximum number of days to keep a history record.
Users can then schedule this JAMSPurgeHistory Job to run on a regular basis, keeping the total number of historical records to the minimum needed.
Note: To increase performance of the JAMSPurgeHistory Job, tables in the JAMS Database may be pruned manually. These tables tend to have the most records, and can cause the job to run longer than you may want. The records should be deleted and not truncated.
HistoryAuditTrail, HistoryElementProperty, HistoryElement, HistoryProperty, HistoryTag, HistoryParam
SQL Server edition:
The next thing users want to look at is the edition of SQL Server that will be used for the JAMS database. If there is not a preexisting database for the JAMS installer to be pointed to, JAMS will install SQL Server 2012 Express Edition. The SQL Server 2012 Express edition will use only a single processor (the lesser of one socket or 4 cores) and has a 10GB database size limit. Other full editions of SQL that users may be running as the JAMS Database should not have any problems as they can have larger database sizes with increased resource allocations.