Bill Rehm, Principal Solution Architect
When I teach the two-week CNC boot camp, one of the surprising things students learn about is the many log files, database tables, and other items that multiply and grow in size, without interruption. Left unchecked, these distributed pockets of information can cause slowness, process failures, or system shutdown. Since there isn't any automatic clearing or archiving, it will have to be done manually.
Basic Logging
Every CNC works with the e1root_xxx, jas_xxx, JDE_xxx, and JDEDEBUG_xxx logs throughout the system. A new set of logs will be created with a new process ID that is appended after every restart of services. Most of these logs can be viewed and managed to a limited degree, using Server Manager. Should you need to deal with a large number of logs or oversized files, you can use OS tools.
On the iSeries, you can find logs in the IFS directory (e.g. JDE900), iSeries Navigator for DB2/400 or iSeries Access. For Windows/UNIX, logs reside in JDERelease\ddp\log folder. Log files in HTML server reside in .\xxx.ear\webclient.war\logs\ folder in Windows/UNIX or IFS in AS400.
Object Management Workbench
By default, every action taken in OMW gets recorded by the dedicated logging system. With these logs, you can see the exact dates and times a person did anything to an object - check-in, check-out, promote, etc. Again, these logs are never automatically purged. In the grand scheme of things, OMW logging is probably not going to be a huge impact on available space. Most clients never purge these logs and never have a problem. However, if you have recorded a considerable amount of development activity continuously for years, the log growth would not be insignificant. This logging, stored in the database, is managed by the R98210B report.
Another consideration with a lot of ongoing development is the accumulation of projects within OMW. After a while, dozens or even hundreds of projects (hopefully at 38 or 01 status) accumulate and just clutter up the place. Once a project is complete, the reason to keep them diminishes. Use R98222B to purge projects you no longer need. This does not delete any objects, it just removes them from projects.
See Oracle document 626487.1 for more information on OMW logging.
Scheduler
The JDE scheduler program creates a record for every execution of every job run through its kernel. If you only have a few jobs running every so often, you might not need to worry about purging scheduler records for years. On the other hand, if you run hundreds of jobs every day, in a matter of weeks, things get out of hand. A complicating factor here is that scheduler records are rarely reviewed. Only when there is a problem does anyone open the detail for a job, and if it's been a long time they're going to be in for a surprise. Use the R91300B to clear out the scheduler records, but don't delete from the current date forward. If you do, you'll wipe out all the jobs that have been scheduled in advance.
See Oracle document 1292206.1 for more information on Scheduler purging.
Server Jobs
Not only does the scheduler create a record of each submission of a scheduled job, it submits a standard JDE report (UBE). All UBEs submitted in JDE are recorded in the F986110 along with extensive audit data in F986114/F986114A. The actual output of the report, (PDF by default), gets stored in the designated PrintQueue destination. By going to Form/Submitted Jobs from within Batch Versions or using Fast Path to go to Work Submitted Jobs (WSJ), you can view the list of jobs run on the system.
A pileup of records in WSJ does more than just clutter up space on the database - too many records can cause a significant performance impact. The WSJ tables are read from and written to quite a bit, not just by the JDE system, but by users as well. Occasionally users search on the WSJ grid without specifying any criteria. This causes the system to return the contents of the entire table. A busy system draws attention and user complaints. The returned dataset could be so large that it could cause the web server to crash. This would lead to users on that server being disconnected, which would be upsetting to them.
Another reason to purge WSJ data is for legal reasons. In the F9861101 and the PrintQueue location serve as records of financial transactions, employee reports, inventories, and a hundred other things. Some of these items cannot and should not be kept past a certain time.
Purge UBE records from all locations in the database and from the PrintQueue directories by manually running the R9861101 locally. This UBE calls the R9861102 and R9861103 as well.
See Oracle document 784600.1 for more information on purging the F986110. If running the WSJ purge manually isn't your style, check Oracle document 1220417.1 to learn how it can be run on the enterprise server.
Package management
Deleting old full and update package builds not only keeps your package assembly screen looking clean, but it also frees up space on the deployment and enterprise servers. The system will happily keep every full and update build ever created without any care for how much space is available. Unless you've set up space monitoring, chances are the first indication of storage problems materializes when a package build fails. Another symptom that deployment server space starvation is occurring is that new media objects won't save.
Deleting old packages is very simple: Go in to Package Assembly and click delete. That will remove all traces of that build from within JD Edwards and all corresponding physical files. I recommend keeping the current full build and the corresponding updates. Keeping the previous full is often recommended, but if space is tight, do away with all previous packages with little worry.
For assistance extending your JD Edwards functionality or if you have any questions about the above, please email us at inquiries@GetGSI.com.