My parallel job populating warnings even after setup to suppress warnings as info by message handler.
When I see the project level message handler setup, I noticed it has two similar entries for same warning message.
Message handler looks like.
IIS-DSEE-TFSF-XXXXX 1 Span for padding a substring must be non-negative: 0. No padding will be performed.
IIS-DSEE-TFSF-XXXXX 2 1 APT_CombinedOperatorController,0: Span for padding a substring must be non-negative: 0. No padding will be performed.
This duplicate(!) entries of message handler causing this issue? Please advice.
Warnings are not suppressed even Message Handler is setup
Moderators: chulett, rschirm, roy
The message with APT_CombinedOperatorController is generated because the second warning is coming from some "combined" stages and it can't tell which one is generating the problem.
When DataStage can safely do so, it optimizes performance for some operators (stages) by combining them to run in a single process on the UNIX side. This maximizes performance and minimizes resource utilization. However it also means that if any of the stages generate an error, it can't identify which one had the issue.
By adding the environment variable $APT_DISABLE_COMBINATION to your job and setting it to true, it will turn off combination, and the message will be tagged to the correct stage. This option slows down the job, so its a good idea to remove it when you are done debugging.
So, with that aside, back to the main problem!
First of all, I do not recommend demoting or removing warnings from jobs unless absolutely necessary. Almost all of them can be easily cleaned up once you understand what it is telling you.
In this case, it looks like the job is attempting to use a pad function and supplying it with a negative length. That means the pad calculation is malformed and should be corrected. If you need help in correcting that, please create a new topic and post the code you think is causing the warning.
Also - it is almost never appropriate to suppress warnings for an entire project. Once you do that, it affects every job in the project, preventing other developers from knowing that the problem even exists. A better practice is to demote warnings, and then only for the job that is currently displaying them.
This can be done from the DataStage Director by opening the log, right clicking on the message and selecting Add Rule to Message Handler. That will bring up a pop-up that will allow you to select the local run-time handler for the job. The job-based rule will move with the job to a new environment as long as you move the compiled object code.
However, I strongly urge you to fix the warnings instead of hiding them. That's like putting tape over the warning lights in your car. Sometimes you might get away with it, but usually it will cause bigger problems down the road!
When DataStage can safely do so, it optimizes performance for some operators (stages) by combining them to run in a single process on the UNIX side. This maximizes performance and minimizes resource utilization. However it also means that if any of the stages generate an error, it can't identify which one had the issue.
By adding the environment variable $APT_DISABLE_COMBINATION to your job and setting it to true, it will turn off combination, and the message will be tagged to the correct stage. This option slows down the job, so its a good idea to remove it when you are done debugging.
So, with that aside, back to the main problem!
First of all, I do not recommend demoting or removing warnings from jobs unless absolutely necessary. Almost all of them can be easily cleaned up once you understand what it is telling you.
In this case, it looks like the job is attempting to use a pad function and supplying it with a negative length. That means the pad calculation is malformed and should be corrected. If you need help in correcting that, please create a new topic and post the code you think is causing the warning.
Also - it is almost never appropriate to suppress warnings for an entire project. Once you do that, it affects every job in the project, preventing other developers from knowing that the problem even exists. A better practice is to demote warnings, and then only for the job that is currently displaying them.
This can be done from the DataStage Director by opening the log, right clicking on the message and selecting Add Rule to Message Handler. That will bring up a pop-up that will allow you to select the local run-time handler for the job. The job-based rule will move with the job to a new environment as long as you move the compiled object code.
However, I strongly urge you to fix the warnings instead of hiding them. That's like putting tape over the warning lights in your car. Sometimes you might get away with it, but usually it will cause bigger problems down the road!