Numeric Data Movement - To A COMP Variable

Numeric Data movement - to a COMP
variable
Table of contents
Background
Section 1: Re-looking at the Background
Section 2: Data storage in PIC S9(01) COMP thru PIC S9(09) COMP Sample Programs
Section 3: Observation of Data storage in PIC S9(01) COMP thru PIC S9(09) COMP
Section 4: Conclusion on PIC S9(01) COMP thru PIC S9(09) COMP
Section 5: Effect of ARITH(EXTEND)
Section 6: Effect of TRUNC(BIN) or TRUNC(STD)
Section 7: HEX ON analysis
Section 8: What would happen if COMP variable had a fractional part?
Section 9: Answered Questions
Section 10: Practice Questions
Background
Have you ever thought/checked/observed what would happen if we replaced a PIC S9(04) COMP variable that is used for computation with, say
PIC S9(01) or PIC S9(02) COMP??
Have you ever thought/checked/observed whether any other COMP variable can do same things that most commonly used COMP viz. PIC
S9(04) COMP - can do??
Have you ever thought/checked/observed what would happen if in linkage section of a cobol program (that received data from jcl) if we coded
length variable, not as PIC S9(04) COMP but as PIC S9(2) COMP or PIC S9(08) COMP or PIC 9(02) COMP etc, say??
Have you ever thought/checked/observed if there is a significance as to why DB2 converts, during DCLGEN process, SMALLINT to PIC S9(04)
COMP and INTEGER to PIC S9(09) COMP??
Have you ever thought/checked/observed what maximum value PIC S9(0N) COMP (N = 1 thru 18) can hold in itself??
Have you ever thought/checked/observed whether PIC S9(08) COMP, say, can only store up to 8 digits, or can it store more as well?
Are you sure if PIC S9(N) COMP can only store up to N digits?
Have you ever checked/observed differences between HEX values stored in a signed COMP vs an unsigned COMP?
Have you ever checked/observed the behavior of a COMP field if it is declared with a decimal part?
..and so on. All these questions are focused around a numeric data type USAGE COMPUTATIONAL or COMP, in short. Generally, COMP poses challenge for
most of us. It is not primarily because it is difficult to understand it (as literature is available) but because it is not further looked or researched into. This
research is extremely important to become more familiar with the subject. Literature normally caters well to the needs of what is generally observed, and,
therefore, we tend to stick to what it provides.
The below scenario that appeared triggered dwelling deeper into behavior of COMP fields.
Project scenario:
There was this file had a field that was defined as PIC S9(04) COMP. It received 4-digit values in it. A process consisting of a few jobs created
this file. This file, in turn, served as input to a subsequent process.
As part of change in requirement, it was expected that 5-digit numbers would start coming to the file variable. In the file PIC S9(04) COMP was
getting changed. It was decided to change it to PIC S9(05).
PIC S9(04) COMP --- PIC S9(05)
Another team made changes to the programs executing in jobs that created this file.
Our team needed to carry out impact analysis on the programs that read data from this file and proceed further.
In one of the programs, numeric variables (defined in working-storage section as PIC S9(04) COMP) received and computed very well values
that they got from this file variable. So, PIC S9(04) COMP on these working-storage variables was expected to be changed to PIC S9(05), to be
able to process all 5-digit numbers. Design document was completed and handed over to developer. Developer made following 2 errors in
coding.
a.
Variable1: it was changed from PIC S9(04) COMP - PIC S9(04). He just dropped the COMP but did not change 04 to 05.
b. Variable2: He did not make any change (overlooked to make the change).
Naturally, errors were found during testing phase. Testing was carried out using many 5-digit numbers (as test cases). This led to analyzing data
movement to COMP.
Many study gates were open during this research and later on. A few compiler options came up for
study in order to understand behavior of COMP fields.
Caution: This document only discusses behavior of following types of numeric data types vis--vis compiler
options
COMP
DISPLAY
COMP-3
So, please read through the document keeping this in mind
The document may appear lengthy, but information in it is categorized, to an extent, so as to help grasp it effectively. Any suggestions to
make the document more concise are most welcome. Also, proof-reading has not been carried out deeply. So, some mistakes might have
inadvertently crept. If you notice any, please inform.
So, let us understand the COMP in greater detail.
COBOL behaviour is deeply governed by how we compile it. And, this makes having knowledge of compilation
parameters more important. Though on majority of times, they do not lead us to problems, knowledge of them
can be handy, and can help solve many unwanted scenarios, which may be very difficult to solve without their
knowledge, and we may spend days to search for reason. Two compiler parameters are also discussed while
analyzing COMP - ARITH, TRUNC
Also, as you read on, associated with a data item keep these two important things in mind:
1. Rule for size of Memory allotment to a data item let us call it memory size allotment rule.
2. Rule for what data this memory can accept Let us call it data limit acceptance rule.
These are two different rules. Many times we confuse memory and data to follow one rule. This is because of the misconception that we think
memory location and its data storing capability have a single rule to follow. This is not true. There are 2 rules one rule that governs size of
memory allotted to a data item, and a second rule (a totally separate rule), that determines what can go inside this memory, and what cannot
go inside this memory.
It is like this. We may have a big room A that permits boxes of small and big sizes. Whereas another room B (of same size) may put a rule that
only small boxes are permitted. Due to this restriction boxes of bigger size do not find entry into the second room B.
Just to introduce, PIC S9(5) COMP. It occupies 4 bytes always. This is as per one rule (memory size allotment rule). But it can store 10 digit
numbers in some scenario, whereas it can only store up to 5-digit numbers in another scenario. This difference in behavior is changed by
changing the compiler settings to manipulate the data limit acceptance rule.
IMPORTANT NOTE: For all programs compiled below, ARITH(COMPAT), TRUNC(BIN) compiler options were in
effect. Wherever, compilation was performed using different option values, it is clearly stated.
If you are confident on the topic of this discussion, you can skip the discussions that follow and go through
practice questions given at the end to test your knowledge.
Section 1: Re-looking at the Background

Case 1:
01 WS-A PIC S9(11) VALUE 274 / 3867 / 38000 / 50000 / 123456 / 3245614 / 1357913579 / 24680246802.
01 WS-B PIC S9(05).
01 WS-C PIC S9(10).
MOVE WS-A TO WS-B
MOVE WS-A TO WS-C
Case 2:
01 WS-A PIC S9(11) VALUE 274 / 3867 / 38000 / 50000 / 123456 / 3245614 / / 1357913579 / 24680246802.
01 WS-B PIC S9(04) COMP.
01 WS-C PIC S9(09) COMP.
MOVE WS-A TO WS-B
MOVE WS-A TO WS-C
WS-B, WS-C in Case1 are of USAGE DISPLAY.
WS-B, WS-C in Case2 are of USAGE COMP.
Here our task is to observe and compare outputs of Case1 and Case2.
First of all,
1.
Why have we chosen to compare
PIC S9(04) COMP vs PIC S9(05) and not PIC S9(04) COMP vs PIC S9(04)?
PIC S9(09) COMP vs PIC S9(10) and not PIC S9(09) COMP vs PIC S9(09)?
The reason is that PIC S9(04) COMP, even though seemingly shows to have 4 digits (apparently indicated by 9(04)) can actually store a few 5-digit numbers as well.
Similarly, PIC S9(09) COMP, even though seemingly shows to have 9 digits (apparently indicated by 9(09)) can actually store a few 10-digit numbers as well.
PIC S9(04) COMP > is actually a 5-digit variable (storing some of 5-digit numbers)
PIC S9(09) COMP > is actually a 10-digit variable(storing some of 10-digit numbers)
So, we are comparing 5-digit variable - PIC S9(05) - with another 5-digit variable - PIC S9(04) COMP
And
10-digit variable - PIC S9(10) - with another 10-digit variable - PIC S9(09) COMP.
So, this is fair comparison that we are doing.
Revising Rules of Data movement to numeric variables

We are fairly familiar with data movement to USAGE DISPLAY numeric fields in this case to PIC S9(N) and to its variations involving SIGN clause. To restate, they
follow following rule
Decimal alignment - of incoming data and the receiving field.
Right justification before decimal
Left justification after decimal
Revising data storage in numeric variables

Lets take an example. Lets give a quick glance at how +123 and -123 get stored in each of three normally used numeric data types USAGE DISPLAY, USAGE COMP3, USAGE COMP
USAGE DISPLAY
Unsigned variable
PIC 9(3) 3 bytes
+123
Individual bits (actual storage)
Understanding in Hexadecimal
Understanding in Decimal
Comments: Each digit occupies 8 bits.
-123
Cannot store it. PIC 9(3) only stores 0 and positive numbers.
Signed variable
PIC S9(3) 3 bytes
+123
Comments: Each digit occupies 8 bits. Last (rightmost) digit (here 3) is superimposed with sign of the number(here +ve). For positive numbers, 1 is
substituted by A, 2 is substituted by B, 3 is substituted by C, and so on. For negative numbers, 1 is substituted by J, 2 is substituted by K, 3 is
substituted by L, and so on.
-123
1
2
1
3
Comments: Each digit occupies 8 bits. Last (rightmost) digit (here 3) is superimposed with sign of the number(here -ve). For positive numbers, 1 is
substituted by A, 2 is substituted by B, 3 is substituted by C, and so on. For negative numbers, 1 is substituted by J, 2 is substituted by K, 3 is
substituted by L, and so on.
USAGE COMP-3
Unsigned variable
PIC 9(3) COMP-3 2 bytes
+123
This is for
storing sign(+ve)
Comments: Each digit occupies 4 bits. 4 bits reserved for sign at right. Unsigned variable shows sign as
hexadecimal F on extreme right.
-123
Cannot store it. PIC 9(3) COMP-3 only stores 0 and positive numbers.
Signed variable
PIC S9(3) COMP-3 2 bytes
+123
This is for
storing sign(+ve)
Comments: Each digit occupies 4 bits. Sign occupies 4 bits. Signed variable shows sign as hexadecimal C for +ve
on extreme right. Hexadecimal D for ve.
-123
This is for
storing sign(-ve)
Comments: Each digit occupies 4 bits. Sign occupies 4 bits. Signed variable shows sign as hexadecimal C for +ve
on extreme right. Hexadecimal D for ve.
USAGE COMP
Unsigned variable
PIC 9(3) COMP 2 bytes
+123
123
Comments: Number is converted to pure binary. Here, no specific set of bits represent 1, 2 or 3. It is a singlepiece 123.
-123
Cannot store it. PIC 9(3) COMP only stores 0 and positive numbers.
Signed variable
PIC S9(3) COMP 2 bytes
+123
123
Comments: Number is converted to pure binary. Here, no specific set of bits represent 1, 2 or 3. It is a singlepiece 123.
-123
1
F
1
F
0
8
65413
Comments: An UNSIGNED 2-byte COMP variable has a range (0 thru +65535). A SIGNED 2-byte COMP variable has
a range (-32,768 thru +32,767). Both variables occupy same memory size. When the variable is changed to
SIGNED, system knows that a 2-byte signed COMP variable CANNOT store beyond +32767. So, what it does is it
allots the range (+32768 thru +65535) to negative numbers
Explanation for storing -123 in PIC S9(03) COMP

