Hi
Is it possible to have a number of separate extracts from a database to separate sequential files in a single job?
In other words these will complete asynchronously and we are expecting the job to complete after the longest running one completes.
We have a number of jobs like this and are finding that when they are run by an external scheduler with 'dsjob' some of the extracts did not complete although the job has completed and returned a successful return code to the scheduler.
Thanks
Andrew
Is it possible to have unlinked stages
Moderators: chulett, rschirm, roy
For a Server job, yes this should work. Independent streams execute as much as possible until a shared passive stage is used to link the streams. If there's no reference stage, then the independent streams should execute to completion.
The issue is this job cannot be re-ran without re-running all streams. It would be better to separate the streams as jobs and then use a Sequence or Batch job to coordinate, at least you gain some measure of restart control.
I suspect your issue is more likely due to previous issues with these jobs leaving zombied processes still out there. If you do a ps -ef|grep phantom you can see the pieces of each job. If an active connection is still out there when the job runs again, the job may mistake that active process for its own and not work correctly. It can exit right away with a success code. I've seen this activity for years, so be aware if you have job failures when talking to a database, always check to make sure all parts have died before restarting.
If your question is about a 390, ignore my comments.
The issue is this job cannot be re-ran without re-running all streams. It would be better to separate the streams as jobs and then use a Sequence or Batch job to coordinate, at least you gain some measure of restart control.
I suspect your issue is more likely due to previous issues with these jobs leaving zombied processes still out there. If you do a ps -ef|grep phantom you can see the pieces of each job. If an active connection is still out there when the job runs again, the job may mistake that active process for its own and not work correctly. It can exit right away with a success code. I've seen this activity for years, so be aware if you have job failures when talking to a database, always check to make sure all parts have died before restarting.
If your question is about a 390, ignore my comments.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
-
ray.wurlod
- Participant
- Posts: 54595
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Hi
Thanks for your responses, we are running on an AIX server reading from an Oracle database also on an AIX server.
The problem was that some of the, for example 8 extracts, in the one job did not complete but the job apparently returned a successful completion code to the scheduler. This is the main problem as a single stage in a job failure should stop the sequence.
I suspect that the source server may not have had adequate connections available, although that should have caused a failure.
As to your point about restartability it is a good point that I had overlooked thank you, although we overwrite the sequential files so that is fine, but in other cases a problem.
Thanks and regards
Andrew
Thanks for your responses, we are running on an AIX server reading from an Oracle database also on an AIX server.
The problem was that some of the, for example 8 extracts, in the one job did not complete but the job apparently returned a successful completion code to the scheduler. This is the main problem as a single stage in a job failure should stop the sequence.
I suspect that the source server may not have had adequate connections available, although that should have caused a failure.
As to your point about restartability it is a good point that I had overlooked thank you, although we overwrite the sequential files so that is fine, but in other cases a problem.
Thanks and regards
Andrew