How to retain preceeding zeros in a decimal field?
Moderators: chulett, rschirm, roy
How to retain preceeding zeros in a decimal field?
Input field is a decimal (eg. 00012.)..
This is to be converted into integer, with the preceeding zeroes retained.
Does anyone have any solution for this...?
Thanks in advance.
This is to be converted into integer, with the preceeding zeroes retained.
Does anyone have any solution for this...?
Thanks in advance.
Hari
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
-
- Participant
- Posts: 12
- Joined: Wed Oct 03, 2007 9:11 am
- Location: London
Re: How to retain preceeding zeros in a decimal field?
Hari,hari4dsx wrote:Input field is a decimal (eg. 00012.)..
This is to be converted into integer, with the preceeding zeroes retained.
Does anyone have any solution for this...?
Thanks in advance.
Do you want to retain the preceding zero's in the output ?
if so use FMT function of BASIC Transformer
Regards
Raga
Raga
Re: How to retain preceeding zeros in a decimal field?
U can tryhari4dsx wrote:Input field is a decimal (eg. 00012.)..
This is to be converted into integer, with the preceeding zeroes retained.
Does anyone have any solution for this...?
Thanks in advance.
substr("00000":link.column,-5,5)
I have a baby
when is an integer not actually an integer?
I would suggest that your requirements are unclear.
In your situation, I would push back on my requirements
source and make them clarify what they mean by "integer".
If you are talking about hardware supported integers (which is
what technical people assume given the phrase "converted into
integer"), then leading zeros are always retained.
Your example used 00012. So if we encode that as a 16 bit integer,
you will get this somewhere on your disk:
0000 0000 0000 1110 (base-2)
Look at all those leading zeros.
Nice, aren't they.
And you get them for free simply by defining your target as type=integer.
(32-bit, 64-bit and larger integers are left as an exercise for the reader )
So in this case, you could go back to your source and
say "Yes we are retaining leading zeros."
But if they really need to see the zero characters (e.g. char( 48 ) )
then they really need some kind of CHAR type field that happens to
hold only digits but no decimal point.
If they expect binary coded decimals or some other kind of integer
encoding, then you have a similar situation.
It pretty much depends on what you mean by "integer format".
Good luck!
In your situation, I would push back on my requirements
source and make them clarify what they mean by "integer".
If you are talking about hardware supported integers (which is
what technical people assume given the phrase "converted into
integer"), then leading zeros are always retained.
Your example used 00012. So if we encode that as a 16 bit integer,
you will get this somewhere on your disk:
0000 0000 0000 1110 (base-2)
Look at all those leading zeros.
Nice, aren't they.
And you get them for free simply by defining your target as type=integer.
(32-bit, 64-bit and larger integers are left as an exercise for the reader )
So in this case, you could go back to your source and
say "Yes we are retaining leading zeros."
But if they really need to see the zero characters (e.g. char( 48 ) )
then they really need some kind of CHAR type field that happens to
hold only digits but no decimal point.
If they expect binary coded decimals or some other kind of integer
encoding, then you have a similar situation.
It pretty much depends on what you mean by "integer format".
Good luck!
hari4dsx wrote:Input field is a decimal (eg. 00012.)..
This is to be converted into integer, with the preceeding zeroes retained.
Does anyone have any solution for this...?
Thanks in advance.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
I'm surprised you didn't throw twos-complement versus ones-complement into that comprehensive discussion. Or Big-Endian versus Little-Endian (so that "leading" suddenly becomes problematic as a term).
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.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact: