Controller problem: Error calling DSRunJob(Batch::Test), code=-14
[Timed out while waiting for an event]
Can you suggest how can this error be avoided?
Error calling job
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Thanks for the responses!!
I was thinking along the same line. Probably I will have to run them on a more efficient server.
I was just wondering whether it had anything to do with improper job design (like too many nested calls, for example Seq calls a sequencer, which then calls another Batch, which finally calls batch that calls the job). Seems like no---what do you think?
I was thinking along the same line. Probably I will have to run them on a more efficient server.
I was just wondering whether it had anything to do with improper job design (like too many nested calls, for example Seq calls a sequencer, which then calls another Batch, which finally calls batch that calls the job). Seems like no---what do you think?
The -14 error indicates that a job start request was issued and that 60 seconds have elapsed while waiting for a record to be written to a status
file.
If the lock tables are too small the job will fail to start and you will get a -14 error. If the system is under a heavy load the job process may not have enough time to write a record to the status file and this will also result in a -14 error.
The RLTABSZ, GLTABSZ and MAXRLOCK parameters determine the size of the lock tables and subsequently how many jobs that can be active at one time.
If you have not already done so, you can try increasing the parameters in the uvconfig file.
Regards
Nagesh
file.
If the lock tables are too small the job will fail to start and you will get a -14 error. If the system is under a heavy load the job process may not have enough time to write a record to the status file and this will also result in a -14 error.
The RLTABSZ, GLTABSZ and MAXRLOCK parameters determine the size of the lock tables and subsequently how many jobs that can be active at one time.
If you have not already done so, you can try increasing the parameters in the uvconfig file.
Regards
Nagesh
Simplicity is the ultimate sophistication
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The lock tables are almost never the issue here. Don't fiddle with these parameters (nor GSEMNUM, probably the most important of all, which Nagesh failed to mention) unless you know what you are doing. You can render DataStage incapable of starting with unwise selections.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Just the totality of work you're asking the server to do. Doesn't matter how you're asking.sammilan wrote:Thanks for the responses!!
I was thinking along the same line. Probably I will have to run them on a more efficient server.
I was just wondering whether it had anything to do with improper job design (like too many nested calls, for example Seq calls a sequencer, which then calls another Batch, which finally calls batch that calls the job). Seems like no---what do you think?
And don't fall into the trap of "hey, we've got a more efficient server now, let's load it up some more!". Think about why you had to get the more efficient server.
This is another simple supply and demand problem. Right now you're demanding more resources than the server can supply. You can increase the supply (more efficient server). You can decrease the demand (fewer simultaneous tasks, smaller work units, etc.).
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.