Numeric-edited fields problem. 4

[andreymurom]

Hello everybody,

My program uses 2 fields that are passed parameters from another another program where they are defined as a character fields. The data in these fields is numeric and I want to do some numeric operations on them.

They are defined as:
01 PGM-PARM.
...
05 FROM-AMT PIC -(8)9.
05 TO-AMT PIC -(8)9.
...

Then I have temporary numeric fields in the program (Thank you very much, Betty Scherber, for the great advice! It's worked.):

01 FROM-AMT-NUM PIC S9(9).
01 TO-AMT-NUM PIC S9(9).

Then I move parms into the numeric fields:

MOVE FROM-AMT TO FROM-AMT-NUM.
MOVE TO-AMT TO TO-AMT-NUM.

There is no problem with the negative numbers coming from the calling program. But when it moves positive numbers it gives an error:

Message . . . . : Floating character in numeric-edited sending field at statement 414 was not valid (C D F G).
Cause . . . . . : During the de-editing of a numeric-edited field containing the floating PICTURE character +, -, or $, a leading floating character was not found, or it was located at the wrong position in the field.

The value in the sending field when this happens looks like : "000001000".

Thank you

 

[StephenJSpiro]

COMP-3 is implementor defined in ALL cases. It is not even mentioned in the Standard.
PACKED-DECIMAL is COMP-3 in the IBM world, and, according to the standard, it's internal representation is implementor-defined.
As I mentioned in a previous post, on the IBM Mainframe all PACKED-DECIMAL/COMP-3 fields have a sign nibble, even if unsigned.

The internal representation of
PIC 9(6) VALUE 123,456 PACKED-DECIMAL
or
PIC 9(6) VALUE 123,456 COMP-3
is X'0123456F'

The internal representation of
PIC S9(6) VALUE +123,456 PACKED-DECIMAL

PIC S9(6) VALUE +123,456 COMP-3
is X'0123456C'

The internal representation of
PIC S9(6) VALUE -123,456 PACKED-DECIMAL
or
PIC S9(6) VALUE -123,456 COMP-3
is X'0123456D'

The zero is inserted to make an even number of nibbles, and 4 full bytes.
(A nibble is a half of a byte.)

1,234,567 would also occupy only 4 bytes:
X'1234567F'

Note that in NCR COBOL, and in some others, a PACKED-DECIMAL field with an odd number of digits can end IN THE MIDDLE OF A BYTE! and the next field can start IN THE MIDDLE OF THE SAME BYTE!

Some implementors have no sign character on an unsigned, packed number. Some have the sign first. It is all IMPLEMENTOR-DEFINED.
And PACKED-DECIMAL is not necessarily COMP-3; that is also implementor defined.

Stephen J Spiro
Member, J4 COBOL Standards Committee
ANSI/ISO

 

[NinaToo]

Stephen, thanks.

Let me see is I have this correct:

PIC 9(6) COMP-3 has 4 bytes. There is a sign nibble, but it (along with the 0 which is a filler) doesn't take up a byte?

And PIC S9(6) COMP-3 has 4 bytes, but the sign does takes up a byte?

Now for more pesky questions.

PIC 9(6) COMP takes up 3 bytes, correct?

PIC S9(6) COMP takes up 3 bytes, but the sign uses up one of them? Or not?

What are the advantages of using either COMP or COMP-3 in your numeric fields?

Thanks, Nina Too

 

[slade]

Hi Nina,

Let's look at this from 2 perspectives:

1) Memory - any 6 digit COMP-3 fld will take up 4 bytes of storage. Unsigned gets an "F" nibble for the sign, positive signed gets "C", negative signed gets "D". In all cases a leading zero nibble is added because adding the sign advanced the fld len to 3.5 bytes, a nono; it must be rounded up to a full byte.

2) Arithmetic - The compiler will construct instructions to manufacture a result assuming 6 digits in the field. The "inefficiency" results from the fact that instructions are used to "simulate" a 6 digit field, where in fact, memory contains a 7 digit field.

You also ask about the advantages of COMP & COMP-3:

Obviously they save external storage space. Not too important now, but back in the days of $100/meg (or was it $1000?) it was. Very!

They also save compute cycles by eliminating the instructions required to put them in a form required by the assembler language to do arith. BAL can only do packed dec and binary arith.

If you specify LIST,NOOFF as part of your compiler options you will get, as part of your compiler O/P, a list of the BAL instructions generated for each of your COBOL stmts.

As a test you can add 2 display flds, 2 comp flds, 2 comp-3 flds, and see the code generated for each.

Hope this helps, Jack.

 

[StephenJSpiro]

"PIC 9(6) COMP-3 has 4 bytes. There is a sign nibble, but it (along with the 0 which is a filler) doesn't take up a byte"
6 digits at 2 characters per byte is 3 bytes, plus a half-byte for the sign (X'F'), and a half-byte filled in with a zero equals 4 bytes.

"And PIC S9(6) COMP-3 has 4 bytes, but the sign does takes up a byte?"
The same as unsigned, but the signs are X'C' or X'D'.

"PIC 9(6) COMP takes up 3 bytes, correct?"
COMP is BINARY (or hexadecimal, which is really the same thing, hex is 2 to the 4th power). On machines with 32-bit words (most computers), and in all COBOL compilers of which I am aware, COMP (BINARY) fields MUST be stored in multiples of half-words. Each half-word contains 2 bytes.
{32 bits = 1 fullword = 2 half-words = 4 bytes = 8 hex characters (or nibbles).}
Therefore PIC 9(6) COMP
or PIC 9(6) BINARY
will occupy one fullword (4 bytes).
Truncation and alignment rules come into play with COMP (BINARY) fields; check your manual.

"PIC S9(6) COMP takes up 3 bytes, but the sign uses up one of them? Or not?"
In a signed binary field, the sign is the high order bit. 0 is positive, 1 is negative.
That's BIT, not byte!

For more information on Binary numbers, see

http://www.cs.colorado.edu/~l3d/courses/CSCI1200-96/binary.html

Binary numbers are stored in different ways on different machines. See

http://www.hive.speedhost.com/code5.htm

for a discussion of "big-endian" and "little-endian". Little-endian binary numbers are usually COMP-5.

Which one is best depends on the architecture of the machine; what does it use for "native" arithmetic. IBM mainframes use PACKED-DECIMAL (comp-3); IBM AS/400 (I believe) uses BINARY (COMP). Intel-based PC's use COMP-5.

Stephen J Spiro
Member, J4 COBOL Standards Committee

 

[NinaToo]

Thanks, both of you. I'll be copying and storing away these instructions in a safe place. I've always been confused about these.

Nina Too