Moving Signed & Unsigned fields

[David Wall]

I'm desperately trying to get to be able to display comp fields in their normal format but have come across a problem.
I can move a numeric field : 9(9)v9(9) to an edited field 9(9).9(9) without problem.
But I get ' invalid source for move . cannot follow S ' when I try S9(9)v9(9) to S9(9).9(9)
but moving it to 9(9).9(9) is ok.
Could someone please explain ??. TIA

The end result I want is to get the original field S9... or 9... into an x(20) field but I get the error
invalid source for move IF I don't move it to the edited field first.

[David Wall]

And there appears to be nothing in the Programmers Guide saying it's illegal to have a . in a Signed field and move Signed data with implied decimal place into it.

[Vincent (Bryan) Coen]

On 06/01/2022 13:02, David Wall wrote:

And there appears to be nothing in the Programmers Guide saying it's
illegal to have a . in a Signed field and move Signed data with
implied decimal place into it.

Sorry are you saying you attempted to move a numeric value with no
decimal point i.e., 1234567  to a signed field and it did any thing
other than call it 1,234,567  ?

How else can you have a data field with implied other than using
12345.67 or the same in a field as pic s9(5)v99 -> 9(5).99-, etc.

It is NOT illegal as a programmer might want to do it despite not
getting the result they would like

Or am I getting the wrong end of the stick ?

Vince

[David Wall]

I don't understand what you are getting at Vince.

I moved a field described as 9(9)V9(9) to an edited field described as 9(9).9(9) with no error.
BUT
I moved a field described as S9(9)v9(9) to an edited field described as S9(9).9(9) with error.

The error given was that the receiving field was described with a . that followed an S

What I'm saying is that the Manual does NOT say having a. AFTER an S is illegal whereas the compiler giving an error seems to indicate that it IS an error.

I thought my original statement was reasonably understandable - but obviously not - sorry.

I've added a simple program demonstrating the error as well as the errors given.

[Simon Sobisch]

As you want to edit it S should not be used: You've possibly wanted +9(9).9(9)?

[David Wall]

Thanks Simon - I'll give that a go & see how we travel.

[David Wall]

OK - Now the line 9 & 17 errors have gone but I still can't move an implied decimal point to an alphabetic field - lines 14 & 16 still occur.
I know that error is the whole reason I'm moving the V field to the . field but it would still be nice if it could be done.
AND - I still believe the Manual should indicate that . cannot follow an S.
Thanks Simon.

[Simon Sobisch]

Reading by mail - what are lines 14+16?

Side note: To convert any text to any numeric field FUNCTION NUMVAL is quite useful... but a specific editing/de-editing should be possible, too. So I'm interested in "what works" and "what similar doesn't".

[Mickey White]

 1         IDENTIFICATION DIVISION.
 2         PROGRAM-ID. MOVETEST.
 3         DATA DIVISION.
 4         WORKING-STORAGE SECTION.
 5         01 FIELDA PIC 9(9)V9(9).
 6         01 FIELDB PIC 9(9).9(9).
 7         01 FIELDC PIC S9(9)V9(9).
 8         01 FIELDD PIC +9(9).9(9).
 9         01 FIELDE PIC X(20).
10         PROCEDURE DIVISION.
11             MOVE FIELDA TO FIELDB.
12             MOVE FIELDC TO FIELDD.
13             MOVE FIELDA TO FIELDE.
14             MOVE FIELDB TO FIELDE.
15             MOVE FIELDC TO FIELDE.
16             MOVE FIELDD TO FIELDE.
17             display 'a' fielda
18             display 'b' fieldb
19             display 'c' fieldc
20             display 'd' fieldd
21             display 'e' fielde
22
23             STOP RUN.

13: Warning: Move non-integer to alphanumeric
15: Warning: Move non-integer to alphanumeric

a000000000000000000
b000000000.000000000
c000000000000000000+
d+000000000.000000000
e+000000000.000000000

[David Wall]

I used Numval in a test but got some strange result moving one field to another.

1 MOVE '987654321.123456789' TO X FIELD >987654321.123456789
2 MOVE NUMVAL(XFIELD) TO ANOTHER X FIELD >00987654321123456789
3 MOVE NUMVAL XFIELD TO S9(9)V9(9) FIELD >987654321123456789
4 MOVE NUMVAL XFIELD TO 9(9).9(9) FIELD >987654321.123456789

Why the extra 2 x 0's on the output field line 2. ??

Sample prog attached.

[Ralph Linkletter]

9(9).9(9)-
9(9).9(9)+
9(9).9(9) sign is separate trailing / leading

Do any of these work ? I would think so

Ralph

[Vincent (Bryan) Coen]

Hell you are making me use my old memory banks :

Is the usage of S in a picture clause only for no-edited fields ?

Nuts going to have to check it :

According to one manual it is :

Numeric Date rules only the following chars is allowed in a PICTURE clause:

"9", "P", "S", and "V"

if unsigned the value can only be from numbers 0 - 9.
If signed the value can also  contain "+", " -" or other representation
of an operational sign,  CR, DB etc.

There is a bit more but got bored from typing.

Vince

mod edit to remove some reply-to