I have the usual setup of data running through a standardization stage (in some jobs, MNS in others) and then being split so I can get the match frequency to use in the match reference stage.
When I run the job, I get the following:
Code: Select all
Match_Frequency_25,1: Input not sorted at record 1606
This occurs for each node. The numbers are not always the same.
It seems to run fine if I create a new job and a new match spec to use in the frequency stage. If I change the columns or change the match spec, I get this error.
I don't want to keep creating the same jobs over and over again. I didn't have to before this. Has anyone seen an error like this before?
Further Information (6/20/08):
I just had it occur again. I had a working job. Then I changed the match spec so that the only pass in the spec matched on an additional column. I provisioned the spec/pass. Then I compiled and ran the job with the freq set to no match spec (to clear the data; had problems earlier and this fixed it). Then I ran the job and got the above error. I have the job for the reference data running right now, and now expect the same error (Got the error).
I hope this extra bit of information helps. Am I missing a step? Did I do the wrong step? Do I need a priest to sacrifice a live chicken to get it to work?
Further Information (Still 6/20/08):
I tried creating a copy of the match spec and using that, but it made no difference. I hope I don't have to create a brand new job (again) just to use the new match spec. I've created new jobs in the past and had them immediately fail with this problem. I believe I had to create both a new job and a new match spec.
I'd rather find a better resolution. In fact, I'd rather sacrifice that chicken.
Further Information (Still late in the workday, Friday, with no hope in sight):
I fixed the problem in the first update. The second update refers to a different (but similar) job with the same problem. The first update problem (FUP) was fixed by reverting the match spec back to the way it was, running the job without refering to the match spec, and then running the job with refering to the match spec.
If I figure out a real resolution to this problem, I'll post it here first thing.
Further Information (6/23/08):
I tried recreating the job from scratch, but using an existing match spec. Still get the error. It may work if I create a new job and match spec at the same time, but I somewhat recall trying that once already and still getting the error.
My coworker tried modifying a working match spec and got the error. Then he recompiled and ran the job again. It worked. So how can this happen, yet we can go long stretches with it working until the match spec if changed?
Current Theories (6/25/08):
We've tried many different things in the attempt to fix the problem. Everything seems to hinge on the match spec itself. If we modify it, it may or may not cause the problem. If the problem already exists, then it will likely occur again. Sometimes if you add a pass to a match spec, it may fail. But not always.
A case has been opened with IBM, but they have not yet been able to recreate the problem.