16
15
14
13
12
11
10
PIC 9(3) COMP
16
15
14
13
12
11
10
PIC S9(3) COMP

Notice that the above 16-bit memory may, at one time, can get allotted to a PIC 9(3) COMP (unsigned variable), and, at another time, may get allocated to PIC
S9(03) COMP (signed variable). How does it behave differently (as regards data storage) when looked from two different data types?
PIC 9(3) COMP: We are not interested in storing the sign here. We want to utilize all 16 bits for storing data purpose. As it is a 16-bit memory, the maximum decimal
number that can get stored is when each of 16 bits stores in itself a binary 1. So, we have sixteen 1s. This corresponds to a decimal number 65535 (2^16 1). So, a
total of 65,536 decimal numbers can be stored (0 thru 65,535).
PIC S9(3) COMP: We are interested in storing the sign here. We must allocate 1 bit for that (2 possibilities one for storing +ve sign, and the other for storing ve
sign). Leftmost 16th bit is reserved for sign. Therefore, we only have 15 remaining bits for storing data. In 15 bits, we can store (2^15 1 = 32767) numbers. Also,
we can store 0. 0 corresponds to all 15 bits as 0. 32,767 corresponds to all 15 bits as 1. That means if we fix sign bit as 0, say, then with it we have 32,768
positive numbers (0 thru 32,767). Similarly, if we fix sign bit as 1, then with it we have another 32,768 numbers (these are -32,768 thru -1). So, total range is (32,768 thru -1, 0, +1 thru +32,767). That means altogether we can store 65,536 numbers.
How are negative numbers stored?
Binary bit patterns
Which decimal number is represented via below?

PIC 9(3) COMP
PIC S9(3) COMP
0000 0000 0000 0000
0000 0000 0000 0001
0111 1111 1111 1110
32766
32766
0111 1111 1111 1111
32767
32767
1000 0000 0000 0000
32768
-32768
1000 0000 0000 0001
32769
-32767
1000 0000 0000 0010
32770
-32766
1111 1111 1000 0101
65413
-123
1111 1111 1111 1110
65534
-2
1111 1111 1111 1111
65535
-1
16th bit is '0'
16th bit changes to '1'
Memory storage is identical-sized for signed and unsigned COMP. When 16th bit is fixed as '0' then for any bit pattern they represent same
decimal number. That means positive numbers are identically represented in binary bits by both PIC 9(3) COMP and by PIC S9(3) COMP. But
when 16th bit changes to '1', then same bit pattern no longer represents same decimal number. When 16th bit is 1, the number as a whole
is understood as POSITIVE by PIC 9(3) COMP, whereas number as a whole is understood as NEGATIVE by PIC S9(3) COMP. That means bit
pattern stored in two different data items may appear same, but they may represent altogether two different numbers.
Binary simply converted to decimal (calculator)

PIC 9(3) COMP understands it as decimal
PIC S9(3) COMP understands it as decimal
0, 1, 2,..32766, 32767, 32768, 32769,..,65534, 65535.

0, 1, 2,..32766, 32767, 32768, 32769,..,65534, 65535.
0, 1, 2,..32766, 32767, -32768, -32767,-3, -2,
-1 .
Practice Homework: Try and develop the bit patterns if 157 and -157 are stored in each of the above numeric data types.
Try and develop the bit patterns if 892 and -892 are stored in each of the above numeric data types.
Section 2: Data storage in PIC S9(01) COMP thru PIC S9(09)

COMP Sample Programs
We will try and answer the following questions as sample
Does the same rule hold good when we move values to USAGE COMP as well. In other words, do PIC S9(05) and PIC S9(04) COMP
behave similarly as far as what values they receive from another variable?
If PIC S9(05) receives some value, is it mandatory that PIC S9(04) COMP should also be able to receive it?
If PIC S9(05) truncates some value, is it mandatory that PIC S9(04) COMP also truncates it as much?
PIC S9(N) is a N-digit variable. Is it true for PIC S9(N) COMP as well?
Other questions
Largest and smallest numbers (basically range) that can be stored in PIC S9(01) COMP.
First let us straightaway refer to the executed program below and its output for these kinds of variables
PIC S9(04) COMP and PIC S9(05) &
PIC S9(09) COMP and PIC S9(10)
First POSITIVE NUMBERS are considered.
Many numbers are taken to test the limit of positive numbers that cobol compiler accepts in these variables.
Now let us also observe the output this time for NEGATIVE NUMBERS.
PIC S9(04) COMP and PIC S9(05) &
PIC S9(09) COMP and PIC S9(10)
Again, many numbers are taken to test the limit of negative numbers that cobol compiler accepts in these
variables.
Section 3: Observation of Data storage in PIC S9(01) COMP

thru PIC S9(09) COMP
Observation from the programs:
Table 1
POSITIVE NUMBERS
Source
Destination
PIC
S9(04)
COMP
PIC S9(11)
PIC S9(05)
Equal or
Not?
PIC S9(09)
COMP
PIC S9(10)
Equal or
Not?
3-digit
274
274
274
YES
274
274
YES
3-digit
999
999
999
YES
999
999
YES
4-digit
3867
3867
3867
YES
3867
3867
YES
4-digit
9999
9999
9999
YES
9999
9999
YES
5-digit
22000
22000
22000
YES
22000
22000
YES
5-digit
32765
32765
32765
YES
32765
32765
YES
5-digit
32766
32766
32766
YES
32766
32766
YES
5-digit
32767
32767
32767
YES
32767
32767
YES
5-digit
32768
-32768
32768
NO
32768
32768
YES
5-digit
32769
-32767
32769
NO
32769
32769
YES
5-digit
32770
-32766
32770
NO
32770
32770
YES
5-digit
38000
-27536
38000
NO
38000
38000
YES
5-digit
50000
-15536
50000
NO
50000
50000
YES
5-digit
65533
-3
65533
NO
65533
65533
YES
5-digit
65534
-2
65534
NO
65534
65534
YES
5-digit
65535
-1
65535
NO
65535
65535
YES
5-digit
65536
65536
NO
65536
65536
YES
5-digit
65537
65537
NO
65537
65537
YES
5-digit
65538
65538
NO
65538
65538
YES
5-digit
99999
-31073
99999
NO
99999
99999
YES
6-digit
123456
-7616
23456
NO
123456
123456
YES
6-digit
999999
16959
99999
NO
999999
999999
YES
7-digit
3245614
-31186
45614
NO
3245614
3245614
YES
7-digit
9999999
-27009
99999
NO
9999999
9999999
YES
8-digit
12345678
24910
45678
NO
12345678
12345678
YES
8-digit
99999999
-7937
99999
NO
99999999
99999999
YES
9-digit
123456789
-13035
56789
NO
123456789
123456789
YES
9-digit
999999999
-13825
99999
NO
999999999
999999999
YES
10-digit
1234567890
722
67890
NO
1234567890
1234567890
YES
10-digit
2147483645
-3
83645
NO
2147483645
2147483645
YES
10-digit
2147483646
-2
83646
NO
2147483646
2147483646
YES
10-digit
2147483647
-1
83647
NO
2147483647
2147483647
YES
10-digit
2147483648
83648
NO
-2147483648
2147483648
NO
10-digit
2147483649
83649
NO
-2147483647
2147483649
NO
10-digit
2148001234
-6702
1234
NO
-2146966062
2148001234
NO
10-digit
9999999999
-7169
99999
NO
1410065407
9999999999
NO
11-digit
24680246802
-20974
46802
NO
-1089556974
4680246802
NO
11-digit
99999999999
-6145
99999
NO
1215752191
9999999999
NO
Table 2
NEGATIVE NUMBERS
Source
Destination
PIC
S9(04)
COMP
PIC S9(11)
PIC S9(05)
Equal
or
Not?
PIC S9(09)
COMP
PIC S9(10)
Equal
or
Not?
3-digit
-274
-274
-274
YES
-274
-274
YES
3-digit
-999
-999
-999
YES
-999
-999
YES
4-digit
-3867
-3867
-3867
YES
-3867
-3867
YES
4-digit
-9999
-9999
-9999
YES
-9999
-9999
YES
5-digit
-22000
-22000
-22000
YES
-22000
-22000
YES
5-digit
-32765
-32765
-32765
YES
-32765
-32765
YES
5-digit
-32766
-32766
-32766
YES
-32766
-32766
YES
5-digit
-32767
-32767
-32767
YES
-32767
-32767
YES
5-digit
-32768
-32768
-32768
YES
-32768
-32768
YES
5-digit
-32769
32767
-32769
NO
-32769
-32769
YES
5-digit
-32770
32766
-32770
NO
-32770
-32770
YES
5-digit
-38000
27536
-38000
NO
-38000
-38000
YES
5-digit
-50000
15536
-50000
NO
-50000
-50000
YES
5-digit
-65533
-65533
NO
-65533
-65533
YES
5-digit
-65534
-65534
NO
-65534
-65534
YES
5-digit
-65535
-65535
NO
-65535
-65535
YES
5-digit
-65536
-65536
NO
-65536
-65536
YES
5-digit
-65537
-1
-65537
NO
-65537
-65537
YES
5-digit
-65538
-2
-65538
NO
-65538
-65538
YES
5-digit
-99999
31073
-99999
NO
-99999
-99999
YES
6-digit
-123456
7616
-23456
NO
-123456
-123456
YES
6-digit
-999999
-16959
-99999
NO
-999999
-999999
YES
7-digit
-3245614
31186
-45614
NO
-3245614
-3245614
YES
7-digit
-9999999
27009
-99999
NO
-9999999
-9999999
YES
8-digit
-12345678
-24910
-45678
NO
-12345678
-12345678
YES
8-digit
-99999999
7937
-99999
NO
-99999999
-99999999
YES
9-digit
-123456789
13035
-56789
NO
-123456789
-123456789
YES
9-digit
-999999999
13825
-99999
NO
-999999999
-999999999
YES
10-digit
-1234567890
-722
-67890
NO
-1234567890
-1234567890
YES
10-digit
-2147483645
-83645
NO
-2147483645
-2147483645
YES
10-digit
-2147483646
-83646
NO
-2147483646
-2147483646
YES
10-digit
-2147483647
-83647
NO
-2147483647
-2147483647
YES
10-digit
-2147483648
-83648
NO
-2147483648
-2147483648
YES
10-digit
-2147483649
-1
-83649
NO
2147483647
-2147483649
NO
10-digit
-2148001234
6702
-1234
NO
2146966062
-2148001234
NO
10-digit
-9999999999
7169
-99999
NO
-1410065407
-9999999999
NO
11-digit
-24680246802
20974
-46802
NO
1089556974
-4680246802
NO
11-digit
-99999999999
6145
-99999
NO
-1215752191
-9999999999
NO
ARITH(COMPAT), TRUNC(BIN) used for documenting below table
COMP fields
SIZE (# of bits)
Total
PIC S9(01) COMP

PIC S9(02) COMP
PIC S9(03) COMP
PIC S9(04) COMP
PIC S9(05) COMP

PIC S9(06) COMP
PIC S9(07) COMP
PIC S9(08) COMP
PIC S9(09) COMP
PIC S9(10) COMP

PIC S9(11) COMP
PIC S9(12) COMP
PIC S9(13) COMP
PIC S9(14) COMP
PIC S9(15) COMP
PIC S9(16) COMP
PIC S9(17) COMP
PIC S9(18) COMP
16
Sign
Data
Theoretical range
5 digits
PIC S9(01) COMP can

store all numbers that PIC
S9(04) COMP can store.
Even PIC S9(02) COMP
and PIC S9(03) COMP
follow same.
same
10 digits
PIC S9(05) COMP can

Even PIC S9(06) COMP,
PIC S9(07) COMP, and PIC
S9(08) COMP follow
same.
same
10
19-digits
PIC S9(10) COMP can

Even PIC S9(11) COMP,
PIC S9(12) COMP, PIC
S9(13) COMP, PIC S914)
COMP, PIC S915) COMP,
PIC S9(16) COMP, and PIC
S9(17) COMP follow
same.
63
Minimum: -9,223,372,036,854,775,808
Maximum: +9,223,372,036,854,775,807((2
raised to 63) - 1)
Comments
Actual range
31
Minimum: -2,147,483,648
Maximum: +2,147,483,647((2 raised to 31) 1)
64
DISPLAY
SIZE
15
Minimum: -32768
Maximum: +32767((2 raised to 15) - 1)
32
Max no.
of digits
stored
RANGE
Minimum:
-999,999,999,999,999,999
Maximum:
+999,999,999,999,999,999
18
If ARITH(EXTEND), TRUNC(BIN) were used for above, then, even PIC S9(10) COMP thru PIC S9(18) COMP would accept the
theoretical range (see discussion in section 5).
1. What range of numbers can PIC S9(04) COMP store?
PIC S9(04) COMP has a range (-32768 to 32767). That means it can store some 5-digit numbers (though, not all). Since, it can store 5-digit numbers (even if a few), its display shows 5 digits.
"NO" (in Table 1 and in Table 2) represent those cases where a number stored in PIC S9(05) is NOT same as that stored in PIC S9(04) COMP (even though source of movement to both was
same number). Difference is because PIC S9(04) COMP, whenever it sees incoming data to be outside of its range, converts it to a number within the range. When incoming data is within
the range, there is no difference between stored value in PIC S9(05) and PIC S9(04) COMP.
2. What range of numbers can PIC S9(09) COMP store?
PIC S9(09) COMP has a range (-2147483648 to +2147483647) . That means it can store some 10-digit numbers (though, not all). Since, it can store 10-digit numbers (even if a few), its display
shows 10 digits.
"NO" (in Table 1 and in Table 2) represent those cases where a number stored in PIC S9(10) is NOT same as that stored in PIC S9(09) COMP (even though source of movement to both was
same number). Difference is because PIC S9(09) COMP, whenever it sees incoming data to be outside of its range, converts it to a number within the range. When incoming data is within
the range, there is no difference between stored value in PIC S9(10) and PIC S9(09) COMP.
Ranges
PIC S9(04) COMP

(-32,768 to 32,767) a
few 5-digit numbers
also included
PIC S9(05)
(-99,999 to 99,999) all
5-digit numbers
included
PIC S9(09) COMP
PIC S9(10)
(-2,147,483,648 to +2,147,483,647) a few

10-digit numbers also included
(-9,999,999,999 to +9,999,999,999) all

10 digit numbers included
Below is the crux of data movement to PIC S9(04) COMP and PIC S9(09) COMP
If number is within range

If number is out of range
PIC S9(04) COMP and PIC S9(09) COMP
PIC S9(05) and PIC S9(10)
directly store it as-is

convert to a number within range ---> store the
number to which source is converted to
directly store it as-is

truncate towards left --> store the number to which source is
truncated to
PIC S9(04) COMP can store 5 digits. It does NOT matter if incoming number has more digits than what PIC S9(04) COMP can store. As an example, even for an 8-digit incoming number,
the incoming number is converted to a number within its range, and then gets stored as converted number.
PIC S9(09) COMP can store 10 digits. It does NOT matter if incoming number has more digits than what PIC S9(09) COMP can store. As an example, even for a 12-digit incoming number,
the incoming number is converted to a number within its range, and then gets stored as converted number.
For COMP, If number is out of range, concept of truncation does NOT hold good (in fact it is irrelevant) as number is CONVERTED. Truncation is relevant when you try to store the
number but cannot fit it due to length issues. When conversion is carried out, the original number gets lost, so truncation of original number becomes meaningless when conversion is
carried out. Conversion (for COMP) and truncation(for USAGE DISPLAY) are two different things.
Conversion formulae (when incoming number is outside of range)

MOD means remainder obtained during division (in excel below can be easily calculated).
PIC S9(04) COMP

(positive number N, outside of (1 to 32767))
MOD((N - 32767),65536) -32769
(negative number N, outside of (-32768 to -1))
MOD((N + 32768),65536) -32768
(Note: The above is applicable for PIC S9(01) COMP thru PIC S9(04) COMP)
PIC S9(09) COMP

(positive number N, outside of (1 to +2147483647))
MOD((N -2147483647),4294967296) -2147483649
(negative number N, outside of (2147483648 to -1))
MOD((N + 2147483648),4294967296) -2147483648
(Note: The above is applicable for PIC S9(05) COMP thru PIC S9(09) COMP)
Further comments:
For PIC S9(04) COMP
1.
2.
Range of values stored in PIC S9(04) COMP is from -32768 to 32767 only ( a total of 65536 numbers). This range repeats on either side (positive numbers and negative numbers see below for explanation).
Any number that is outside of this range - numbers less than -32768, and numbers greater than 32767 - , if moved, gets converted (not truncated) to a number within this range
as per rule
Actual number
-98304..-65536-32769
-32768..032767
32768..6553698303
Number converted to
-32768.032767
-32768..032767
-32768.032767
Negative side
Positive side
For PIC S9(09) COMP

1.
2.
Range of values stored in PIC S9(09) COMP is from -2147483648 to +2147483647 only ( a total of 4294967296 numbers). This range repeats on either side (positive
numbers and negative numbers - see below for explanation).
Any number that is outside of this range - numbers less than -2147483648, and numbers greater than 2147483648 - , if moved, gets converted (not truncated) to a
number within this range as per rule
Actual number
-6442450944..-4294967296.-2147483649
-2147483648..02147483647
214748364842949672966442450943
Number converted to
-214748364802147483647
-2147483648..02147483647
-214748364802147483647
Negative side
Positive side
Now let us answer these questions
Does the same rule hold good when we move values to USAGE COMP as well. In other words, do PIC S9(05) and PIC S9(04) COMP behave similarly as
far as what they receive from another variable?
Ans: Rule is same for COMP as well. But before applying three points of the rule, conversion takes place, if required. If value is out of range, conversion
happens. If value is within range, no conversion happens. After decision on conversion-or-not is made and applied, rule of numeric movement is applied.
If PIC S9(05) receives some value, is it mandatory that PIC S9(04) COMP should also be able to receive it?
Ans: It is not necessary. They have different ranges. PIC S905) can store from -99,999 thru +99,999. PIC S9(04) COMP can store -32,768 thru +32,767.
PIC S9(05)
-99,999+ 99,999
PIC S9(04) COMP
-32,768..+32,767
Within, -32,768+32,767, both will store identically.
Outside of -32,768..+32,767 and within -99,999+ 99,999, PIC S9(04)COMP will convert. PIC S9(05)will store without issues.
Outside of -99,999+ 99,999, PIC S9(04)COMP will convert and store. PIC S9(05) will truncate.
Similarly,
PIC S9(10)
-9,999,999,999.+ 9,999,999,999
PIC S9(09) COMP
-2,147,483,648.. +2,147,483,647
Within, -2,147,483,648+2,147,483,647, both will store identically.
Outside of -2,147,483,648..+2,147,483,647 and within -9,999,999,999+ 9,999,999,999, PIC S9(09)COMP will convert. PIC S9(10)will store without
issues.
Outside of -9,999,999,999+ 9,999,999,999, PIC S9(09)COMP will convert and store. PIC S9(10) will truncate..
If PIC S9(05) truncates some value, is it mandatory that PIC S9(04) COMP also truncates it as much?
Ans: Not really. As an example, if a 6-digit number is moved, then PIC S9(05) will truncate it. But as far as PIC S9(04) COMP is concerned, there is no question
of truncation. There is a question of conversion. Truncation (in PIC S9(05) and conversion (in PIC S9(04) COMP) will lead to totally 2 different answers. Reason
for the different values in them will not be truncation alone. On one side it is truncated, on the other side, it is converted.
PIC S9(N) is an N-digit variable. Is it true for PIC S9(N) COMP as well?
Ans: Not really. PIC S9(N) COMP can store (N+1), (N+2). Number of digits depending on what N is. PIC S9(01) COMP can store 5 digits.
Other questions
Ans: Already explained earlier
Section 4: Conclusion on PIC S9(01) COMP thru PIC S9(09)

COMP
Conclusion:
When the receiving variable is PIC S9(04) COMP.
When the input numbers are in the range (-32768..0..32767), values moved to it behave as if we are moving to PIC S9(05). No change of value happens.
When input numbers are outside of this range, they get converted to bring them back to this range - (-32768..0..32767).
PIC S9(04) COMP CANNOT store anything outside of this range (-32768..0..32767)
PIC S9(04) COMP CAN store 5-digit positive numbers from 10000 to 32767, not after that.
PIC S9(04) COMP CAN store 5-digit negative numbers from -32768 to -10000, not after that.
PIC S9(04) COMP CAN store 5-digit numbers (even if not all). Whereas, PIC S9(04) Can only store max of 4-digit numbers, not 5-digit numbers. For COMP variables, we should not
relate 9(N) with number of digits it can store.
Incoming Positive numbers:
5-digit positive numbers > 32767
(example: 45678, 50000)
all 6-digit
(example: 456789, 523456)
all 7-digit
(example: 4567890, 1234567)
and so on.all undergo conversion when moved to PIC S9(04) COMP.
Like PIC S9(05) applies truncation on all incoming numbers. PIC S9(04) COMP applies conversion on all incoming numbers. Discussion of truncation does not arise as any number,
if found outside of range, is converted to a number inside the range. This new number is easily storable.
Incoming Negative numbers:
5-digit negative numbers < -32768
(example: -45678, -50000)
all 6-digit
(example: -456789, -523456)
all 7-digit
(example: -4567890, -1234567)
and so on.
all undergo conversion when moved to PIC S9(04) COMP.
Incoming numbers within the range (-32768..0..32767) are not converted, and are stored as it is.
When the receiving variable is PIC S9(09) COMP.
When the input numbers are in the range (-2147483648 to +2147483647), values moved to it behave as if we are moving to PIC S9(10). No change of value happens.
When input numbers are outside of this range, they get converted to bring them back to this range - (-2147483648 to +2147483647).
PIC S9(09) COMP CANNOT store anything outside of this range (-2147483648 to +2147483647).
PIC S9(09) COMP CAN store 10-digit positive numbers from 1000000000 to +2147483647, not after that.
PIC S9(09) COMP CAN store 10-digit negative numbers from -2147483648 to -1000000000, not after that.
PIC S9(09) COMP CAN store 10-digit numbers (even if not all). Whereas, PIC S9(09) Can only store max of 9-digit numbers, not 10-digit numbers. For COMP variables, we should
not relate 9(N) with number of digits it can store
Positive numbers:
10-digit positive numbers > +2147483647,
all 11-digit,
all 12-digit,
and so on.
Negative numbers:
10-digit negative numbers < -2147483648
all 11-digit,
all 12-digit,
and so on.
Incoming numbers within the range (-2147483648 to +2147483647) are not converted, and are stored as it is.
To assign a value
We cannot use VALUE clause to assign COMP variable with a value that is outside of its range. Same is true for USAGE DISPLAY variables. The number specified must be within range.
Myth broken:
PIC S9(N) COMP can only store up to N digits. This is not true. Even PIC S9(01) COMP can store 5 digits. Even PIC S9(05) COMP can
store 10 digits.
PIC S9(04) COMP can only store up to 4-digit numbers. It can store some of 5-digit numbers as well +10000 to +32767, and from 32768 to -10000.
PIC S9(09) COMP can only store up to 9-digit numbers. It can store some of 10-digit numbers as well +100000000 to +2147483647,
and from -2147483648 to -100000000.
New knowledge:
PIC S9(01) COMP thru PIC S9(04) COMP can all store same set of numbers (-32,768 thru +32,767). It is because anyway they occupy
identical-sized memory (16 bits). So, why not allow same range to be stored.
PIC S9(05) COMP thru PIC S9(09) COMP can all store same set of numbers (-2147483648 thru +2147483647). It is because anyway
they occupy identical-sized memory (32 bits). So, why not allow same range to be stored.
PIC S9(N) (N = 1, 2, 3) can do all that PIC S9(04) can do.
PIC S9(N) (N = 5, 6, 7, 8) can do all that PIC S9(09) can do.
As PIC S9(01) COMP, PIC S9(02) COMP, PIC S9(03) COMP, PIC S9(04) COMP all mean same thing, and
PIC S9(05) COMP, PIC S9(06) COMP, PIC S9(07) COMP, PIC S9(08) COMP, PIC S9(09) COMP all mean same thing
DCLGEN recognizes
--SMALLNT = PIC S9(04) COMP
--INTEGER = PIC S9(09) COMP
Existing correct knowledge:
PIC 9(N) or PIC S9(N) can store max of N digits.
PIC 9(N) COMP-3 or PIC S9(N) COMP-3 can store max of N digits.
So, next time when we observe a value, 39364, say, when moved to PIC S9(04) COMP but does not get stored as 39364, we
should not be surprised!!!
Similarly, next time when we observe a value, 2148001234, say, when moved to PIC S9(09) COMP but does not get stored as
2148001234, we should not be surprised!!!
Section 5: Effect of ARITH(EXTEND)

Now lets study what effect ARITH(EXTEND) has.
So, far we have seen declarations up to 18 bytes and data processed up to 18 digits. Can
we increase the capability of data processed? In other words, can data of more number
of digits be stored and processed?
ARITH(EXTEND) allows for the possibility of EXTENDING the memory allotment for numeric data items, beyond maximum size allowed by ARITH(COMPAT). This results in
extending the range of numbers that can be stored in a numeric data item.
1. To make COBOL program accept more than 18 digits in a numeric data item, compiler option ARITH(EXTEND)should be in effect. We can supply it from PARM
option to IGYCRCTL.
2. Default option is ARITH(COMPAT).
ARITH(COMPAT): Range is to declare data items up to 18 digits. 18 digits includes before and after decimal digits. Total number of digits (before and after decimal) should not exceed 18.
ARITH(EXTEND): Range is extended to declare data items up to 31 digits. 31 digits includes before and after decimal digits. Total number of digits (before and after decimal) should not exceed 31.
A few programs are tried out for this purpose. See attached text doc.
As regards numeric datatypes we normally come across, these can be divided into 3 animals (there are more animals though, in the COBOL jungle!). These
normally used animals are:
First animal - USAGE DISPLAY
Second animal - USAGE COMP
Third animal - USAGE COMP-3
USAGE
DISPLAY
Where ARITH(COMPAT) and ARITH(EXTEND) are

identical in behavior?
Where ARITH(COMPAT) and ARITH(EXTEND) are NOT identical in

behavior?
For
1. PIC 9(N) N <=18
2. PIC S9(N) N <=18
3. PIC S9(M)9(N) (M+N) <=18
ARITH(COMPAT) and ARITH(EXTEND) behave identically for their
computation and DISPLAY
ARITH(EXTEND) allows following (which ARITH(COMPAT) does NOT allow)

1. PIC 9(19) thru PIC 9(31) to be declared
2. PIC S9(19) thru PIC S9(31) to be declared
3. PIC S9(M)V9(N) to be declared (19 <= M+N <= 31)
4. Number of significant digits to extend beyond 18 but fewer than 32 significant digits before and after decimal
counted.
PIC S9(10) COMP thru PIC S9(18) COMP

Theoretical range in 64 bits occupied by each of PIC S9(10) COMP thru PIC S9(18) COMP
-9,223,372,036,854,775,808 Maximum: +9,223,372,036,854,775,807((2 raised to 63) - 1)
When compiling using ARITH(COMPAT) option
Actual Range of PIC S9(10) COMP thru PIC S9(18) COMP was limited to
-999,999,999,999,999,999 thru +999,999,999,999,999,999. This was because when ARITH(COMPAT) is used,
COBOL does NOT even accept more than 18 digit numbers at all. Theoretical minimum and maximum values (in
63 bits of PIC S9(10) COMP thru PIC S9(18) COMP fields) are both 19 digits. But as COBOL does NOT permit
(when ARITH(COMPAT) is used) more than 18 digits, no 19-digit number of the range is permitted.
--from +1,000,000,000,000,000,000 and up to +9,223,372,036,854,775,807 are NOT allowed
--from -1,000,000,000,000,000,000 and up to -9,223,372,036,854,775,808 are NOT allowed
COMP
COMP-3

ARITH(COMPAT) or ARITH(EXTEND) - respective ranges of PIC S9(01)
COMP thru PIC S9(09) COMP stay same.
1. PIC S9(01) thru PIC S9(04) COMP - Range is (-32,768 thru +32,767)
2. PIC S9(05) thru PIC S9(09) COMP - Range is -2147483648 thru +
2147483647)
When compiling using ARITH(EXTEND) option,

1. Actual Range of PIC S9(10) COMP thru PIC S9(18) COMP is extended
from: Minimum: -999,999,999,999,999,999 Maximum: +999,999,999,999,999,999
to : Minimum: -9,223,372,036,854,775,808 Maximum: +9,223,372,036,854,775,807((2 raised to 63) - 1)
2. Also, each of these can accommodate the new range - PIC S9(10) COMP thru PIC S9(18) COMP
DISPLAY and computation are also same.
For COMP, declaration of more than PIC S9(18) COMP is not allowed, even with ARITH(EXTEND) option.
For
1. PIC 9(N) COMP-3 N <=18
2. PIC S9(N) COMP-3 N <=18
3. PIC S9(M)9(N) COMP-3 (M+N) <=18
ARITH(COMPAT) and ARITH(EXTEND) behave identically for their
computation and DISPLAY
ARITH(EXTEND) allows following (which ARITH(COMPAT) does NOT allow)

1. PIC 9(19) COMP-3 thru PIC 9(31) COMP-3 to be declared
2. PIC S9(19) COMP-3 thru PIC S9(31) COMP-3 to be declared
3. PIC S9(M)V9(N) COMP-3 to be declared (19 <= M+N <= 31)
4. Number of significant digits to extend beyond 18 but fewer than 32 significant digits before and after decimal
counted.
ARITH(COMPAT)
ARITH(EXTEND)
DISPLAY
Up to 18 digit-declarations and up to 18-digit processing allowed.
More than 18-digit declarations and more than 18-digit processing allowed.
COMP
Up to 18 digit-declarations only. BUT PRMISSION GIVEN TO PROCESS A FEW

19-DIGIT NUMBERS PERMITTED UP TO THEORETICAL LIMIT
COMP-3
More than 18-digit declarations and more than 18-digit processing allowed.
In summary,
ARITH(EXTEND) helps
1.
Makes possibility of extending capability of storing more than 18 digits. But this gift is only given to 2 of above three animals viz. USAGE DISPLAY and USAGE COMP-3.
2.
USAGE COMP animal is benefitted in a way that the below members of its family - PIC S9(10) COMP thru PIC S9(18) COMP find themselves holding additional numbers.
Following (extra numbers) 19-digit numbers are allowed for these animals.
+1,000,000,000,000,000,000 and up to +9,223,372,036,854,775,807
-1,000,000,000,000,000,000 and up to -9,223,372,036,854,775,808
What ARITH(EXTEND) cannot do for us:

