Corrupt Jobs
Moderators: chulett, rschirm, roy
Corrupt Jobs
I have searched this forum, and couldnt quite find what I was looking for....
Is there a way to check if there are any jobs that are corrupt in a project?
We migrated our jobs from one environment to the next, and only discovered in the middle of a sequence running that a job was corrupt. This obviously caused a lot of last minute frantic sequence creation which could have been avoided if we simply checked before the time.
Is there a way to check if there are any jobs that are corrupt in a project?
We migrated our jobs from one environment to the next, and only discovered in the middle of a sequence running that a job was corrupt. This obviously caused a lot of last minute frantic sequence creation which could have been avoided if we simply checked before the time.
Anticipation of failure is worse than failure itself
There are various types of errors, and not all of them can be detected or discovered the same way.
Recompilation usually does a good job of either detecting or eradicating errors.
Recompilation usually does a good job of either detecting or eradicating errors.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
Thanks Arn. I accept that one cannot cater for all errors.
However, I find it hard to accept that a sequence should abort halfway through because of a corrupt job, when after importing I should have some kind of way to check that my job is corrupt. Oi. It means that someone has to sit and drive a keyboard at absurd hours, as opposed to simply leaving things on a schedule and performing ad-hoc checks.
Last weekend we had to man the keyboard 24/7 for 64 hours in part due to perhaps getting corrupt jobs. And yes, there were corrupt jobs... Trying to eliminate this need in every way possible
Any ideas?
However, I find it hard to accept that a sequence should abort halfway through because of a corrupt job, when after importing I should have some kind of way to check that my job is corrupt. Oi. It means that someone has to sit and drive a keyboard at absurd hours, as opposed to simply leaving things on a schedule and performing ad-hoc checks.
Last weekend we had to man the keyboard 24/7 for 64 hours in part due to perhaps getting corrupt jobs. And yes, there were corrupt jobs... Trying to eliminate this need in every way possible
Any ideas?
Anticipation of failure is worse than failure itself
hey Craig
We exported the executables to a different project (note: we are not so fortunate, we have a single datastage environment oi).
The technical guys in Manilla indicated that the jobs were corrupt. So we recompiled in the different project re-exported the executables, and imported in the project required, which appears to have done the trick
I am thinking that maybe while we were exporting the executables, someone may have had some jobs open. Its a 24/7 kind of project with resources based on 3 continents, so its highly unlikely that all the jobs would be closed by all datastage developers.
We exported the executables to a different project (note: we are not so fortunate, we have a single datastage environment oi).
The technical guys in Manilla indicated that the jobs were corrupt. So we recompiled in the different project re-exported the executables, and imported in the project required, which appears to have done the trick
I am thinking that maybe while we were exporting the executables, someone may have had some jobs open. Its a 24/7 kind of project with resources based on 3 continents, so its highly unlikely that all the jobs would be closed by all datastage developers.
Anticipation of failure is worse than failure itself
Sorry, forgot to answer how the extracts are performed...
We have a project for each environment
So we export from the development project the executables
And import these to the target environment.
Dont need to compile, as long as it is compiled in development
The hit the run button in the target environment and it runs
Anyway, very simple what to do here
- Save a copy of the manager client and assess for any hiccups
- Make this part of the migration of code...
I have marked the topic as resolved.
Thanx once again for all the assistance
We have a project for each environment
So we export from the development project the executables
And import these to the target environment.
Dont need to compile, as long as it is compiled in development
The hit the run button in the target environment and it runs
Anyway, very simple what to do here
- Save a copy of the manager client and assess for any hiccups
- Make this part of the migration of code...
I have marked the topic as resolved.
Thanx once again for all the assistance
Anticipation of failure is worse than failure itself
-
- Participant
- Posts: 34
- Joined: Tue Jan 30, 2007 6:13 pm
- Location: Central Florida