How to convert Display Variable to Numeric Signed Variable
ChinmaYT
01 FIELD-A pic S9(3)V99 value 0.
01 FIELD-B pic +ZZZ.99.
I have a value in FIELD-B as -123.45
How can i move this value to signed variable?
MOVE FIELD-B TO FIELD-A is not working fine
neither i can perform ADD on FIELD-B as it is not numerica data item.
Thanks.
Keith Dick
You really must learn to give us a reasonable amount of information when you start your questions. It isn't so bad to play a game of 20 questions when you are asking questions in person, but it is very annoying when doing it via email. Gather all the information relevant to the question and put it into your first post.
In this case, show us the data in FIELD-B, preferably via some INSPECT command that displays the data without trying to interpret it, such as
DISPLAY FIELD-B WHOLE IN HEX
or whatever the syntax is that displays the field value in hex. That's the syntax for the old INSPECT, if I remember it correctly. If you are using Visual Inspect or Native Inspect, find the equivalent command. I'm not familiar with Native Inspect, but from looking at the manual, the command
x /8xb ADDRESS OF FIELD-B or maybe x /8bx ADDRESS OF FIELD-B
might be the way to display the raw value in hex (the manual is ambiguous about the order of the format and size). I don't know what it is in Visual Inspect and there is no manual on the web to look at.
Do the same for FIELD-A's value after the MOVE.
And if it isn't obvious what went wrong, tell us what you see as the incorrect result.
Then we'll have half a chance to help you figure out what the problem is.
The COBOL manual says that one may MOVE a numeric edited field to a numeric field, which is the situation you have for a statement such as MOVE FIELD-B TO FIELD-A with the above declarations, so it ought to work properly IF the data in FIELD-A matches the declaration. Show us the raw contents of the two fields and we should be able to make some progress.
Your statement that you can't ADD to FIELD-B as it is not numeric seems to match what the manual says about ADD. It says that ADD works only with numeric data items. That generally does NOT include numeric edited. So you must MOVE the data from the numeric edited field into a numeric field before using it in ADD or other arithmetic statements. After you do the calculation, you can MOVE the restult back to the numeric edited field. I can't tell you why the compiler won't do the conversion from numeric edited to numeric automatically when you use a numeric edited item in an ADD statement, but the manual says it doesn't, so I guess you will have to do the conversion to numeric before using it in ADD.
Perhaps that is the point of your first question. Perhaps your original problem was the inability to ADD with a numeric edited field and you are trying to MOVE to the numeric field so you can do some arithmetic. If that is the case, good -- you are on the right track. You recognized that is what you need to do. Now show us the contents of FIELD-B when it doesn't work, and we'll be able to help you figure out what is wrong.
Doug Miller
>
> 01 FIELD-A pic S9(3)V99 value 0.
>
> 01 FIELD-B pic +ZZZ.99.
>
>I have a value in FIELD-B as -123.45
>
>How can i move this value to signed variable?
(CAUTION -- untested)
01 field-b PIC +ZZZ.99.
01 field-b-redef REDEFINES field-b.
03 leading-sign PIC X.
03 integer-part PIC XXX.
03 FILLER PIC X.
03 fractional-part PIC XX.
01 field-c PIC S999V99 SIGN LEADING SEPARATE.
01 field-c-redef REDEFINES field-c.
03 leading-sign PIC X.
03 integer-part PIC XXX.
03 fractional-part PIC XX.
..
MOVE CORRESPONDING field-b-redef TO field-c-redef.
INSPECT integer-part OF field-c-redef
REPLACING ALL SPACES BY ZEROS.
Rich S
"MOVE FIELD-B TO FIELD-A" should work.
As Keith suggests, you probably have corrupt data in FIELD-B.
If you DISPLAY it in INSPECT, you should see: FIELD-B = "-123.45"
Keith Dick
That might be worth trying, but the way I read the manual, I think having spaces in the numeric edited field should be okay. The manual says that on a MOVE:
"If sender is numeric-edited, the operand�s unedited numeric value is determined
(it can be signed). The unedited numeric value of sender is moved to receiver."
The way I read that, if the contents of the sender can be produced by a valid MOVE into the numeric edited item, then MOVE will be able to figure out what the value is. Maybe it doesn't really mean that, but I think it does. If so, then the spaces shouldn't be the problem. That's why I want to see the raw contents.
Rich S
>
> >> 01 FIELD-A pic S9(3)V99 value 0.
>
> >> 01 FIELD-B pic +ZZZ.99.
>
> >>I have a value in FIELD-B as -123.45
>
> >>How can i move this value to signed variable?
>
> > (CAUTION -- untested)
>
> > 01 field-b PIC +ZZZ.99.
> > 01 field-b-redef REDEFINES field-b.
> > 03 leading-sign PIC X.
> > 03 integer-part PIC XXX.
> > 03 FILLER PIC X.
> > 03 fractional-part PIC XX.
> > 01 field-c PIC S999V99 SIGN LEADING SEPARATE.
> > 01 field-c-redef REDEFINES field-c.
> > 03 leading-sign PIC X.
> > 03 integer-part PIC XXX.
> > 03 fractional-part PIC XX.
> > ..
> > MOVE CORRESPONDING field-b-redef TO field-c-redef.
> > INSPECT integer-part OF field-c-redef
> > REPLACING ALL SPACES BY ZEROS.
>
> That might be worth trying, but the way I read the manual, I think having spaces in the numeric edited field should be okay. The manual says that on a MOVE:
>
> (it can be signed). The unedited numeric value of sender is moved to receiver."
>
> The way I read that, if the contents of the sender can be produced by a valid MOVE into the numeric edited item, then MOVE will be able to figure out what the value is. Maybe it doesn't really mean that, but I think it does. If so, then the spaces shouldn't be the problem. That's why I want to see the raw contents.
Right. Spaces are not a problem.
Moving 1.2 to FIELD-B in a test program and DISPLAYing in INSPECT
yielded: FIELD-B = "+ 1.20" (space between sign and number 1)
Moving FIELD-B to FIELD-A yielded: FIELD-A = 1.20
This was on G06.29 using both COBOL85 and NMCOBOL compilers.
Doug Miller
>ps.com>, ChinmaYT <chinma...@gmail.com> wrote:
>>
>> >> =A0 =A0 =A001 =A0FIELD-A =A0 pic S9(3)V99 value 0.
>>
>> >> =A0 =A0 =A001 =A0FIELD-B =A0 =A0 =A0 =A0pic +ZZZ.99.
>>
>> >>I have a value in FIELD-B as -123.45
>>
>> >>How can i move this value to signed variable?
>>
>> > (CAUTION -- untested)
>>
>> > 01 field-b-redef REDEFINES field-b.
>> > =A0 =A003 leading-sign =A0 =A0 PIC X.
>> > =A0 =A003 integer-part =A0 =A0 PIC XXX.
>> > =A0 =A003 FILLER =A0 =A0 =A0 =A0 =A0 PIC X.
>> > =A0 =A003 fractional-part =A0PIC XX.
>> > 01 field-c =A0 =A0 =A0 =A0 =A0 =A0 PIC S999V99 SIGN LEADING SEPARATE.
>> > 01 field-c-redef REDEFINES field-c.
>> > =A0 =A003 leading-sign =A0 =A0 PIC X.
>> > =A0 =A003 integer-part =A0 =A0 PIC XXX.
>> > =A0 =A003 fractional-part =A0PIC XX.
>> > ..
>> > MOVE CORRESPONDING field-b-redef TO field-c-redef.
>> > INSPECT integer-part OF field-c-redef
>>
>> That might be worth trying, but the way I read the manual, I think having=
> spaces in the numeric edited field should be okay. =A0The manual says that=
> on a MOVE:
>>
>> =A0 "If sender is numeric-edited, the operand s unedited numeric value is=
> determined
>> =A0 (it can be signed). The unedited numeric value of sender is moved to =
>receiver."
>>
>> The way I read that, if the contents of the sender can be produced by a v=
>alid MOVE into the numeric edited item, then MOVE will be able to figure ou=
>t what the value is. =A0Maybe it doesn't really mean that, but I think it d=
>oes. =A0If so, then the spaces shouldn't be the problem. =A0That's why I wa=
>nt to see the raw contents.
>
>Right. Spaces are not a problem.
>
>Moving 1.2 to FIELD-B in a test program and DISPLAYing in INSPECT
>
>Moving FIELD-B to FIELD-A yielded: FIELD-A =3D 1.20
>
>This was on G06.29 using both COBOL85 and NMCOBOL compilers.
You're all assuming that the OP has a Cobol85 program...
What if it's SCOBOL?
Rich S
Good point but it must be COBOL85/NMCOBOL since that MOVE statement
wouldn't compile in SCOBOL - ** ERROR 453 ** ILLEGAL SENDING OR
RECEIVING ITEM IN MOVE STATEMENT
Your suggestion also, in effect, assumes COBOL85 or NMCOBOL since
there is no INSPECT statement in SCOBOL.
Jerry
You could also use an intrinsic funtion like NUMVAL (chapter 14 in the cobol
manuals)
The manual is quite clear
DATA DIVISION
WORKING-STORAGE SECTION.
01 A PICTURE S99V99.
PROCEDURE DIVISION.
MOVE FUNCTION NUMVAL ("35") TO A.
DISPLAY A.
MOVE FUNCTION NUMVAL ("35.") TO A.
DISPLAY A.
MOVE FUNCTION NUMVAL ("35.75") TO A.
DISPLAY A.
MOVE FUNCTION NUMVAL (".35") TO A.
DISPLAY A.
MOVE FUNCTION NUMVAL (" - 35.75 ") TO A.
DISPLAY A.
MOVE FUNCTION NUMVAL (" 35.75 CR") TO A.
DISPLAY A.
Output:
35.00
35.00
35.75
00.35
-35.75
-35.75
Regards Jerry.
"Rich S" <richard...@gmail.com> schreef in bericht
news:aea52020-7a81-4bb9...@l25g2000yqd.googlegroups.com...
Frans Jongma
From what I remember from my old COBOL days, FIELD-B's purpose is to
get it nicely printed. It is an output-only field.
Therefore, if you want the numeric value of FIELD-B to appear in
FIELD-A, the correct thing to do is to revert to the original source
of FIELD-B.
Yes, there has to be a source, because numeric-edited field values do
not suddenly appear from nowhere.
Keith Dick
> Rich S <richard...@gmail.com> writes:
>
> From what I remember from my old COBOL days, FIELD-B's purpose is to
> get it nicely printed. It is an output-only field.
> Therefore, if you want the numeric value of FIELD-B to appear in
> FIELD-A, the correct thing to do is to revert to the original source
> of FIELD-B.
> Yes, there has to be a source, because numeric-edited field values do
> not suddenly appear from nowhere.
>
I imagine the purpose behind that is to permit taking input that was prepared in readable form, including spaces and decimal points, and being able to read it easily into your COBOL program, but that is just my guess. Whatever the reason, a numeric edited field is supposed to work as the source field of a MOVE in the way the original poster's program intended. I imagine the problem the original poster has is that the data in his input field does not conform to the picture of the field, but he has not yet responded with any more information about the problem, so we don't yet know what actually is causing his problem.
ChinmaYT
Again the same problem with me, data is being moved correctly but
inspect is not showing the correct data even enform is showing
incorrect.
Keith Dick
And again you haven't shown us any actual data, so again we cannot tell you what is happening.
Display the raw contents of the fields using the command I showed you in my first reply and post that here.