1.
It cannot allow USAGE COMP animal to be declared with more than 18 digits in PIC clause. Which means following declaration is invalid
01
A PIC S9(19) COMP VALUE 1234567890123456789.
2.
It cannot allow USAGE COMP animal to process outside of theoretical maximum range.
3.
It cannot allow COMP to store 20 digits or more.
Section 6: Effect of TRUNC(BIN) or TRUNC(STD)

Now lets study what effect TRUNC(BIN) or TRUNC(STD) have.
TRUNC option talks about truncation, or cutting short, the range of numbers that can be stored in a numeric data item.
Firstly, TRUNC option only has effect on COMP fields (remember I am only talking about 3 animals DISPLAY, COMP, and COMP-3!!!). Out of
these, DISPLAY or COMP-3 are not affected by TRUNC option.
There are 2 separate things about a memory:
Size of Memory allotted to a variable to store data.
Range of data that this memory can accommodate.

When compilation is done using TRUNC(STD), memory allotment rule to COMP variables follows same rule as when TRUNC(BIN) option is used.
For example, PIC S9(1) COMP, it will continue to occupy 2 bytes only. That means size of memory allotment is not changed.
What changes from TRUNC(BIN) to TRUNC(STD) is the range of values that PIC S9(01) COMP can accept.
PIC S9(01) COMP
-------------------------TRUNC(BIN) - Range is (-32,768 thru +32,767)
TRUNC(STD) - Range is (-9 thru +9)
So, as we see range of numbers stored is what is affected by TRUNC option. Size of memory is NOT affected. Size of memory utilized remains
same.
It is like this. A 10 m long room can accommodate up to 10m long box. But as per a rule passed, only up to max 5m boxes long are permitted
into the box. More than 5m boxes are cut(to 5m size box) before they are allowed to enter. So, room size is NOT changed. Length of containers
permitted is restricted.
DISPLAY/COMP-3: In the case of DISPLAY/COMP-3, things are simple. Count how many 9s are there in the PICTURE definition. If number of
digits in incoming number exceeds number of 9s in the PICTURE definition, then apply truncation rule to drop excess digits on left. So, the
reference to decide truncation is number of 9s in PICTURE definition. This is standard rule of storing.
COMP: But we have already seen that in the case of COMP, number of 9s in PICTURE definition is NOT taken as criterion to decide what can be
dropped. Here truncation is governed by a separate rule binary rule of storing. This rule says that if incoming number exceeds maximum
number permitted inside the memory allotted, then truncation happens. And we have seen number of digits in maximum number is GREATER
THAN number of 9s In PICTURE definition.
TRUNC(STD) means truncate using standard rule which is, as per number of 9s present in PICTURE definition.
TRUNC(BIN) means truncate using binary rule that is, if incoming number exceeds maximum number allowed as per binary rules of
storage.
Default chosen for TRUNC may vary from system to system. Observe it carefully. In one system, I did not pass TRUNC from PARM, it took
default as TRUNC(BIN). In another system, it took the default as TRUNC(STD). So, observe it carefully.
We have seen that range of numbers in a COMP field can be different from that of DISPLAY/COMP-3 for the same PIC definition. In fact, any
COMP declaration CAN store more range of numbers than what its DISPLAY/COMP-3 declaration counterparts can store.
As an example,
PIC S9(8) can only store -99,999,999 thru +99,999,999. Which means 8-digit numbers. Larger numbers undergo truncation.
Truncation is governed by number of 9s (in this case 8).
PIC S9(8) COMP can store from some 10-digit numbers also.
If we want PIC S9(08) COMP to also follow how PIC S9(08) behaves, then TRUNC(STD) is to be used. If TRUNC(STD) is used, then PIC S9(08)
COMP will not accept any 9 or higher digit numbers. Its range of numbers will be -99,999,999 thru +99,999,999, which is for PI S9(08).
TRUNC option cannot alter the range of
DISPLAY
PIC 9(N)
PIC S9(N)
PIC 9(M)V9(N)
PIC S9(M)V9(N)
COMP-3
PIC 9(N) COMP-3
PIC S9(N) COMP-3
PIC 9(M)V9(N) COMP-3
PIC S9(M)V9(N) COMP-3
It can alter the range of

PIC 9(N) COMP
PIC S9(N) COMP
PIC 9(M) COMP
PIC S9(M) COMP
----- That means TRUNC does NOT affect DISPLAY/COMP-3 fields, in any way.
In summary, if TRUNC(STD) is used, then even for a COMP field, developer feels as if it is a DISPLAY/COMP-3 field. Truncations are governed by
number of 9s in the PICTURE definition for COMP fields, and they behave (outwardly) as DISPLAY/COMP-3 fields. Remember internal storage is
still in binary format in them. Only the range of numbers stored is cut short.
ARITH and TRUNC
(there are 2 worksheets in above excel file)
01 COMP fields supplementary document.docx
Section 7: HEX ON analysis

We often analyze data in a file in HEX ON mode. This is especially for fields that are non-DISPLAY types, like COMP, COMP-3
etc..Here again we should be able to read the data in decimal form. Because that is what we understand. But data shown is in
hexadecimal form. So, we should clearly know how to convert this hexadecimal number to decimal number.
Analysis of USAGE DISPLAY and COMP-3 fields
This is relatively easy as for each digit there is a corresponding Hexa decimal value shown. One can easily convert hexadecimal
number to decimal number.
Analysis of COMP fields

1. Move a value to a COMP field.
2. Identify (as per ARITH and TRUNC options) if this value will be accepted as it is, or it will undergo
truncation before acceptance.
3. Whatever decimal value is accepted is what gets shown in DISPLAY statement (DISPLAY done on the
variable).
4. The file (in HEX ON mode) shows hexadecimal equivalent of the stored decimal number.
5. PIC 9(1) COMP thru PIC 9(18) COMP
Feed the hexadecimal value obtained from file into calculator. Compute the equivalent decimal value
in the calculator. You will find that the decimal value as shown by the calculator will be what DISPLAY
statement (actually stored) will also show. Remember only 0 and positive decimal numbers get stored
here. There is a unique hexadecimal number for every decimal number here. Remember also that
what you move into the variable may or may not get stored. If truncation is there, then what you
move will be different from what gets stored.
Decimal - what you move(A) --- Decimal that gets stored(B, shown in DISPLAY) ---- Hexa decimal form (HEX ON).
|
Calculators decimal value (C)
A and B may or may not match.
B and C will always match.
6.

Here calculators decimal value and your decimal value may not match. This is true even if your value
was accepted by the COMP variable. This case is true for negative numbers. For positive numbers, your
decimal value and calculators decimal value will match. Values will be same as obtained for unsigned
COMP fields.
Decimal - what you move(A) --- Decimal that gets stored(B, shown in DISPLAY) ---- Hexa decimal form (HEX ON).
|
Calculators decimal value (C)
A and B may or may not match.
B and C will always match for positive numbers.
B and C will NOT match for negative numbers.
A.
If we do not know whether a COMP field is signed or not, then remember that by just seeing hexadecimal value in the file for this field, we
cannot conclude whether it is corresponding to a signed or if it is corresponding to an unsigned COMP field. For example, if
we find X6F82 in the file. X6F82 can come by
a.
storing +28546 in an signed COMP field
b. storing +28546 in an unsigned COMP field
Here we ARE able to predict the exact decimal value. But still cannot predict the sign-ness or unsign-ness of field.
Similarly, if we find X8000 in the file. X8000 can come by
a.
storing +32768 in an signed COMP field
b. storing -32768 in an unsigned COMP field
Here we are NOT able to predict the exact decimal value also.
So, hex values can be misleading sometimes.
B.
By seeing Hexadecimal values, we cannot predict number of 9s in COMP field.
Example, PIC S9(02) and PIC 9(02), PIC S9(03) all show 2 bytes in file.
C.
You know that a field is numeric. But you do not know whether it is COMP, COMP-3, or DISPLAY. You also do not know whether it is signed or
unsigned. You also do not know the number of 9s in the PICTURE? Can we predict the PICTURE definition by looking at the hexadecimal value?
Ans: Answer is No.
Refer to the table shown below.
Nature of
field
DISPLAY
Unsigned
Signed
Basic PICTURE definitions
Allowed 'decimal' characters (without

HEX ON mode)
PIC 9(N)
PIC 9(N)V9(M)
0 thru 9
PIC S9(N)
PIC S9(N)V9(M)
0 thru 9, A thru R
allowed Hexadecimal
characters (in HEX ON
mode)
F(in odd numbered nibbles
from left)
0 thru 9(in even numbered
nibbles from left)
F(in odd numbered nibbles
from left, except second
from right)
0 thru 9(in even numbered
nibbles from left, except
rightmost)
Example
Ex: +123
X'F1F2F3'
Ex: -123
X'F1F2D3'
C/D (second nibble from

right)
0 thru 9(rightmost nibble)
COMP-3
COMP
Unsigned
PIC 9(N) COMP-3

PIC 9(N)V9(M) COMP-3
hard to figure out.junk shown
0 thru 9
F(rightmost nibble)
Signed
PIC S9(N) COMP-3

PIC S9(N)V9(M) COMP-3
0 thru 9.
C/D(rightmost nibble)
Ex: -123
X'00123D'
Unsigned
PIC 9(N) COMP
0 thru 9, A thru F
Ex: 123
X'007B'
Signed
PIC S9(N) COMP
0 thru 9, A thru F
Ex: -123
X'FF85'
Ex: 123
X'00123F'
Lets take an example to prove this point.

Hexadecimal value shown is XF0FF.
It is a 2-byte field. Comparing to the table above, we find that
this cannot be coming from DISPLAY Unsigned.
This cannot be coming from DISPLAY signed.
This cannot be coming from COMP-3 Unsigned.
This cannot be coming from COMP-3 Signed.
So, the only possibility is that it is coming from a COMP field.
Can we say Signed COMP or Unsigned COMP. No, we cannot. Why? Use calculator to convert F0FF to decimal. It is 61695.
This could be coming from PIC 9(1) COMP thru PIC 9(4) COMP provided program is compiled with TRUNC(BIN).
It could also be coming from PIC S9(1) COMP thru PIC S9(4) COMP. In this case the decimal value will not be 61695, but will be -3841.
So, here answer is NO.
Hexadecimal value shown is XF0F1.

