Page 1 of 1

Corrupt Jobs

Posted: Tue Oct 02, 2007 5:08 am
by Doc Phil
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.

Posted: Tue Oct 02, 2007 6:07 am
by ArndW
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.

Posted: Tue Oct 02, 2007 6:55 am
by Doc Phil
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?

Posted: Tue Oct 02, 2007 7:05 am
by chulett
Curious... how did you 'migrate' these jobs? What was the nature of the corruption encountered and how did you... uncorrupt them?

Posted: Tue Oct 02, 2007 7:47 am
by Doc Phil
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.

Posted: Tue Oct 02, 2007 7:56 am
by DSguru2B
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?

Posted: Tue Oct 02, 2007 8:14 am
by Doc Phil
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

Posted: Tue Oct 02, 2007 8:44 am
by chulett
You export *just* the executables? :?

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

Posted: Tue Oct 02, 2007 9:14 am
by Doc Phil
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...

Posted: Tue Oct 02, 2007 9:19 am
by Doc Phil
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

Posted: Thu Oct 18, 2007 11:29 am
by DKostelnik
go to the admin tool and execute DS.CHECKER against the specific project.