DSXchange

tulasi wrote:Hi
r u able to resolve this issue.
i am also having a similar issue. please help me in this.

Rather than jumping on a four year old "similar" post, you need to start a new post and explain to us exactly what the particulars of your issue are. Then we can help.

Those other posts should have mentioned that you run the ulimit command inside a job to get accurate values rather than running it manually at the command line. Did you?

I know it's been worded a little oddly but I've been working on the assumption that they want JOB2 to run if JOB1 runs ok or has warnings.

Split from the linked post - please check the Release, Type & OS.

I think that doc is a little short on details. From what I recall, you replace a "#" with "__035__", that's two underscores on both sides of the internal value.

"On the database side" means you have your DBA check for you. Let them know what table(s) it is accessing and/or the connecting user.

I was responding to your concerns that if you had gaps in the sequence that those gaps would somehow lead to duplicates being generated in subsequent runs, which is... wrong. We do update one table with latest Seq Number+no.of records in the present run. That's your problem. You should be updating ...

I don't see how you get there from here. Gaps = duplicates? No. I dont get any duplicates, Eg; You conviently left out part of what I quoted: As per my concern, this should be sequence number as i am maintaing max sequence number in a file. if we have gaps in seq.numbers. We will get duplicates seq...

When you code JOB1.$JobStatus in a trigger, the name of the Job Activity stage you are checking must be JOB1... is it?

Yes - use RUNWARN rather than RUNNING.

First task would usually be to trace the processes on the database side, see if there are locks / blocks there causing the 'hang'.

1. What type of procedure did you set the stage to? Sounds like 'target' would be appropriate here. Getting it wrong can generate the error you posted.

2. You don't bind in the parameter name from the proc but rather that field from the job that should be passed to each positional parameter.

vik1979 wrote:what could be the issue with the environment?

Probably nothing. The 8.0 version was notoriously buggy, perhaps there is a fixpack that corrects the issue.

In the meantime, start using your script. If a job is locked and gets skipped one night, more than likely you'll pick it up the next night. Better than nothing... and it will give you an idea what kind of a problem (if any) you'll have with locks.

As in the Server function or you got the PX version working?