Jeremy M.
Well Known Member
I am curious to find out what everyone typically does on a weekly basis to mantain their JDE systems?
Tom_Davidson
VIP Member
The first thing I'd do is run R9861101 to purge old submitted jobs. The number of days to keep will vary on installation.
Jeremy M.
Well Known Member
From other posts I have gathered these items:
Package Builds
Build/Deploy Full Packages
Purging Tasks
Job History
Purge Submitted Jobs older then XX days
Purge completed Scheduler Jobs older then XX days
Work Center
Purge Work Center messages/tasks older then XX days
Purge Work Center processes
Package History
Purge Package Build History
Purge deployment records for client deployments
Purge deployment records for server deployments
Logs
PDF Generation Temp Files
PDF Viewing Temp Files
JAS Logs
WebSphere Application Server Logs
Enterprise Server Logs
HTTP Logs
Rebuild XREF
Cross Reference Rebuild (XREF)
Some said they like to clear OMW logs but others recommended against it. Anything else?
Package Builds
Build/Deploy Full Packages
Purging Tasks
Job History
Purge Submitted Jobs older then XX days
Purge completed Scheduler Jobs older then XX days
Work Center
Purge Work Center messages/tasks older then XX days
Purge Work Center processes
Package History
Purge Package Build History
Purge deployment records for client deployments
Purge deployment records for server deployments
Logs
PDF Generation Temp Files
PDF Viewing Temp Files
JAS Logs
WebSphere Application Server Logs
Enterprise Server Logs
HTTP Logs
Rebuild XREF
Cross Reference Rebuild (XREF)
Some said they like to clear OMW logs but others recommended against it. Anything else?
m@dm@x
Well Known Member
I submit a weekly proposal to fire my AS/400 Administrator.
Max
Max
gregglarkin
Legendary Poster
[ QUOTE ]
I submit a weekly proposal to fire my AS/400 Administrator.
Max
[/ QUOTE ]
My DBAs and Developers are fine, but there are a few infrastructure guys I'd be willing to vote off the island....
I submit a weekly proposal to fire my AS/400 Administrator.
Max
[/ QUOTE ]
My DBAs and Developers are fine, but there are a few infrastructure guys I'd be willing to vote off the island....
jdeKrnl
Active Member
We also run a custom report that identifies scheduled jobs that are about to expire.
m@dm@x
Well Known Member
[ QUOTE ]
[ QUOTE ]
I submit a weekly proposal to fire my AS/400 Administrator.
Max
[/ QUOTE ]
My DBAs and Developers are fine, but there are a few infrastructure guys I'd be willing to vote off the island....
[/ QUOTE ]
My Developers are fantastic. They claim every issue is a CNC issue but that's expected. For example, the coffee remained on the burner for too long the other day and it was my fault. However, I welcome the day we kick the 400 out of our shop. Believe me, I love the 400; it's the other useless bagage that comes with it I could do without.
Max
[ QUOTE ]
I submit a weekly proposal to fire my AS/400 Administrator.
Max
[/ QUOTE ]
My DBAs and Developers are fine, but there are a few infrastructure guys I'd be willing to vote off the island....
[/ QUOTE ]
My Developers are fantastic. They claim every issue is a CNC issue but that's expected. For example, the coffee remained on the burner for too long the other day and it was my fault. However, I welcome the day we kick the 400 out of our shop. Believe me, I love the 400; it's the other useless bagage that comes with it I could do without.
Max
m@dm@x
Well Known Member
All,
I'm a lucky man; my 400 Admin sucks on EPIC levels. Please discuss. Just Say'in.
Max
I'm a lucky man; my 400 Admin sucks on EPIC levels. Please discuss. Just Say'in.
Max
brother_of_karamazov
Legendary Poster
I was under the impression that AS/400's sat in closets.....dusty, forgotten and requiring no admin.
[ QUOTE ]
All,
I'm a lucky man; my 400 Admin sucks on EPIC levels. Please discuss. Just Say'in.
Max
[/ QUOTE ]
[ QUOTE ]
All,
I'm a lucky man; my 400 Admin sucks on EPIC levels. Please discuss. Just Say'in.
Max
[/ QUOTE ]
m@dm@x
Well Known Member
[ QUOTE ]
I was under the impression that AS/400's sat in closets.....dusty, forgotten and requiring no admin.
[ QUOTE ]
All,
I'm a lucky man; my 400 Admin sucks on EPIC levels. Please discuss. Just Say'in.
Max
[/ QUOTE ]
[/ QUOTE ]
I wish my Admin would do just that!
I was under the impression that AS/400's sat in closets.....dusty, forgotten and requiring no admin.
[ QUOTE ]
All,
I'm a lucky man; my 400 Admin sucks on EPIC levels. Please discuss. Just Say'in.
Max
[/ QUOTE ]
[/ QUOTE ]
I wish my Admin would do just that!
AllisonD
Well Known Member
What is your EPIC admin doing to you? You have to be trying real hard to screw up the 400...
m@dm@x
Well Known Member
[ QUOTE ]
What is your EPIC admin doing to you? You have to be trying real hard to screw up the 400...
[/ QUOTE ]
One of his disastrous recipes included two parts electricity and one part MIMIX. I have to admit, alot of it is bad luck. For example, the cd drive wasn't working correctly on our Production Server and when he inserted a Vertex CD, there was a whole bunch of blinking lights and calls to IBM support afterwards. I felt bad for the guy until he blamed it on our Vertex Admin. I guess the drive had been bad for over a year before the CD insertion and was never taken care of.
Max
What is your EPIC admin doing to you? You have to be trying real hard to screw up the 400...
[/ QUOTE ]
One of his disastrous recipes included two parts electricity and one part MIMIX. I have to admit, alot of it is bad luck. For example, the cd drive wasn't working correctly on our Production Server and when he inserted a Vertex CD, there was a whole bunch of blinking lights and calls to IBM support afterwards. I felt bad for the guy until he blamed it on our Vertex Admin. I guess the drive had been bad for over a year before the CD insertion and was never taken care of.
Max
pduncan
Member
[ QUOTE ]
The first thing I'd do is run R9861101 to purge old submitted jobs. The number of days to keep will vary on installation.
[/ QUOTE ]
fairly new CNC here - is there any 'danger' in running this?
The first thing I'd do is run R9861101 to purge old submitted jobs. The number of days to keep will vary on installation.
[/ QUOTE ]
fairly new CNC here - is there any 'danger' in running this?
gregglarkin
Legendary Poster
well if you set the interval to one day, it will keep your system clean but royally piss off your users. as a policy, we tell users that we will keep 30 days of reports active. I manually delete the jobs, and then run this report. it cleans out the records of the jobs. I like to manually clean out the queue, it keeps me in touch with the directory structure of my server.
- Gregg
- Gregg
brother_of_karamazov
Legendary Poster
[ QUOTE ]
well if you set the interval to one day, it will keep your system clean but royally piss off your users. as a policy, we tell users that we will keep 30 days of reports active. I manually delete the jobs, and then run this report. it cleans out the records of the jobs. I like to manually clean out the queue, it keeps me in touch with the directory structure of my server.
- Gregg
[/ QUOTE ]
Allow me to translate Gregg for you:
"I like to manually clean out the queue, it keeps me in touch with the directory structure of my server."
equals
"Boss, I am gonna grab a beer and be cleaning out queues so don't expect to see me for the rest of the day."
well if you set the interval to one day, it will keep your system clean but royally piss off your users. as a policy, we tell users that we will keep 30 days of reports active. I manually delete the jobs, and then run this report. it cleans out the records of the jobs. I like to manually clean out the queue, it keeps me in touch with the directory structure of my server.
- Gregg
[/ QUOTE ]
Allow me to translate Gregg for you:
"I like to manually clean out the queue, it keeps me in touch with the directory structure of my server."
equals
"Boss, I am gonna grab a beer and be cleaning out queues so don't expect to see me for the rest of the day."
gregglarkin
Legendary Poster
[quoteAllow me to translate Gregg for you:
"I like to manually clean out the queue, it keeps me in touch with the directory structure of my server."
equals
"Boss, I am gonna grab a beer and be cleaning out queues so don't expect to see me for the rest of the day."
[/ QUOTE ]
Dude - we discussed that in the CNC union meeting. You keep the union secrets off the forum. We only teach those secrets after the intiation ceremony...
- Grand Puba Gregg
"I like to manually clean out the queue, it keeps me in touch with the directory structure of my server."
equals
"Boss, I am gonna grab a beer and be cleaning out queues so don't expect to see me for the rest of the day."
[/ QUOTE ]
Dude - we discussed that in the CNC union meeting. You keep the union secrets off the forum. We only teach those secrets after the intiation ceremony...
- Grand Puba Gregg
brother_of_karamazov
Legendary Poster
[ QUOTE ]
[quoteAllow me to translate Gregg for you:
"I like to manually clean out the queue, it keeps me in touch with the directory structure of my server."
equals
"Boss, I am gonna grab a beer and be cleaning out queues so don't expect to see me for the rest of the day."
[/ QUOTE ]
Dude - we discussed that in the CNC union meeting. You keep the union secrets off the forum. We only teach those secrets after the intiation ceremony...
- Grand Puba Gregg
[/ QUOTE ]
The first rule of CNC Club is "You do not talk about CNC Club"
[quoteAllow me to translate Gregg for you:
"I like to manually clean out the queue, it keeps me in touch with the directory structure of my server."
equals
"Boss, I am gonna grab a beer and be cleaning out queues so don't expect to see me for the rest of the day."
[/ QUOTE ]
Dude - we discussed that in the CNC union meeting. You keep the union secrets off the forum. We only teach those secrets after the intiation ceremony...
- Grand Puba Gregg
[/ QUOTE ]
The first rule of CNC Club is "You do not talk about CNC Club"
altquark
Legendary Poster
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...
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...
Similar threads
- ahmedfawzi55
- JD Edwards® EnterpriseOne Technical