Corrupt Jobs

Doc Phil · Post by **Doc Phil** » Tue Oct 02, 2007 5:08 am

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.

ArndW · Post by **ArndW** » Tue Oct 02, 2007 6:07 am

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.

Doc Phil · Post by **Doc Phil** » Tue Oct 02, 2007 6:55 am

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?

chulett · Post by **chulett** » Tue Oct 02, 2007 7:05 am

Curious... how did you 'migrate' these jobs? What was the nature of the corruption encountered and how did you... uncorrupt them?

Doc Phil · Post by **Doc Phil** » Tue Oct 02, 2007 7:47 am

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.

DSguru2B · Post by **DSguru2B** » Tue Oct 02, 2007 7:56 am

Who ever is responsible for the export should have a generated report that indicates how many exports were unsuccessful. Are you using Version Control for this task?

Doc Phil · Post by **Doc Phil** » Tue Oct 02, 2007 8:14 am

Nopes, its the one thing I spotted which they dont have and seriously need, version control.

I like the idea of having a report indicating that all exports were successful.

:D

chulett · Post by **chulett** » Tue Oct 02, 2007 8:44 am

You export *just* the executables?

How exactly is the extract performed? The Manager client *does* produce a log of all problems encountered, btw.

Doc Phil · Post by **Doc Phil** » Tue Oct 02, 2007 9:14 am

New to the project, and this is the status quo at the moment.

Will be researching at least a chapter a night now that I know where the developer's guide is.

Thanks for the guidance...

Doc Phil · Post by **Doc Phil** » Tue Oct 02, 2007 9:19 am

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

DKostelnik · Post by **DKostelnik** » Thu Oct 18, 2007 11:29 am

go to the admin tool and execute DS.CHECKER against the specific project.