It is a 2-byte field. Comparing to the table above, it could be
DISPLAY Unsigned -> Decimal value = 01
COMP Unsigned -> Decimal value = 61681
COMP Signed -> Decimal value = -3855

So, here also answer is NO.
Hexadecimal value shown is X1234.

It is a 2-byte field. Comparing to the table above, it is more refined. That is, we can definitely say that it is COMP field. But can we say whether
signed or unsigned
COMP Unsigned -> Decimal value = 4660
COMP Signed -> Decimal value = 4660

So, here decimal value is same. But we cannot say if coming from unsigned or signed.
So, here also answer is NO.
So, the conclusion is that if we at least know that the field is signed or not, then we may be able to say about the USAGE type. But that also very
remote chance. Number of 9s is also not knowable for sure.
COMP - HEX ON
analysis
(There are three sub-sheets in this excel)
Section 8: What would happen if COMP variable had a

fractional part?
This is hardly used. Perhaps never. But lets analyse if COMP can only store integers or fractions as well. If it can store fractions, how do they
behave?
COMP variables can be declared with fractional part and they can store fractional numbers as well.
Memory Size: Memory size rules for a COMP variable that has a fractional part is same as that for COMP variable that is without a
fractional part. Which means number of bytes allocated only depends on the total number of 9s in the PICTURE definition.
PIC 9(03)V9(01) COMP, PIC 9(02)V9(02) COMP, PIC 9(01)V9(03) COMP, PIC V9(04) COMP all occupy 2 bytes. Their signed versions also occupy 2
bytes only.
Range of Data Storage:

TRUNC(BIN)
We know that range of PIC 9(04) COMP is from 00000 thru 65535.
We know that range of PIC S9(04) COMP is from -32768 thru 32767.
In order to understand range of PIC 9(N)V9(M) COMP [N+M = 4], it is enough to remember that number of decimal digits that can be stored
after decimal cannot exceed the number of 9s declared after decimal. We know the range of PIC 9(N)V9(M) COMP for M = 0. When M > 0, the
new range is derived from original range only(M=0). In the new range, for M > 0,decimal will move left wards by as many digits as the
number of 9s after decimal.
For example, range of PIC 9(04) COMP is 0 thru 65535.
So, as per this rule:
PIC 9(03)V9(01) COMP - will have range from 0 thru 6553.5.
PIC V9(04) COMP

- will have range from 0 thru 6.5535.
Similarly, 5 thru 9-digited and 10 thru 18-digited PICTURE clauses also behave as per their respective ranges.
PIC S9(03)V9(01) COMP - will have range from -3276.8 thru 3276.7.
PIC SV9(04) COMP

- will have range from -3.2768 thru 3.2767.
Similarly, 5 thru 9-digited and 10 thru 18-digited PICTURE clauses also behave as per their respective ranges.
TRUNC(STD)
As with variable declarations without the decimal part, here also, COMP variables behave as if COMP is removed from them.
As examples:
PIC 9(03)V9(01) COMP will behave as PIC 9(03)V9(01) behaves -- Range will be from 0 thru +999.99.
PIC S9(03)V9(01) COMP will behave as PIC 9(03)V9(01) behaves -- Range will be from -999.99 thru +999.99.
Section 9: Answered Questions

Q. If I want to process a 20-digit number using a single variable, what should I do?
A. Use either USAGE DISPLAY or USAGE COMP-3. Use ARITH(EXTEND) during compilation. COMP cannot help here.
Q. I want to utilize PIC S9(18) COMP to be able to store those 19-digit values that are theoretically allowed?
A. Use ARITH(EXTEND) and TRUNC(BIN) during compilation. If ARITH(EXTEND) is used but TRUNC(STD) is used, then program will still process 18 digit numbers max.
Moving a 19-digit number will truncate one digit (on left).
Q. I want to process a 35-digit number using a single variable. What should I do?
A. No one can help here. We cannot process more than 32 digit numbers (before and after decimal counted). Perhaps need to think of using multiple variables method etc
Q. I am using ARITH(COMPAT). Can I process an 18-digit number?

A. Yes. All three animals DISPLAY, COMP, COMP-3 can do this. ARITH(COMPAT) is default option. To pass, ARITH(EXTEND) we must pass from JCL.
Q. I am using ARITH(EXTEND). Can I store a 20-digit number in PIC S9(19) COMP-3?

A. No. Irrespective of ARITH option used, USAGE DISPLAY and USAGE COMP-3 can only store as many digits as there are 9s in PICTURE clause.
Q. I am using ARITH(COMPAT). Can I declare a PIC 9(19) but process a 18-digit number through it?
A. No. None of three animals can help here. When ARITH(COMPAT) is used, any of three animals can at best declare
PIC 9(18)
PIC S9(18)
PIC 9(N)V9(M) (N+M) <=18
PIC S9(N)V9(M). (N+M) <=18
In order to process above request, below options are possible
PIC 9(19)
PIC 9(19) COMP-3
And compile using ARITH(EXTEND) in either case.
PIC 9(19) COMP is not declarable. This animal never goes beyond PIC 9(18) COMP.
Q. I am observing that my program does not allow me to declare PIC clause with greater than 18 digits. I want to process a 20 digit number. What should I do?
A. This is happening because compiler option ARITH uses COMPAT. If field under consideration is COMP, then nothing can be done. COMP cannot be declared beyond PIC
S9(18) COMP anyway. If field under consideration is DISPLAY or COMP-3, then change compiler option ARITH. Use ARITH(EXTEND) in order to make DISPLAY / COMP-3
fields accept PICTURE clause greater than 18 digits. You must use PIC S9(20) or above and then assign a 20-digit value to it.
PIC S9(19) and PIC S9(19) COMP-3 cannot store a 20-digit number.
Q. I have copied a program from one machine (A) to another machine (B). In machine A, it was able to process a 9-digit number. But not anymore in machine B.
Why?
A. Let me divide the discussion into 2 pieces
USAGE DISPLAY / USAGE COMP-3
To be able to process a 9-digit number, minimum any of following should be used.
a.
PIC 9(9)
b.
PIC S9(9)
c.
PIC 9(9) COMP-3
d.
PIC S9(9) COMP-3
Any value under ARITH (COMPAT or EXTEND) , and any value for TRUNC (BIN or STD) cannot cause the problem you have observed. That means the variable under
question is a neither a USAGE DISPLAY nor a USAGE COMP-3 type. It is a COMP variable.
The problem is that you had a COMP variable that might have been declared in any of following ways
PIC S9(05) COMP
PIC S9(06) COMP
PIC S9(07) COMP
PIC S9(08) COMP
On machine A, compiler option was TRUNC(BIN). Any of these variables can process a 9-digit number when TRUNC(BIN) is used. (Remember PIC S9(01) COMP thru PIC
S9(04) COMP cannot process a 9-digit variable). Due to this, when you moved a 9-digit number into the variable, it was able to accept it and process it. But on machine B,
TRUNC(STD) was used. Due to this, when you moved a 9-digit number into the variable, truncation happened in following way (check out which one!!)
PIC S9(05) COMP 9-digit number was truncated to 5 digits.
Compile using TRUNC(BIN) override from PARM of IGYCRCTL - and you will be good to go!!
Q. I am using ARITH(EXTEND), can I declare as below.

01 DISTANCE-OF-STAR PIC S9(20) VALUE 12345678901234567890123.
A. No. PICTURE definition must be compatible with VALUE clause. As it is a USAGE DISPLAY field, number of digits in PICTURE must be greater than or equal to number of
digits in VALUE clause.
If it were a USAGE COMP-3, same argument hold good.
If it were a COMP field, it is invalid declaration because PIC S9(18) COMP is maximum we can declare.
Q. Can I ever process 10-digit numbers through a PIC 9(9)?

A. No. This variable can at best store 999,999,999 (maximum value allowed = number of 9s in PICTURE).
Q. Can I ever process 10-digit numbers through a PIC 9(9) COMP-3?

Q. Can I ever process 10-digit numbers through a PIC 9(9) COMP?

A. Yes. PIC 9(9) COMP combined with TRUNC(BIN) can achieve this. ARITH (COMPAT or EXTEND) does not impact here. Remember not all 10-digit numbers can be
processed. Only up to +2147483647 can be processed.
If TRUNC(STD) is used, then no 10-digit number can be processed. Max is 9-digit number.
Q. Can I ever process 11-digit numbers through a PIC 9(9)?

Q. Can I ever process 11-digit numbers through a PIC 9(9) COMP-3?

Q. Can I ever process 11-digit numbers through a PIC 9(9) COMP?

