Numeric Formatting

[SiouxCityElvis]

Hi everyone.
I'm running RMCOBOL-85 on Linux.

I noticed something yesterday when moving a alphanumeric field to a numeric formatted field.
Does a move statement from a PIC X to a PIC 9(8)V9(2) automatically get rid of commas from the PIC X?

Here's my code.

WORKING-STORAGE SECTION.

01  WS-CSV-AMOUNT     PIC  X(10).
01  NUMERIC-INTERMEDIATE-STEP PIC X(10).
01  NUMERIC-INTERMEDIATE-EDIT REDEFINES
      NUMERIC-INTERMEDIATE-STEP PIC Z(10).

01  WS-PAY-AMT-RFMT-B  PIC 9(08)V9(02).

PROCEDURE.
..
..
..
WS-CSV-AMOUNT gets populated with a 1,050.30

MOVE WS-CSV-AMOUNT TO NUMERIC-INTERMEDIATE-STEP.
MOVE NUMERIC-INTERMEDIATE-EDIT TO WS-PAY-AMT-RFMT-B.
...
...
..

Then WS-PAY-AMT-RFMT-B is put into a record's field with the same format. Later, another program writes records out to a flat file showing the amounts without the decimals. In this case, for some, reason, the comma in the 1,050.30 does not cause any sort of problem. It seems to be handled implicitly somehow - I'm curious, How?

Thanks.
-David

 

[COBOLKenny]

It's probably the de-editing feature. You can move a numeric-edited item to a numeric item and it will strip out the punctuation in the field and store it the way you are seeing.

 

[fredericofonseca]

As mentioned on other threads here before, this is a functionality of RM/COBOL.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[k5tm]

Actually, it is functionality that is required by the 1985 ANSI COBOL standard. The unfortunate part is that the ANSI standard did not stipulate any rules for the de-edit.

We adopted a rather relaxed set of rules which matched our de-edit conversion on ACCEPT. Frankly this made the most sense and provided a lot of flexibility for circumstances such as this one. Other vendors seem to want to involve the edit picture during the de-edit process, but we could never arrive at a set of de-edit rules that dealt rationally with insertion characters, etc. (E.g. is a zero that appears in the actual data in the character position of an insertion zero really a zero? And is a non-zero digit that appears in the character position of an insertion zero really non-zero?)

Tom Morrison

http://www.liant.com

 

[WMK]

Tom,
Are you certain that the '85 Standard requires this on a move from an ALPHANUMERIC to NUMERIC field? (See original post). I don't think so, but I could be mistaken.

Bill Klein

 

[k5tm]

Bill,

I can't help smiling.

(See original post).

It isn't an alphanumeric source after all... (Hint for lurkers: check the REDEFINES.)

Tom Morrison

http://www.liant.com

 

[WMK]

The first move

MOVE WS-CSV-AMOUNT TO NUMERIC-INTERMEDIATE-STEP.

is UNDEFINED in the '85 Standard. The only time an alphanumeric sending field is DEFINED (in the '85 Standard) when moved to a numeric or numeric-edited field is if the sending field is an unsigned integer (with no spaces).

This issue was "discussed" and resolved via "interpretation". See:

CIB-26, page 64, Interpretation A-286

(This is probalby too obscure a reference for most people.)

Bill Klein

 

[WMK]

Sorry folks, my last update was wrong. I missed which one was moved to which.

The reason *THIS* code is undefined is that you have a field

NUMERIC-INTERMEDIATE-EDIT ... PIC Z(10).

with contents of

1,050.30

This falls into the "incompatible data" rules and is undefined for THAT reason.





Bill Klein

 

[k5tm]

Bill is correct, but I believe that our implementation (described above) predates the "obscure" committee interpretation that made it "incompatible data". Neither the interpretation or the new 2002 standard addresses the issue I raised above about the correct interpretation of insertion zeroes (or did I miss that somewhere?). The de-edit MOVE was thereby rendered virtually useless and should have been removed from the 2002 standard, in favor of the NUMVAL function, which provides a superset of functionality.

But for David, an RM/COBOL user, the functionality remains as determined by a bunch of Liant (nee Ryan McFarland) developers way back in 1985.

Tom Morrison

http://www.liant.com

 

[WMK]

Although this is fairly obscure for many of those in this forum, I did want to clarify the question that Tom raised about whether or not the 2002 Standard "cleared" up the rules for numeric-edited to numeric de-editing when the contents fo the sending item don't match the picture clause.

The answer is YES - the following quotes should help readers of this forum see both the change and that the committees knew it was a "substantive change"

From the 2002 Standard, Substantive change 24 starting on page 817

24) Incompatible data. The conditions that cause the incompatible data condition are specified explicitly. They are limited to boolean, numeric, and numeric-edited sending operands.

Justification:
In the previous COBOL standard, the rules for incompatible data stated that when the content of a data item was referenced and the content of that data item was not compatible with the class specified by its PICTURE clause, then the result of that reference was undefined. There were no rules specifying when the content of a data item was referenced or when this caused the incompatible data condition. This determination was left to each implementor and the incompatible data condition may have been given in circumstances different from those now specified..

