Archives of the TeradataForum

Message Posted: Wed, 31 May 2006 @ 09:57:43 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

My experience with the utilities is that they are pretty robust as far as core dumps go. After all, they have been around for along time and are pretty mature.

On the other hand, an INMOD is code that has been developed as a "plug in" or "extension" to one of the utilities, in this case multiload. However, that's not to say that the mload can't experience a core dump. For example if you have an INMOD that returns a null pointer and mload attempts to dereference it, it may experience a core dump. I would still argue that it isn't mloads fault it was given a null pointer, it was the inmod - however the point where the failure actually occurred would be in the mload code that dereferenced the pointer.

If there is a bug or whatever in the INMOD which will result in a core dump, then the whole application (i.e. mload) will crash (not just your module). This is because at a high level, Unix (and Windoze for that matter) is concerned with running programs. If a problem occurs in one of the programs it will generate a core dump (or GPF) irrespective of whether the problem occurred in this library or that control (or your INMOD).

Are you 100% sure that your INMOD has no problems and is fully debugged?

Are you trying to do anything fancy in it such as buffering or some other complex processing that might be influenced by external factors such as system workload, time of day etc?

Is there something that might be related to the time, or the sequence that the records are received or the fullness of the database containing the tables being mloaded?

Possibly you are experiencing a "data overrun" condition. Could it be that a file was being "delivered" while the mload was running and this caused the INMOD to get confused - possibly because the incoming file was not yet complete? Put another way, maybe when the job failed, files just happened to arrive faster than the mload+INMOD could process them. However, when you re-ran the process in another database, maybe the mload+inmod could keep ahead of the incoming files. BTW. When you say a different database, do you mean a different database on the same system, or a whole different system (eg. a test system)?

It is difficult to advise on such things without extremely detailed knowledge of the environment, the goal and the code. This is especially true if the fault is intermittent. If it is not intermittent and happens every single time in the first environment, then clearly there must be something different between the two environments - you just haven't identified the specific difference (other than the database name). Understanding this difference will help you understand the root cause of the core dump and thus enable you to identify a solution.

All the best with your search

Glenn Mc

	<Prev	Next>		<<First	<Prev	Next>	Last>>