All these items depend on the platform you're running and the size of your installation as well as how large your development outfit is.
Heres some comments on what you have found so far :
[ QUOTE ]
Package Builds
Build/Deploy Full Packages
[/ QUOTE ]
Obviously, package builds are dependent on the amount of development you're promoting. If you're completely stable, and have no development, then you won't be performing package builds more than once a month. On the other hand, if you're a large development outfit and are continuously rolling out functionality, then this can occur more frequently. I try and stress that production builds should be FULL packages on a scheduled basis - and on any implementation where development is pushed into production - then a prod package should be built and deployed WEEKLY - usually on a Tuesday night. I pick that night, because people are always around on Wednesdays - deploying on Friday is always bad, since there might not be any activity to discover an issue over the weekend, and nobody wants a system down due to package build issues on a Monday morning ! PY packages could be a daily affair - or even multiple times a day depending on your project load.
[ QUOTE ]
Purging Tasks
[/ QUOTE ]
Purging is very much down to the customer. This is a functional activity - deleting old historical data. However, the following are good keys :
[ QUOTE ]
Job History
Purge Submitted Jobs older then XX days
Purge completed Scheduler Jobs older then XX days
[/ QUOTE ]
Usually 30 days is enough time - but I sometimes extend that to 60 days, just in case. Some customers have the PDF's saved to optical devices - so that as soon as they are transferred off, its possible to remove them from WSJ. This can easily be scheduled.
[ QUOTE ]
Work Center
Purge Work Center messages/tasks older then XX days
Purge Work Center processes
[/ QUOTE ]
These often get forgotten about. I like to delete messages about the same frequency as the submitted jobs - but these can take up a lot of space, and your company might want to only keep 7 days of messages.
[ QUOTE ]
Package History
Purge Package Build History
Purge deployment records for client deployments
Purge deployment records for server deployments
[/ QUOTE ]
I usually keep the last two or three full packages plus all related update packages. Therefore, each time I build a new full package, I delete the old package n-3 ago. Look to my website to a document that talks about naming conventions that will help schedule deletion of packages and keep this ordered (look for a document called "ESU installation procedures")
[ QUOTE ]
Logs
PDF Generation Temp Files
PDF Viewing Temp Files
[/ QUOTE ]
delete these whenever you can. They don't need to be around.
[ QUOTE ]
JAS Logs
WebSphere Application Server Logs
Enterprise Server Logs
[/ QUOTE ]
I would delete these when you stop/start services. I have created scripts at customers that zip these up, so they can be backed up, and then remove them at the time the services are stopped/started for a regular backup.
[ QUOTE ]
HTTP Logs
[/ QUOTE ]
There really isn't any reason to keep these. Unless you're looking at some statistics.
[ QUOTE ]
Rebuild XREF
Cross Reference Rebuild (XREF)
[/ QUOTE ]
You should do this on a regular basis - more so if you're using QSoft or a program that uses xRef - but its always a good idea to regularly keep this up to date
[ QUOTE ]
Some said they like to clear OMW logs but others recommended against it. Anything else?
[/ QUOTE ]
NEVER, EVER clear OMW Logs. This is your way to identify when an object has been touched, who touched it, etc etc. This is a core SOX requirement to be honest - so if you're a US public company, these OMW logs are your key to SOX compliancy. However, EVERYONE should keep OMW logs - and they should only ever be purged when you UPGRADE (ie, a new system is implemented). Otherwise you'll never know WHO developed an object, WHEN it was developed, and WHY.
On AS/400 - you should remove SQL Packages on a regular basis - just to keep everything "clean".
On an Oracle and SQL database, you should perform re-org duties - usually once a week (and usually on a Sunday or on a "quiet" day).
Backing up is important. I like to not only use a traditional database backup, but also have "options" - on SQL Server, for example, I like to use BCP Exports of individual tables (all tables) so that I have the ability to restore a single table if need be (or use these exports for refreshes).
Regular refresh of the CRP data - obviously based on your testing schedules.
On very large development organizations, regular regression testing using an automated testing tool - this requires regular refreshes of a "golden" test data set, together with regular testing practices. I have a whitepaper that talks more about this (the case for a QA pathcode).
If you're using a citrix farm - either for fat clients or for publishing IE, you should regularly bounce the farm (once per night to once per week)
Boucing the JAS servers on a regular basis wouldn't hurt (once per week to once per month)
I'm sure others have ideas too...