DSXchange

Hi Friends,
Does anyone ever receive the requirement on porting server functions such as ICONV, OCONV and FMT to PX? Although the replacement for them can be found in current PX package, I am just wondering if any client would be interested in seeing the one-to-one match for these functions between Server and PX, especially for those clients who want to convert the Server jobs to PX.
Any comment on this topic is appreciated...

Meaning what? You are volunteering to write them and donate them to the public domain? Trying to organize a grass roots campaign so IBM does that? Honestly curious here.

Typically not... ICONV and OCONV are use to convert to and from internal storage formats used by server jobs. Since PX jobs don't use those storage formats I've never seen a requirement to re-create the functionality.

I once started that effort but never got a chance to finish it. The thing is ICONV and OCONV are so vast, it takes uninterrupted, 101% dedication and effort to make such a conversion.

Just try to sense if there is even a need for this...
If there is , I don't mind doing that in my spare time since I have already done part of the functions for some clients and I have no problem to complete the full function...
As we all know, it's a long shot to get IBM act on it.

pneumalin wrote:Just try to sense if there is even a need for this...
If there is , I don't mind doing that in my spare time since I have already done part of the functions for some clients and I have no problem to complete the full function...
As we all know, it's a long shot to get IBM act on it.

Yeah, why not? I hope you post the translator version for PX soon.

Since thet source for ICONV and OCONV are in c, it would be much easier for IBM to adapt existing code than to rewrite the complete functionality. Albeit the time and date handling (with full NLS support) would be a great feature to add to PX and is currently sorely lacking.

If ICONV and OCONV are originally written in C in Server Edition, I agree it would make more sense for IBM to migrate them.
How about FMT?

Most of the interal functions in server edition are written in C. This includes FMT.

If this is the case, I shall advise IBM to migrate them.
Thanks everyone for your response...

I think the date functions inside ICONV and OCONV are most needed. Otherwise most of that is not needed. I think most FMT can be handled by string functions. Once in a while HEX and other similar conversions would be nice. They maybe there I have not looked. I have always pushed most of that off into the database which is not always a good idea.

The functionality of FMT may be available in new functions. However, the help is fairly poor on this subject. Would anyone be willing to post a reference between FMT and new Parallel functions?

Of course you can always drag the BASIC transformer from your repository onto the pallet and use the ICONV/OCONV/FMT variables.

Ray D

Dropping a BASIC transformer into a Parallel job will cripple your performance, as it will run sequentially on a single node (the conductor node) regardless of the degree of parallelism in use.

Personally I have yet to encounter a formatting problem that can't be solved with a Modify, printf or in some idiosyncratic cases, a parallel routine.

SettValleyConsulting wrote:Dropping a BASIC transformer into a Parallel job will cripple your performance, as it will run sequentially on a single node (the conductor node) regardless of the degree of parallelism in use.

That is not necessarily true. This stage type can run on multiple nodes in an SMP environment and (theoretically at least) all machines on which the server engine is installed.