A. No. This variable can at best store 999,999,999 (TRUNC(STD)) or +2147483647(TRUNC(BIN)) none of which is 11-digit number.
Q. I have copied a program from one machine (A) to another machine (B). My program received INDIA IS MY COUNTRY from JCL. On machine A, I was able to get
correct value of length( as 19) into the program in the length variable. On machine B, length variable showed me length of data passed as 9. Why? I have used
length variable as PIC S9(01) COMP for the length variable and I very well know that even PIC S9(01) COMP can store any number that PIC S9(04) COMP can store,
then why the length is not shown correctly. Please note that my program is able to receive the parameter value correctly. It is only length that is not indicated
correctly. So, length of data received(9), and actual data received(INDIA IS MY COUNTRY) are not consistent.
A. JCL passes length correctly. It must have passed 19 only. But when this starts getting into the program, system checks the rules for COMP processing. You are right in
saying that even PIC S9(01) COMP can store any number that PIC S9(04) COMP can store, and, therefore, it should be able to accept 19 into the length variable. But it is
possible only when TRUNC(BIN) is used during compilation. If TRUNC(STD) is used instead, then this variable behaves like a true 1-digit variable that cannot accept anything
beyond max 1-digit number, that is 9.
So, 19 is sent by JCL. But only one digit is acceptable to COBOL variable. Right justification rule makes 9 to be stored and 1 is truncated.
Q. PIC S9(01) COMP - I know that it occupies 2 bytes. Same thing with PIC S9(02) COMP, PIC S9(03) COMP and PIC S9(04) COMP. Does the memory allotment change if I
choose different option for ARITH and/or a different option for TRUNC?
A. No. Size of Memory allocated for COMP is in no way governed by options chosen for ARITH or option chosen for TRUNC. The maximum thing that option chosen in a
TRUNC can do is that it can limit the contents that you put inside these memories. Each of them store easily 4 digit numbers easily when RNC(BIN) is in effect. But the
moment TRUNC(STD) is used, each of them start accepting numbers differently. PIC S9(01) COMP will only max accept 1-digit (-9 thru +9), PIC S9(02) COMP will only max
accept 2-digits (-99 thru +99), PIC S9(03) COMP will only max accept 3-digit s(-999 thru +999), PIC S9(04) COMP will only max accept 4-digits (-9999 thru +9999).
When TRUNC(STD) is used, memory allotment rule does NOT change but rule for acceptance of a number into it changes.
Q. I need to declare a numeric field that can accommodate a 5-digit number . What are the options possible for me to declare a PIC that uses minimum 9s?
A.
USAGE DISPLAY
PIC 9(05) if only positive numbers are going to come.
PIC S9(05) if both positive and negative numbers are going to come
USAGE COMP-3
PIC 9(05) COMP-3, if only positive numbers are going to come.
PIC S9(05) COMP-3, if both positive and negative numbers are going to come
USAGE COMP
PIC S9(06) COMP
Q. I need to declare a numeric field that can accommodate an 8-digit number . What are the options possible for me to declare a PIC that uses minimum 9s?
A.
Keep track of TRUNC option for this.
USAGE DISPLAY
PIC 9(08) if only positive numbers are going to come.
PIC S9(08) if both positive and negative numbers are going to come
USAGE COMP-3
PIC 9(08) COMP-3, if only positive numbers are going to come.
PIC S9(08) COMP-3, if both positive and negative numbers are going to come
TRUNC option does NOT matter for USAGE DISPLAY and USAGE COMP-3.
USAGE COMP
PIC 9(05) COMP, if only positive numbers are going to come.
PIC S9(05) COMP, if both positive and negative numbers are going to come
[Make sure TRUNC(BIN) is used. TRUNC(STD) will make it NOT accept anything more than 5-digits].
If TRUNC(STD) is used, make sure to use minimum of PIC 9(08) COMP or PIC S9(08) COMP.
Q.
01 WS-VAR PIC S9(02) COMP.
DISPLAY LENGTH OF WS-VAR
DISPLAY WS-VAR
A. LENGTH OF is an internal function of cobol that helps to know the size of memory that cobol has allocated to a data item. Answer is In number of bytes allocated. In this
case, WS-VAR occupies 2 bytes and, hence, answer of DISPLAY LENGTH OF WS-VAR will be 2.
DISPLAY WS-VAR displays the contents presents in WS-VAR. If program is compiled with TRUNC(BIN), DISPLAY WS-VAR will show 5 digits. If program is compiled with
TRUNC(STD), DISPLAY WS-VAR will show 1 digit.
If the above variable is stored as a field on a file, then it will occupy 2 bytes there.
Q. PIC S9(N) COMP.

When it is compiled with TRUNC(BIN) it stores internally in binary format. When it is compiled using TRUNC(STD), does internal storage method change?
A. No. The method of storage does not change. COMP will always follow binary storage algorithm. BIN and STD only govern which decimal number can be stored and which
cannot be stored. Only range is what gets changed from BIN to STD. Once decision is made to store a given number, the binary conversion is done, and binary bit pattern is
stored.
Q. I have a PIC S9(04) COMP field that is present in a file record. When I open the file I see it as holding 2 bytes. But when I read the file in my program and display
the field from there, display shows 5 digits in SYSOUT. The number stored is only a 3-digit number inside the variable. Then why is it that in one place (file) I see 2
bytes) and in the other place (SYSOUT) it shows me 5 digits (5 bytes).
A. A variable has 2 properties associated with it.
a.
memory size
b.
data present
these are two different things.
Simple answer to the question is that file is meant to be responsible for showing size of memory held by variable. So, it shows us clearly that variable is holding 2 bytes of
memory. Whereas SYSOUT is meant to be responsible for showing clearly the data that is actually stored in the variable. So, it shows 5 digits.
SYSOUT is meant for a different purpose than file, as regards showing properties of a variable. One(file) shows first property clearly (regardless of whether second property is
shown clearly or not). The other(SYSOUT) shows second property clearly (regardless of whether first property is shown clearly or not)
Elaboration:
File is more interested in showing to us size of memory that is holding the data. It shows you memory clearly. By seeing the file, you get clarity about how much size of memory
is allocated by system to your variable. So, you get clarity on memory when you see the file. But this enforcement puts restriction on the capability of file to show data clearly.
So, it does not take guarantee to show the data in a format that you and I can comfortably read. For some fields (USAGE DISPLAY) you and I may be able to read data
comfortably, but for some others(non-USAGE DISPLAY) not.
Whereas is DISPLAY is more interested in showing you the data in a comfortable manner. That means DISPLAY puts effort to ensure that we get to see each digit clearly. It
does not bother to take responsibility of showing to us how many bytes held this data in the background. In fact all non-USAGE DISPLAY variables are converted, temporarily,
to USAGE DISPLAY types to be able to show data comfortably.
So, one person (file) takes one responsibility - of showing information on memory clearly. The other person (SYSOUT) takes the other responsibility - of showing the data
clearly. Tools like File Aid, File manager take both responsibilities. They show us data stored as well as size of memory against that data.
It is like
We see blueprint of a house. That is like seeing memory size. We get to know easily how many rooms are there, what their sizes are. This is like seeing file.
Later you see the photo of only luggage. Here we do not know how much luggage was kept in which room. This is like seeing SYSOUT.
When we see the actual house with luggage, it is like seeing File Aid. We can see size of room also and also what data is kept in how much space. Memory size is
also known, and data is also in readable format.
File viewing
DISPLAY (SYSOUT) viewing
Area of Focus
Memory
Data
What is clear?
It is clear how much size of memory a variable holds.
It is clear what data is stored (all types of fields)
what is not clear?
It may not be clear what data is stored (true for otherthan-USAGE DISPLAY fields)
It may NOT be clear how much size of memory

the variable holds.
USAGE DISPLAY
non-USAGE DISPLAY
Clarity on data available for USAGE DISPLAY fields

Clarity on data NOT available. Need to use HEX ON
and other methods to determine the data
Clarity on data available
system-oriented (memory conservation)
Human-oriented(comfort in viewing)
File is a memory area. A file is meant to hold a region of memory (mostly permanent) to store data. File can be empty initially. Data may come later into it. In initial days of
programming and storing data, lot of effort was made to use this memory efficiently so that lesser memory could store comparatively more data. Effort was made to find out
ways how to store data in a compressed manner. COMP variable was created as an outcome of this effort.
Assuming your program is using TRUNC(BIN) while performing compilation. PIC S9(04) COMP is allotted 2 bytes, regardless of TRUNC option chosen. As this variable is part
of your file record, that means as and when records are written to the file, file reserves on each record 2 bytes of memory for this variable. Data going into this variable on each
record is stored into these 2 bytes only.

Next thing to be answered is that what size of data can you store in a given size of memory. A program compiled with TRUNC(BIN) allows provision for storing, in PIC S9(04)
COMP, up to certain 5-digit numbers(-32,768 thru -1, 0, +1 thru 32,767). So, as you can see now, that the memory reserved was 2 bytes. But number of digits moved into it
can be as high as 5. Notice that when we talk of size of data stored, we do NOT speak in terms of bytes. We speak in terms of digits. It is because we human beings understand
digits, and it is the digits that get stored.. A digit has no meaning for a computer. It only understands bits and bytes. For us, we are not interested in seeing bits and bytes 1s and
0s). We want to see the digits. For us, 1 digit means size=1, 2-digit means size=2 and so on. But as programmers, we should understand that what is size=1 for us is NOT
NECESSARILY size=1 for system. That means it may sometimes be true, but it need not always be.
For us, SIZE=1 means 1-digit
For system, SIZE=1 means 1 byte.
Can we equate 1-digt = 1 byte when data is stored in the file? The answer is yes sometimes, and not on some other times. Yes is when USAGE of the variable is DISPLAY.
And No is when the USAGE of the variable is other than DISPLAY.
USAGE of field
SIZE
for us
DISPLAY
non-DISPLAY
for system
Identical
Different
DISPLAY means show what you would have shown had the variable been of type USAGE DISPLAY. A USAGE DISPLAY variable NEVER undergoes any conversion when it is
taken from a storage location (either in a physical file or inside a variable that is declared inside a program) to a display location (SYSOUT).There is no need for any conversion
because inside the file or inside the program the data is in USAGE DISPLAY format, and when it is displayed, then also it is in USAGE DISPLAY format.
DISPLAY statement converts, if required, any non- USAGE DISPLAY to a USAGE DISPLAY. This happens temporarily only and things are shown in SYSOUT in USAGE
DISPLAY format. Inside the program, data variable may still be in non-DISPLAY format.
Q. I use DISPLAY statement to display a file record. There is a PIC S9(04) COMP field in the record that stores 172 in it. But I cannot see 172 anywhere in the record
shown on SYSOUT. I see some junk values in the places intended for the COMP variable. But when I use DISPLAY on this COMP variable that is holding 172, it is
shown to me as 00172. Why?
A. First of all, from your question it is clear that you are using TRUNC(BIN).
When you use DISPLAY statement on a file record(01 level), you are using DISPLAY statement on a variable that is of USAGE DISPLAY. Group level variables are considered
by system as alphanumeric, and we know that alphanumeric variable default to USAGE DISPLAY. Since, it is already USAGE DISPLAY, system does NOT do any reformatting
of data present inside record, and data of entire record is shown exactly as it is present in the file. So, you see the data present in the COMP variable as some junk values.
When DISPLAY statement is applied on the COMP variable, system finds that it is not of USAGE DISPLAY. So, system converts the variable temporarily to a USAGE DISPLAY
type. It converts to PIC S9(05) COMP. Why does it convert to PIC S9(05) COMP, and not to PIC S9(04) COMP? It is because system knows that program was compiled with
option TRUNC(BIN), therefore, range of numbers allowed in it is from -32,768 to +32,767(5-digt numbers). To store 5-digit numbers in USAGE DISPLAY format, you need PIC
S9(05) and not PIC S9(04). Therefore, system decides in favour of PIC S9(05). And, therefore, when this (temporary) PIC S9(05) is displayed that is holding 00172, you see
00172.
Had your variable been declared as PIC S9(N) COMP N between 5 and 9, your display (on the variable) would have shown you 0000000172, which means 10-digits. It is
because PIC S9(6) COMP can hold some 10-digit numbers also(when compiled with TRUNC(BIN)). So, PIC S9(6) COMP temporarily converts to PIC S9(10).
Q. A value of 555 is moved to PIC S9(02)V9 COMP and displayed. TRUNC(BIN) is used during compilation. What will be displayed? Will the display change if
TRUNC(STD) is used? If yes, what is the new value displayed?
A. PIC S9(02)V9 COMP occupies 2 bytes. We know that PIC S9(04) COMP can hold -32768 thru 32767. Here, PIC S9(02)V9 COMP has a range in such a way that after
decimal sign, a maximum of one decimal digit is permitted. So, its range is -3276.8 thru 3276.7. Which means it can easily store 555. During DISPLAY, COMP is temporarily
dropped. And, similar to as PIC S9(03) COMP or PIC S9(04) COMP will display, here also, display will be 00555.
Section 10: Practice Questions

