Bill Rehm, Principal Solution Architect
In Part 1, I told you about basic JD Edwards logging, OMW logging, scheduler jobs, server logs, and package management. That's a lot to manually manage, but there's even more in JD Edwards to keep an eye on.
Enterprise Server General
Directories Under ...\spec
The folder ...\spec\runtimeCache stores the persistent TAM cache files for UBE specs, and the UBEoverride folder serves as a temporary placeholder for overridden specs in a Zip file. Normally, package deployment removes the persistent UBE cache. Full package deployments remove the entire "runtimeCache" folder, and update packages remove caches of those UBE's included in the update package. You can also remove all files in those directories at any time, even when the services are running.
Global Tables and Data Dictionary
Global tables (glbltbl.ddb and .xdb) are part of the local specifications stored under the /pathcode/spec directory. Within these global tables, data item definitions for every EnterpriseOne software table reside. Data Dictionary (dddict and ddtext.ddb and xdb) files, replicated copies of the data dictionary, become populated by a Just in Time install (JITI) from the Master Data Dictionary tables.
Normally these files are purged during normal operations such as package deployments, but sometimes these files need to be manually deleted, allowing them to regenerate, correcting possible corruption and resolving other errors. To remove the files, best practices state to stop JDE services and delete the files. As services restart, the files regenerate automatically.
Operating System Specific
UNIX
Temporary files get created by the JD Edwards UserID in the /var/tmp directory of the UNIX Enterprise server. The creation of temporary files occurs when the EnterpriseOne third-party PDF generation library constructs the PDF for a job. Occasionally, the system fails to clean up these files and they remain on the server consuming disk space. Batch jobs forced to terminate on UNIX/AIX servers using the KILL command leave behind temporary ACR* files when the Adobe libraries reinitialize. These files on the server reside in the /tmp folder, and begin with the name: AcroxxxPID, where xxx is any character and PID is the Process ID of the runbatch process.
iSeries
In the IFS /tmp directory1, there can be many QACXxxxxxx stream files (STMF). These temporary files get created during UBE processing on the iSeries from users submitting UBE's to the server. They usually purge out on their own, but at times, they may remain even after the UBE finishes processing. These files can be deleted, but the caveat includes stopping EnterpriseOne services first, in case the files are in use. It is safe to delete after services have been stopped.
CPP* in the IFS /tmp directory are created on the AS400 by the C compiler. Neither the compiler nor the operating system cleans up these files. Take caution when deleting these files. Make sure no process or compile is occurring on the operating system when deleting.
Windows
One of the reasons why UBE's fail to submit to the server is because the Enterprise server's disk is out of space where the temp directory is located. The temporary directory can be set by environment variables (TEMP/TMP) of the user that starts EnterpriseOne services.
Database Purges
Package Build Spec Tables
When a package is built and deployed, JD Edwards creates a set of spec tables on the database that correlate to the package. Normally during package deletion, those tables are also deleted. It's a good idea to keep an eye on the central objects.
Backup/Work tables
People create backup tables when changing data manually (or they should!), and work tables when they need to do advanced data manipulation outside of JD Edwards. Creators often fail to delete these tables upon completion of the work. Depending on the specific table being backed up, the effect on disk space may be considerable, and excessive free space consumed. It's important to delete these work tables as soon as possible after they're no longer needed since allocated database (DB) space is not easily freed. It's very helpful if you insist on a standard naming convention for backup tables so that they are easy to find. A manual backup table is not necessary to remain on the system longer than a day since regular database backups also make copies of the tables.
Alert Logs
Databases make a record of everything that goes on – not just of data, but also actual operations. These logs can fill up and in some cases, halt the database completely. Make sure you not only review database alert logs, but also purge them on a regular basis to prevent downtime. Consult your specific database manuals for information about logging.
iSeries Database Considerations
iSeries systems manage some unique files. Some of these were discussed in the operating system section and are repeated here for clarity. There are a number of temporary objects that you can remove as necessary:
Unnn, Tnnn, Rnnn, OW_Mnnn, and OWnnn SQL packages (nnn = numeric suffix)
QACXxxx Physical Files (xxx = alphanumeric suffix) in ExxxSYS library or STMF in IFS /tmp or ExxxSYS/tmp directory
Obsolete journal receivers in OWJRNL library (use DLTJRNRCV command)
See Oracle documents 1279546.1 and 1319579.1 for more information.
Miscellaneous Purges
Saved Objects
In the process of modifying or creating new objects, developers may use OMW to save their code to local zip files. Those files can serve as object backup or portable containers to share code. Those files can accumulate on their workstations over time and do more than just take up space. Corporate retention policies also apply to old versions of code. It is best to delete those files when they're not needed. One way to keep the workstations clean is to schedule regular times to check in all objects and re-image the workstation from an up-to-date snapshot.
Deleting Users
One purge that might actually be a bad idea is EnterpriseOne users. Once an employee leaves a company, it seems almost logical to just delete the user. After all, they're not going to create any new records, and removing them doesn't affect existing data, right? This is all true. However, if you get a couple years down the road and need to review historical transactions for an audit, it's going to be really tough to remember who WHSE147 was if the record is gone or no longer tied to an Address Book number.
Security
Adding security over the years can end up creating unnecessary duplication of security records and make for an extremely convoluted set of permissions. Review security once a year to be sure people have the proper authority and you don't have the digital equivalent of a ball of tangled wire on your hands.
For assistance extending your JD Edwards functionality or if you have any questions about the above, please email us at inquiries@GetGSI.com.