Anyone interested in using ICONV, OCONV and FMT in PX
Moderators: chulett, rschirm, roy
Anyone interested in using ICONV, OCONV and FMT in PX
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...
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...
Pneuma Lin.
pneumalin@yahoo.com
pneumalin@yahoo.com
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.
Last edited by asorrell on Wed Mar 10, 2010 11:15 am, edited 1 time in total.
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.
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.
Pneuma Lin.
pneumalin@yahoo.com
pneumalin@yahoo.com
Yeah, why not? I hope you post the translator version for PX soon.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.
gateleys
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?
How about FMT?
Pneuma Lin.
pneumalin@yahoo.com
pneumalin@yahoo.com
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
If this is the case, I shall advise IBM to migrate them.
Thanks everyone for your response...
Thanks everyone for your response...
Pneuma Lin.
pneumalin@yahoo.com
pneumalin@yahoo.com
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.
Mamu Kim
-
- Premium Member
- Posts: 72
- Joined: Thu Sep 04, 2003 5:01 am
- Location: UK & Europe
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.
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.
Phil Clarke
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.