1.
2.
3.
5.
6.
True or False TRUNC(BIN) makes COMP fields to accept values as per their binary limits.
True or False TRUNC(STD) makes COMP fields to behave like USAGE DISPLAY fields, as regards what values they can accept.
ARITH(COMPAT) is used for compiling the program. What is the maximum value that PIC 9(06) can hold? Does this maximum value
depend upon whether TRUNC(BIN) or TRUNC(STD) is used?
ARITH(COMPAT) is used for compiling the program. What is the maximum value that PIC 9(06) COMP can hold? Does this maximum
value depend upon whether TRUNC(BIN) or TRUNC(STD) is used?
Memory size of PIC 9(4) COMP can be varied by compiler options in TRUNC? True or False.
Memory size of PIC S9(6) COMP can be varied by compiler options in TRUNC? True or False.
7.
01 WS-HOURS-WORKED PIC 9(3) COMP.
4.
Program is compiled with ARITH(COMPAT), TRUNC(BIN). Fill the following table.

Decimal
Value
moved
Decimal
value
accepted
Hexadecimal
representation
147
56
8788
34000
55555
82310
247
87
8000
35672
89100
Change the option to TRUNC(STD). Fill the table again. Comment on the differences, if any, you observe, between using two TRUNC
options.
8.
01 WS-HOURS-WORKED PIC S9(3) COMP.
Program is compiled with ARITH(COMPAT), TRUNC(BIN). Fill the following table.
Decimal
Value
moved
147
56
8788
34000
55555
82310
247
87
8000
35672
89100
-147
-56
-8788
-34000
-55555
-82310
-247
-87
-8000
-35672
-89100
Decimal
value
accepted
Hexadecimal
representation
Change the option to TRUNC(STD). Fill the table again. Comment on the differences, if any, you observe, between using two TRUNC
options.
9.
01 WS-HOURS-WORKED PIC S9(3) COMP.
Fill the following table.
Decimal
Value
moved
148
81
912
34000
55555
82310
247
35672
89100
-148
-81
-912
-34000
-55555
-82310
-247
-35672
-89100
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
Decimal
value
accepted
(TRUNC(BIN))
Decimal
value
accepted
(TRUNC(STD))
It is intended to store a 5 digit number in a numeric field. Which numeric data type(COMP, COMP-3, USAGE DISPLAY) requires least
number of bytes? Give the PICTURE definition. What are the values of ARITH and TRUNC options when least number of bytes are
used?
In the context of data movement to a numeric variable of type COMP, does truncation mean same as conversion?
During HEX ON on a file opened in view mode, following value is seen. It is known to be a numeric field(without decimal)
80
00
What can be the data type for this field? Give all possible variable declarations to get this value. Give reasons for your answer.
7G
AF
Comment on possible variable declarations and corresponding decimal data in it.
During HEX ON on a file opened in view mode, can a COMP field show H anywhere in the data? What are valid characters for COMP
field in HEX ON mode?
During HEX ON on a file opened in view mode, can a COMP-3 field show H anywhere in the data? What are valid characters for
COMP-3 field in HEX ON mode?
12
3F
During HEX ON on a file opened in view mode, following value is seen in a COMP field(without decimal)
81
27
What is the range of values that PIC 9(4) COMP has?
What is the range of values that PIC S9(4) COMP has?
How many digits are displayed in SYSOUT when a DISPLAY statement is made on a PIC S9(7) field?
How many digits are displayed in SYSOUT when a DISPLAY statement is made on a PIC S9(7) COMP field?
How many bytes are occupied by PIC S9(5) COMP? Does number of bytes used dependent on any compiler settings of ARITH and BIN?
True or False - ARITH(EXTEND) is used to make COMP fields accept more than 18 digits of data.
True or False - Using ARITH(EXTEND), PIC S9(09) COMP can accept 15 digits numbers.
True or False - ARITH(EXTEND) is used. If TRUNC(BIN) is used, then PIC S9(18) COMP can accept numbers limited by binary limit.
Whereas if TRUNC(STD) is used, then PIC S9(18) COMP can accept standard(max 18 digits) of numbers.
PIC S9(04) COMP is used. Can HEX ON show
a. 80
00
b. FF
FF
For any data value? If yes, for what value?
27. PIC 9(04) COMP is used. Can HEX ON show

c.
80
00
d. FF
FF
For any data value? If yes, for what value?
28. COMP variable is being used and TRUNC(BIN) option is in effect. What will be the least hexadecimal value in the leftmost nibble value
when a negative number(permitted by the binary boundary) is stored in it.
29. ARITH(COMPAT), TRUNC(BIN) is being used for compilation. Can a 19-digit PICTURE clause be declared?
30. TRUNC(STD) is being used. How many digits will be displayed by PIC S9(5) COMP field?
31. 01 WS-ROI
PIC S9(01)V99 COMP.
01 WS-PRINCIPAL PIC 9(05)V99.
01 WS-INTEREST PIC 9(05)V99.
MOVE 12345 TO WS-PRINCIPAL
MOVE 12 TO WS-ROI.
COMPUTE WS-INTEREST = (WS-PRINCIPAL * WS-ROI) / 100.
DISPLAY WS-INTEREST
What will be the display if TRUNC(BIN) is used?
What will be the display if TRUNC(STD) is used?
See the display if default values are supplied to TRUNC.
32.
A COMP field is used as a file variable. Data in the variable is displayed using DISPLAY. Also, it is viewed using HEX ON and converted
to decimal using calculator. For which TRUNC option(between BIN or STD), can the two methods give different values? Can this
behavior be exhibited by unsigned COMP fields?
33.
PIC S9(03) COMP is used for a file variable. TRUNC(BIN) is used. A value -32770 is intended to be stored using a MOVE statement.
What is the decimal value accepted by the variable? What value does DISPLAY show? What hexadecimal value does variable show
when HEX ON is done on the file?
34. A job that is part of a batch job calculates claim amount payable for claims filed and approved for payment. A deductible field is
present in the claim settlement file of this job. This field is calculated by the program. Deductible field is defined as PIC S9(3) COMP.
An arithmetic statement computes a value and moves into this field. If the value moved is
123, 456, 31012, 40126
a. What will be the amounts moved to this field in each of above cases? (You can assume that program is compiled with
ARITH(COMPAT), TRUNC(BIN).
b. What will the hexadecimal values shown by this field in each of above cases.
c.
From the above values, if there are any that do NOT get moved as it is, to the COMP field, can compiler options be tweaked
suitably so they get accepted by the COMP variable as it is?
35. PIC S9(08) COMP is used for a file variable. Program is compiled with ARITH(COMPAT), TRUNC(STD). Multiplication is carried out
between following variables and output is stored in the COMP field.
01 WS-NUMBER-OF-PEOPLE PIC 9(7).
01 WS-AVERAGE-SALARY
PIC 9(5).
a. Is COMP field capable to store the result of multiplication? If yes, why? If no, why?
b. What is the maximum value storable in COMP field?
c.
What should be the minimum size of COMP field to be able to accept all results possible from multiplication?
d. If we do not wish to reduce the size of COMP field, and realize that size of WS-NUMBER-OF-PEOPLE is reducible, then what
should be the reduced size of WS-NUMBER-OF-PEOPLE chosen?
e.
If program was complied with ARITH(COMPAT), TRUNC(STD), what is the maximum storable value in the COMP field?

Numeric Data Movement - To A COMP Variable

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Numeric Data Movement - To A COMP Variable

Hochgeladen von

Copyright:

Verfügbare Formate

Numeric Data movement - to a COMP

So, let us understand the COMP in greater detail.

Section 1: Re-looking at the Background

Revising Rules of Data movement to numeric variables

Decimal alignment - of incoming data and the receiving field.

Right justification before decimal

Left justification after decimal

Revising data storage in numeric variables

Comments: Each digit occupies 8 bits.

PIC S9(3) COMP-3 2 bytes

Explanation for storing -123 in PIC S9(03) COMP

PIC 9(3) COMP

PIC S9(3) COMP

Binary bit patterns

Which decimal number is represented via below?

PIC S9(3) COMP

0000 0000 0000 0000

0000 0000 0000 0001

0111 1111 1111 1110

0111 1111 1111 1111

1000 0000 0000 0000

1000 0000 0000 0001

1000 0000 0000 0010

1111 1111 1000 0101

1111 1111 1111 1110

1111 1111 1111 1111

16th bit is '0'

16th bit changes to '1'

Binary simply converted to decimal (calculator)

0, 1, 2,..32766, 32767, 32768, 32769,..,65534, 65535.

Section 2: Data storage in PIC S9(01) COMP thru PIC S9(09)

We will try and answer the following questions as sample

Section 3: Observation of Data storage in PIC S9(01) COMP

ARITH(COMPAT), TRUNC(BIN) used for documenting below table

PIC S9(01) COMP

PIC S9(05) COMP

PIC S9(10) COMP

PIC S9(01) COMP can

PIC S9(05) COMP can

PIC S9(10) COMP can

PIC S9(04) COMP

PIC S9(09) COMP

(-2,147,483,648 to +2,147,483,647) a few

(-9,999,999,999 to +9,999,999,999) all

If number is within range

PIC S9(04) COMP and PIC S9(09) COMP

PIC S9(05) and PIC S9(10)

directly store it as-is

directly store it as-is

Conversion formulae (when incoming number is outside of range)

PIC S9(04) COMP

PIC S9(09) COMP

For PIC S9(09) COMP

Now let us answer these questions

Section 4: Conclusion on PIC S9(01) COMP thru PIC S9(09)

When the receiving variable is PIC S9(09) COMP.

PIC S9(N) (N = 1, 2, 3) can do all that PIC S9(04) can do.

PIC S9(N) (N = 5, 6, 7, 8) can do all that PIC S9(09) can do.

PIC 9(N) or PIC S9(N) can store max of N digits.

Section 5: Effect of ARITH(EXTEND)

First animal - USAGE DISPLAY

Second animal - USAGE COMP