This International Standard defines when incompatible data is detected, thereby increasing the degree of program portability. The EC-DATA-INCOMPATIBLE exception condition, which is part of the new common exception processing, gives programmers control over the handling of the exception.

This change was made as a result of a request for an interpretation of the previous COBOL standard. It is believed that few, if any, programs will be affected by this change.

From page 398

14.5.12.2 Incompatible data
...
2) When a numeric-edited data item is the sending operand of a de-editing MOVE statement and the content of that data item is not a possible result for any editing operation in that data item, the result of the MOVE operation is undefined and an EC-DATA-INCOMPATIBLE exception condition is set to exist.

...

Having said that, no ask me if there is now or soon will be a "2002 Standard conforming compiler" and if not, why should a programmer care about this rule?

Furthermore, ask me if I think that if Liant (or any other vendor) that works differently than this today ever DOES provide a 2002 conforming compiler, do I think they won't provide at least an OPTION to work as they do today.

On the other hand, this wording is an indication of how those forming the 2002 Standard *thought* they wanted the '85 Standard de-editing to work.

Bill Klein

 

[k5tm]

Okay, Bill, I will then ask the question in this way:

The contents of a data item described with [tt]PIC 90909090[/tt] is 10203040. When de-edited, the numeric value is:[ul square][li]1234[/li]
[li]10203040[/li]
[li]all of the above [/li]
[li]none of the above.[/li][/ul]
Please explain your answer.

Tom Morrison

http://www.liant.com

 

[WMK]

In the 2002 Standard, the relevant rule (for MOVE) is on page 479 which states (in part),

When the sending operand is numeric-edited, de-editing is implied to establish the operand's unedited numeric value, which may be signed; then the unedited numeric value is moved to the receiving field.

So, given your question if you had

01 Num-Ed PIC 90909090 Value "10203040".  
01 Num1   Pic 9(7)     Value  10203040.
01 Num2   Pic 9(4)     Value 1234.
   ..
Evaluate True
 When Num-Ed = Num1
       Display "Use 10203040 for sending value"
 When Num-Ed = Num2
       Display "Use 1234 for sending value"
 When other
       Display "Use something else for sending value"
End-Evaluate

What would your compiler (and run-time) display?

Does this answer FOR YOU what the 2002 Standard wants you to do?

Bill Klein

 

[k5tm]

Bill,

At the risk of being pedantic...

What would your compiler (and run-time) display?

First, this is not a MOVE statement, and is not therefore pertinent. Second, it diagnoses the disagreement in [tt]Pic 9(7) Value 10203040[/tt]. Having corrected that, at runtime it chooses the first WHEN.

Does this answer FOR YOU what the 2002 Standard wants you to do?

If this example were changed to use MOVE, it still would not answer the question.


In order to get a result of 10203040 in a [tt]PIC 90909090[/tt] item, one would have to store (via MOVE or an arithmetic statement) the value 1234 in that item. So, should the de-editing MOVE return a value of 1234, or should it return a value of 10203040 (which is what NUMVAL would return, I think)? The standard explains how insertion zeros work when storing, but it has been and remains silent on the de-edit side, as far as I can tell.

Tom Morrison

http://www.liant.com

 

[WMK]

I don't understand your point. The 2002 Standard (I haven't checked the wording of the '85 Standard) seems clear enough to me that it uses the numeric value. That is why I gave the EVALUATE example.

There is no "implication" (that I can see) that a de-editing move is the reverse of an editing move to that same field. (Possibly the "name" is confusing").

When it says

unedited numeric value

that is really what it means. That is NOT the same thing as saying something like the "value that would be used to populate this field via a move statement"

Bill Klein

 

[k5tm]

Okay, now we are getting to the point. Consider:

01  num-edit-1    pic 90909090.
01  num-edit-2    pic 9/9/9/9/.
01  a-value       pic 9(8).
...
    move 1234 to num-edit-1, num-edit-2.
    move num-edit-1 to a-value.
    display a-value.
    move num-edit-2 to a-value.
    display a-value.

Will the display statements show the same value, or two different values. I take it from your previous answer that you would expect two different values.

But the 2002 standard says:

When the sending operand is numeric-edited, de-editing is implied to establish the operand's unedited numeric value, which may be signed; then the unedited numeric value is moved to the receiving field.

Why would the 'unedited numeric value' of these two fields be different when the edit picture differs only in the insertion character? What does 'de-editing is impled' really mean?

Tom Morrison

http://www.liant.com

 

[WMK]

Just an update (and correction). After communicating off-line with some J4 members (and Tom), The following seems to be the consensus as to what both the '85 and '02 Standard "means" (and what most members of J4 - but not everyone who reads it - think is "clear").

If you have

05 NumEd1  Pic  990  Value "120".
05 NumEd2  Pic  9/9  Value "1/2".

That de-editing BOTH fields will yield the numeric value "12".

For the first of these two, it is definitely (and intentionaly) a different value than that created by the NumVal intrinsic function (which is "120").

Bill Klein