View previous topic :: View next topic
|
Author |
Message |
Lingam D
New User
Joined: 07 Sep 2011 Posts: 8 Location: india
|
|
|
|
Hi
I need to convert a char field to float field using sort.
My input is like
Code: |
NY0.01897 color
ET1.34533 size
MW33.7899 size |
I need to convert 3-12(fixed) position to float.
I tried searching in the forum but could not find it. Please provide the sort card for this.
Code'd |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
if instead of the forums You had searched the manuals You could have stumbled on the FL format
but remember/consider that
FL deals only with the HEX float representation, not with the IEEE 754
better speak with the application designers to properly eviscerate the requirement |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Please use the Code tags to preserve spacing of your data.
Why do you want to convert it to a "float"? I know it is the "requirement" but why does someone think using a "float" will give you anything that you can't otherwise define?
If this is coming into your system, then it might "work" for you, if you are handing it off to something else (non-mainframe) it's asking for trouble. |
|
Back to top |
|
|
Skolusu
Senior Member
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
|
|
|
|
Lingam D,
TO=FL is not Supported. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
that' s what happens by looking only at one page of the manual !
the concerns about investigating the why and the format of the float representation still stands. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
Lingam D wrote: |
Hi
I need to convert a char field to float field using sort.
My input is like
Code: |
NY0.01897 color
ET1.34533 size
MW33.7899 size |
I need to convert 3-12(fixed) position to float. |
As Dr. Sorichetti and Sr. Woodger indicate, a true floating-point number (COBOL COMP-1 or COMP-2; PL/I FLOAT) is an extremely bad choice unless you are dealing with the sorts of widely varying magnitudes to be found in scientific programming. Even on this assumption, you do not have a character representation of a floating-point number (which would look something like 1.897E-2), but what may be called a "floating decimal point"; the decimal points are not all aligned, but "float" in the field according to the number of significant digits to their left.
(I also wonder why you consider the field to be positions 3-12, when 10-12 seem invariably to be blanks.)
I recommend that you limit your efforts to aligning the decimal points or, even better, allowing the consumer of these data to do so. |
|
Back to top |
|
|
|