DSXchange

I'm getting the same error. And what he gave is the entire error message, given from the activity status screen. I tried to view it using the IA Log View, but it doesn't show. Odd thing is, I've run this same analysis before. I have to run it every month, and this is the first time I had an issue wi...

I would try right-clicking on the SET file and select 'Provision All'. Other than that, I'm not sure.

One odd thing I've noticed is that is person A has a job open that uses a rule set, then person A has also locked that rule set from persons B, C, and D. I have also noticed, at least on our system, that person A has to close down DS to completely unlock it. It seems to take more than just closing t...

Since you are using version 8, you have access to all of the DataStage components as well. There is a way to call C routines through one such stage. This is one of the more advanced topics, and was barely covered in the advaced DS class. I would check out the documentation that comes with DS to see ...

I wouldn't recommend matching on only the name. We have a group where that's all we have, and our success rate is low. Always try to match on address if you can.

And the area info (city/state/zip) are good for blocking.

Good luck.

Configuring the DB connection is only for testing the pass within the Match Spec. You don't need it to run the job itself. If you're able to set up a test DB for testing the passes, I'd go for it; it seems to be faster. I'm not sure how much more help I'll be for your problem. I've been dealing with...

Not to sound condescending, but you did provision the match spec and passes, and compile the job, right? I've made that mistake myself. All blocking does is group the data according to the values. This makes the actual matching better. You should try to use the standardized data, probably some of th...

I replied to the previous post as well (the last entry).

Make sure you are blocking on something in all of the passes in the Match Spec. I made that mistake as well, and spent hours trying to fix it.

We are running into the same set of errors and are trying to figure out what could have caused it. Have you had any luck yet ? From what I can recall, the problem was with the server. This was a while ago, and we've had several problems since then, so I can't remember the details. I think we had to...

The + refers to a single word that consists of only letters. The ++ refers to two words that are seperated by something that appears in both the STRIPLIST and SEPLIST. If you have the client installed on your machine, then you'll have access to the documentation that is a good reference to this stuf...

Have you tried explicitly partitioning and sorting on the blocking field(s)?

Yes, I have. I still get the same error. And keep in mind that I get the error even if I don't specify a match spec.

I now have a valid workaround for those having this problem. If you run the affected job on a single node configuration, it should run.

Though we still don't know the cause of the problem.

I've been in contact with IBM support and was given a workaround until a patch could be released. Unfortunately, the workaround doesn't always work.

To get around the problem, you must run the job sequentially. It got one set of jobs running again, but not another.

If the problem is already occuring, it seems as though it always aborts if I tell the Match_Freq stage not to use a match spec. If the job is working, it could still fail if I use a match spec, but not always.

Yet when I first ran these jobs, I wasn't using a match spec and it ran fine.

I have been working on this some more and found some interesting information. I added a pass to a match spec that was already running. Then the error popped up. I placed the pass into the holding area and ran it again; it worked. I added the pass again, but then deleted a matching column. I still go...