Need help with edited fields

[sharlas]

I'm reading this file where the data is written to the file in
edited numeric fields like:

01 Data.
03 Data_a pic -9(13)V(2).
03 Data_b pic -9(13)V(2).
03 Data_c pic -9(13)V(2).
03 Data_d pic -9(13)V(2).

so when the value -2542,23 is stored in
Data_a it looks in the file like this:
-000000254223

My intention is to read the data to a similar edited fields like:
01 Datax.
03 Datax_a pic -9(13)V(2).
03 Datax_b pic -9(13)V(2).
03 Datax_c pic -9(13)V(2).
03 Datax_d pic -9(13)V(2).

Then I try to move for example the Datax_a-field
to this edited field:

01 Edited_b pic -B---B---B---B--9,99

so that when we print the value it should look like this

-2 542,23

And this is were it all goes wrong. When I move the edited
Datax_a -field to Edited_b it looks like:
-25,42
So where did my decimal part go? It looks like that only
the integer part has been move to Edited_b and it's in the wrong
place.

I've also tried to move the Datax_a first to pic s9(13)V(2) and then
to Edited_b with no luck. I've also tried to make Edited_b bigger and smaller,
added and removed those minus signs and B's, but nothing really helps.

Sorry for my bad English,

thanks in advance

Sakke

 

[fredericofonseca]

That will work well with RM/COBOL-85 so please post your program and cobol vendor and version.

this is the output of the following program for a datafile with the following values.

-00012012391-00120034391-00000142391-12345678912-00000058791

-----
-120 123.91
-1 200 343.91
-1 423.91
-123 456 789.12
-587.91
-----
Code at the end of this.


Tom and Bill,
As I have never used a variable this way I wonder if the sign is positioned correctly on line 1,4 and 5.
The reason why I ask is that there is a B on that particular position, and I would expect the sign to be separated by one space on those 3 cases. (no I did not look at the standard to see if it should work like this)
Clarify me if possible.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. PGM1.
       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.

            SELECT MAPA ASSIGN TO DISK
                       "numbers.lst"
                   ORGANIZATION LINE SEQUENTIAL.

       DATA DIVISION.
       FILE SECTION.

       FD MAPA    LABEL RECORD OMITTED.
       01 REC1.
          05 f1 pic -9(9)V99.
          05 f2 pic -9(9)V99.
          05 f3 pic -9(9)V99.
          05 f4 pic -9(9)V99.
          05 f5 pic -9(9)V99.

       WORKING-STORAGE SECTION.
       01  numedit pic -B---B---B---B--9.99 value zero.
       PROCEDURE DIVISION.
       01  numedit pic -B---B---B---B--9.99 value zero.
       PROCEDURE DIVISION.
       INIC.
           OPEN INPUT  MAPA.
           READ MAPA
           move f1 to numedit
           display    numedit
           move f2 to numedit
           display    numedit
           move f3 to numedit
           display    numedit
           move f4 to numedit
           display    numedit
           move f5 to numedit
           display    numedit.
           CLOSE MAPA.
           GOBACK.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[sharlas]

The sign floats just next to the first
significant digit. So the B puts a space there only when there's a number in that position.

I'm not currently at work right now, so I can't tell you the exact version, but It's 85-something on VMS/ALPHA.

Your example shows just that what I'd like my program to do, but it doesn't. It just keeps cutting the decimal part and moves two digits from the integer part to the receiving fields decimal part. So your programs first value gives an output: -1 201.23

Well, then I have this second problem I've been wondering, that is how do I convert this edited output from that numeric field to an alphanumeric field. Do I just move it to an pic x(16) or something or could I make a redefine like:
01 num.
03 numedit pic -B---B---B---B--9.99 value zero.
03 numedit2 redefines numedit pic x(16).

Will this work? How many characters should there be when the sending field is signed and has 13+2 digits. Is x(16) enough?

I have to use the edited value in
an STRING like this:
STRING
"@@@" DELIMITED BY SIZE
numedit2 DELIMITED BY SIZE
"@@@" DELIMITED BY SIZE

Then I write this string to another file.
So the final output should be something like this:
@@@ -120 123.91@@@
where that whole string is alphanumeric.

 

[fredericofonseca]

Sharlas,

On your example you are using "," (comma) as a decimal separator. If you are not using the special names to tell the program that this is the decimal separator then you get that result.

If you look at my example I did use the default decimal separator of "." (decimal point), and thus it works as expected.

As for moving from "123 345.11" to a valid numeric field once again with RM/COBOL it works fine if you just define the fields as a numeric edited (such as you have) and move it to a non edited numeric field.

E.g. from my program just create another variable "S9(12)V99" and move numedit to it. The value will be correct in all cases.

As I said before please post your program.




Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[sharlas]

Yes it's that DECIMAL POINT AS COMMA -declaration in the special names -section. We use comma instead of point as decimal separator here in Finland. I'll check that from my program on Monday and post the whole program if the problem isn't solved yet.

Thanks for your help!

Regards

Sakke

 

[k5tm]

Frederico,

Sakke is correct. Your use of multiple '-' editing characters makes the '-' a floating rather than an insertion editing character. You get the same behavior as ---,---,--9.99 (using ',' as the thousands separator, and '.' as the decimal point). The ',' is an insertion character, and the floating character has higher priority. It is explained in the 1985 standard using a big grid (state table?). The key to understanding the grid is understanding the dual role of characters as both insertion and floating editing characters.

It will be interesting to see what Sakke determines about DECIMAL POINT IS COMMA.

Tom Morrison

http://www.liant.com

 

[slade]

I would have thought that -000000254223 should be defined as a numeric item with a "sign is leading separate" clause, not a numeric edited item with a floating sign. Or does it matter?

Regards, Jack.

 

[fredericofonseca]

Tom,

Thanks for the info. Now that I look at your example (--,--) I laugh, as I do use it like that

Slade,

With RM/COBOL it doesn't matter for this case.
That is the way I would use it though.


Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[WMK]

When "decimal point is comma" is specified, then I think that the move to a

01 Edited_b pic -B---B---B---B--9,99

field SHOULD work as desired. (of course, I would use "-" not "_" in the data name, but that should be irrelevant).

I will be interested in Tom's next update - as it LOOKS to me like a "bug in the compiler" if it isn't "correctly" moving a "V" to the "," in the move.

Bill Klein

 

[k5tm]

Bill,

It would be exactly the correct behavior if the

DECIMAL POINT IS COMMA

is not specified, however.

We await the answer from Sakke.

Tom Morrison

http://www.liant.com

 

[sharlas]

Hi,

Everything works just fine now! I added that DECIMAL POINT IS COMMA -clause to the special names section and the move from pic -9(9)V(2) to -B---B---B---B--9,99 is working properly now. I'll have to remember that next time.

Thanks for the help Frederico!

Sakke

 

[3gm]

slade -

As a design point, I agree with you. Defining the input field as an edited numeric is not good practice. It requires a de-editing move to use it. I don't believe that it can be used directly in an arithmetic expression for instance.

Regards.

Glenn

 

[k5tm]

Glenn,

That is correct.

MOVE

only.

Tom Morrison

http://www.liant.com

 

[WMK]

For any '85 Standard compiler, a numeric-edited field may be used as the RECEIVING field in an arithmetic statement.

For any compiler with the '89 Standard Intrinsic Function module, they may also be used as "sending" items in arithmetic statements - by the use of the NumVal (or NumVal-C) intrinsic functions.

I believe that this thread (at least started) as being for a compiler withOUT the full intrinsic function module - but I did want to make it clear that for many environments numeric-edited fields MAY be used in arithmetic expressions.

Bill Klein