Occasional "Missing StringID[2046]" error

[Gazelle]

We occasionally receive a "Missing StringID[2046]" error when running datastage v7.x jobs from Unix.

- It happens for both PX jobs and for Server jobs.
- It usually happens when the job aborts, but there have been cases where the job finishes okay, but the message is still written to Unix (we lump std out and err together).
- It seems that Unix did not receive a return code indicating the job status.
- All processes continue to run, and must be terminated manually.

The "fix" is to rerun the job.

Does anyone have any ideas re the cause of this problem, and what we can do to prevent it?

[ray.wurlod]

Curious. "2046" does not appear in the source code for dsjob (see Appendix A, Server Job Developer's Guide).

The only 2046 in the resource table (DS_RESENU) carries the message "finished waiting for job".
I suspect that the code has attempted to find the string associated with this (functionally equivalent to the query SELECT "DESC" FROM DS_RESENU WHERE ERRNO = 2046;) when it's finished waiting for a job, but for whatever reason has failed to find it.
Are you having problems with other messages, for example just getting an error code where you might expect error text?
Try the above SQL in the Administrator client's command window, or in a telnet session to your project, and tell us whether it worked or not.

People in Japan should execute SELECT "DESC" FROM DS_RESJPN WHERE ERRNO = 2046;

[Gazelle]

Note that it has been a problem for both Server jobs and Parallel jobs.

From Administrator, the command:
SELECT "DESC" FROM DS_RESENU WHERE ERRNO = 2046;
returns
Finished waiting for job\n

I did notice one other code returned without text:
Missing StringID[2114]
so put this through Administrator:
SELECT "DESC" FROM DS_RESENU WHERE ERRNO = 2114;
returns
Job status\t:

Thanks,

- g

[ray.wurlod]

Resource files (for example DS_RESENU for English (United States), DS_RESJPN for Japanese) are the means by which messages to be emitted by DataStage are localized. Within DataStage every message is encoded, or tokenized, and the resource files are used to translate.

They are hashed files within the DataStage repository database. This is how they can be used for server jobs, parallel jobs, and everything else.

Another interesting factoid brought to you on DSXChange!

[Gazelle]

It continues to be an occasional problem.

Does anyone have any thoughts on why this occurs, and what we can do to prevent it from happening?

Thanks,

- g

[ray.wurlod]

My guess would be that you might be running out of hashed file descriptors in the T30FILE table occasionally, or maybe just taking a timeout accessing the resource file.

That said, I don't think it could be the latter, because this is a key-based access to a hashed file that is never updated and therefore never locked.

If it occurs again, you need to determine very quickly thereafter whether the T30FILE table is full, or nearly so. Use the UNIX command $DSHOME/bin/smat -d | wc -l and compare this with the T30FILE configuration parameter. But you probably won't be quick enough to see the true picture as at the time of the error.

[rbhudsuder]

Curious. "2046" does not appear in the source code for dsjob (see Appendix A, Server Job Developer's Guide).

The only 2046 in the resource table (DS_RESENU) carries the message "finished wa ...

It is in uvsh:

Code: Select all

strings -a /opt/dstage/Ascential/DataStage/DSEngine/bin/uvsh|grep StringID

prints

Code: Select all

Missing StringID[%u]

Question in short: is there some tunable parameter that eliminates this problem? (there is mentioning of some timeout in this discussion...)

[ray.wurlod]

You could try doubling T30FILE