Symptom

When you run a S2PX-generated Parallel job that incorporates the Char(expression) function (propagated from the Server Char(expression) function) you may experience situations where converting 8-bit numbers (i.e. values greater than 127) will fail to convert and instead return and empty string.

Cause

The Server function Char(expression) (IBM documentation here and here) returns the ASCII character from the numeric value of expression, including support for the translation of values larger than 127. The equivalent Parallel function (Char(%number%,[%allow8bits%]) does not translate values greater 127 without the use of the optional allow8bits parameter which needs to be set to True. E.g. ( Char(%number%, 1))

S2PX will propagate Server Char() calls to their identical Parallel equivalent, and will not introduce a value for the [%allow8bits%] parameter. When using the Parallel Char() function in this mode the the DataStage DSParams file maps the Parallel Char() function to the underlying C++ functions char_from_num() or u_char_from_num(). The behaviour of the DataStage logic used to selection which underlying implementation is unclear, but the fundamental problem is that only the char_from_num() function supports the allow8bits argument, while the u_char_from_num() doesn’t. This means that under certain (unclear) conditions the function’s type signature will not match, and you may get the runtime error The number of arguments must be 1. For example:

Solution

S2PX provides an Asset Query to let you know where you are employing a the Char() function, and consequently where you might experience functional errors in your solution due to the lack of inherent support for 8-bit characters. Where this Asset Query identifies calls to Char() you may wish to experiment with introducing the [%allow8bits%] parameter to the Char() call in the S2PX-generated Parallel equivalent job to see if that works for you, but bear in mind that you could receive a runtime error.