Change display format from character mode to numeric mode

Question

The value in variable VAR is -1, and when I am trying to write to a file, it gets displayed as J(character mode), which is equivalent to -1.

The VAR is defined in Cobol program copybook as below:
10 VAR PIC S9(1).

Is there any way, to change the display format from character "J" to -1, in the output file.

The information which I found by googling is below:
Value +0 Character {
Value -0 Character }
Value +1 Character A

To convert the zoned ASCII field which results from an EBCDIC to ASCII character translation to a leading sign numeric field, inspect the last digit in the field. If it's a "{" replace the last digit with a 0 and make the number positive. If it's an "A" replace the last digit with a 1 and make the number positive, if it's a "B" replace the last digit with a 2 and make the number positive, etc., etc. If the last digit is a "}" replace the last digit with a 0 and make the number negative. If it's a "J" replace the last digit with a 1 and make the number negative, if it's a "K" replace the last digit with a 2 and make the number negative, etc., etc. Follow these rules for all possible values. You could do this with a look-up table or with IF or CASE statements. Use whatever method suits you best for the language you are using. In most cases you should put the sign immediately before the first digit in the field. This is called a floating sign, and is what most PC programs expect. For example, if your field is 6 bytes, the value -123 should read " -123" not "- 123".

Answer 1

It might be simpler to move it to an EBCDIC output (display) field so that its just EBCDIC characters, and then convert that to ASCII and write it.

For example

10 VAR        PIC S9(1).
10 WS-SEPSIGN PIC S9(1) SIGN IS LEADING SEPARATE.
10 WS-DISP    REDEFINES WS-SEPSIGN 
              PIC XX.

MOVE VAR TO WS-SEPSIGN.   

Then convert WS-OUT to ASCII using a standard lookup table and write it to the file.

Answer 2

If you are sending data from an EBCDIC machine to an ASCII machne, or vice versa, by far the best way is to only deal with character data. You can then let the transfer/communication mechanism do the ASCII/EBCDIC translation at record/file level.

Field-level translation is possible, but is much more prone to error (fields must be defined, accurately, for everything) and is slower (many translations versus one).

The SIGN clause is a very good way to do this. There is no need to REDEFINES the field (again you get to issues with field-definitions, two places to change if the size is changed).

There is a similar issue with decimal places where they exist. Where source and data definitions are not the same, an explicit decimal-point has to be provided, or a separate scaling-factor.

Both issues, and the original issue, can also be dealt with by using numeric-edited definitions.

01  transfer-record.
    ...
    05  numeric-edited-VAR1 PIC +9.
    ...

With positive one, that will contain +1, with negative one, that will contain -1.

Take an amount field:

01  VAR2 PACKED-DECIMAL PIC S9(7)V99.
...
01  transfer-record.
    ...
    05  numeric-edited-VAR2 PIC +9(7).99.
    ...

For 4567.89, positive, the new field will contain +0004567.79. For the same value, but negative, -0004567.79.

The code on the Source-machine is:

MOVE VAR1 TO numeric-edited-VAR1
MOVE VAR2 TO numeric-edited-VAR2

And on the target (in COBOL)

MOVE numeric-edited-VAR1 TO VAR1
MOVE numeric-edited-VAR2 TO VAR2

The code is the same if you use the SIGN clause for fields without decimal places (or with decimal places if you want the danger of being implicit about it).

Another thing with field-level translation is that Auditors don't/shouldn't like it. "The first thing you do when the data arrives is you change it? Really?" says the Auditor.