DSXchange

Have you tried declaring NAME_ID as a bigint?

Have you checked your linux support to see if there are known issues with "date"? I don't think that this problem originates in DataStage

Shared containers cannot be compiled. You need to use them in a job and compile the job.

OK, so you need to add a NullToValue() or otherwise handle those nulls and then you can mark the topic as resolved.

Is OP_Appt_hrg_Src.PROVIDERS_REFERENCE_NO a nullable field?

I did a quick search and found a large number of threads with this same problem, but the short of it is that you can increase the limit in UNIX with the command "ulimit -s {size}". You can do this in the dsenv file in order to make it apply t all DataStage users.

What happened when you added the "-x" option to your "orchadmin -rm" command as I suggested earlier?

dongyingying wrote:......when the sp failed caused by some exceptions or error...

Please post those messages, otherwise anyone responding would just have to guess what them might be.

As Craig has already pointed out, the "rub" of the problem is that the main job should have a "compiled" status as it should never be run. This means that somewhere in your processing you are executing this job without an invocation id and while it is running you cannot start any...

Start by breaking your logic (and Server Job) into small and simple steps. Start off with your join and use a lookup stage with 4 keys. Once you have that working then you can add a transform stage to work on your derivation logic.

No need to clear the status file, just recompile your multi-instance job. I think that the concensus is that the error you are seeing is due to an attempt to run same job&instance at the same time. Note that a multi-instance job can also be run without specifiy an invocation id, if the job is ru...

You've lost me with the last post. Does that mean that you can no longer reproduce the problem, or that you cannot get rid of the problem?

Yes, you can modify entries in your .dsx file from 8.7 so that it is read into 8.1. This method is not supported or documented or recommended, since any functionality that has changed or been added between 8.1 and 8.7 won't work and might cause strange effects. If your jobs aren't "tricky"...

One of the options is to "suppress" messages and not even log them at all. Unfortunately, it is also the default option for job level messages so can be a bit of a problem when all you want to do is make warnings into informational messages.

@ArndW I would like to clarify that TCS is not a "small" company as you can see from the number of employees and the revenue... Chandra, since I posted the number of employees in my response it should have been clear that I was being sarcastic. I've worked with TCS in the past and must ad...