Numeric Data Movement - To A COMP Variable
Numeric Data Movement - To A COMP Variable
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.
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).
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.
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.
USAGE DISPLAY
Unsigned variable
PIC 9(3) – 3 bytes
+123
Individual bits (actual storage)
1 1 1 1 0 0 0 1 1 1 1 1 0 0 1 0 1 1 1 1 0 0 1 1
Understanding in Hexadecimal
F 1 F 2 F 3
Understanding in Decimal
1 2 3
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
Individual bits (actual storage)
1 1 1 1 0 0 0 1 1 1 1 1 0 0 1 0 1 1 0 0 0 0 1 1
Understanding in Hexadecimal
F 1 F 2 C 3
Understanding in Decimal
1 2 C
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
Individual bits (actual storage)
1 1 1 1 0 0 0 1 1 1 1 1 0 0 1 0 1 1 0 1 0 0 1 1
Understanding in Hexadecimal
F 1 F 2 D 3
Understanding in Decimal
1 2 L
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
Individual bits (actual storage)
0 0 0 1 0 0 1 0 0 0 1 1 1 1 1 1
Understanding in Hexadecimal
1 2 3 F
Understanding in Decimal
This is for
1 2 3
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
Individual bits (actual storage)
0 0 0 1 0 0 1 0 0 0 1 1 1 1 0 0
Understanding in Hexadecimal
1 2 3 C
Understanding in Decimal
This is for
1 2 3
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
Individual bits (actual storage)
0 0 0 1 0 0 1 0 0 0 1 1 1 1 0 1
Understanding in Hexadecimal
1 2 3 D
Understanding in Decimal
This is for
1 2 3
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
Individual bits (actual storage) 0 0 0 0 0 0 0 0 0 1 1 1 1 0 1 1
Understanding in Hexadecimal 0 0 7 B
Understanding in Decimal 123
Comments: Number is converted to pure binary. Here, no specific set of bits represent ‘1’, ‘2’ or ‘3’. It is a single-
piece 123.
-123
Cannot store it. PIC 9(3) COMP only stores 0 and positive numbers.
Signed variable
PIC S9(3) COMP – 2 bytes
+123
Individual bits (actual storage) 0 0 0 0 0 0 0 0 0 1 1 1 1 0 1 1
Understanding in Hexadecimal 0 0 7 B
Understanding in Decimal 123
Comments: Number is converted to pure binary. Here, no specific set of bits represent ‘1’, ‘2’ or ‘3’. It is a single-
piece 123.
-123
Individual bits (actual storage) 1 1 1 1 1 1 1 1 1 0 0 0 0 1 0 1
Understanding in Hexadecimal F F 8 5
Understanding in Decimal 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
1 15 14 13 12 1 10 9 8 7 6 5 4 3 2 1
6 1
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 1‘s. 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.
Binary simply converted to decimal (calculator) 0, 1, 2,……..32766, 32767, 32768, 32769,…………………..,65534, 65535.
PIC 9(3) COMP understands it as decimal 0, 1, 2,……..32766, 32767, 32768, 32769,…………………..,65534, 65535.
PIC S9(3) COMP understands it as decimal 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
Other questions
Largest and smallest numbers (basically range) that can be stored in PIC S9(01) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(02) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(03) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(04) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(05) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(06) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(07) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(08) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(09) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(10) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(11) 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) Equal or PIC S9(09) Equal or
PIC S9(11) COMP PIC S9(05) Not? COMP PIC S9(10) 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 0 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 -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 0 83648 NO -2147483648 2147483648 NO
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
Table 2
NEGATIVE NUMBERS
Source Destination
PIC Equal Equal
S9(04) PIC or PIC S9(09) or
PIC S9(11) COMP S9(05) Not? COMP PIC S9(10) 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 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 0 -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 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 0 -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
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).
Below is the crux of data movement to PIC S9(04) COMP and PIC S9(09) COMP
PIC S9(04) COMP and PIC S9(09) COMP PIC S9(05) and PIC S9(10)
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.
‘MOD’ means remainder obtained during division (in excel below can be easily calculated).
Further comments:
1. 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).
2. 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
1. 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).
2. 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
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
Largest and smallest numbers (basically range) that can be stored in PIC S9(01) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(02) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(03) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(04) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(05) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(06) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(07) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(08) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(09) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(10) COMP.
Largest and smallest numbers (basically range) that can be stored in PIC S9(11) 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.
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 numbers within the range (-32768..0…..32767) 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
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)
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.
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.
ARITH
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:
Where ARITH(COMPAT) and ARITH(EXTEND) are Where ARITH(COMPAT) and ARITH(EXTEND) are NOT identical in
USAGE identical in behavior? behavior?
For ARITH(EXTEND) allows following (which ARITH(COMPAT) does NOT allow)
1. PIC 9(N) – N <=18 1. PIC 9(19) thru PIC 9(31) to be declared
DISPLAY 2. PIC S9(N) – N <=18 2. PIC S9(19) thru PIC S9(31) to be declared
3. PIC S9(M)9(N) – (M+N) <=18 3. PIC S9(M)V9(N) to be declared – (19 <= M+N <= 31)
ARITH(COMPAT) and ARITH(EXTEND) behave identically – for their 4. Number of significant digits to extend beyond 18 but fewer than 32 significant digits – before and after decimal
computation and DISPLAY 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)
PIC S9(01) COMP thru PIC S9(09) COMP When compiling using ARITH(EXTEND) option,
ARITH(COMPAT) or ARITH(EXTEND) - respective ranges of PIC S9(01) 1. Actual Range of PIC S9(10) COMP thru PIC S9(18) COMP is extended
COMP thru PIC S9(09) COMP stay same. from: Minimum: -999,999,999,999,999,999 Maximum: +999,999,999,999,999,999
1. PIC S9(01) thru PIC S9(04) COMP - Range is (-32,768 thru +32,767) to : Minimum: -9,223,372,036,854,775,808 Maximum: +9,223,372,036,854,775,807((2 raised to 63) - 1)
2. PIC S9(05) thru PIC S9(09) COMP - Range is -2147483648 thru + 2. Also, each of these can accommodate the new range - PIC S9(10) COMP thru PIC S9(18) COMP
2147483647)
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 ARITH(EXTEND) allows following (which ARITH(COMPAT) does NOT allow)
1. PIC 9(N) COMP-3 – N <=18 1. PIC 9(19) COMP-3 thru PIC 9(31) COMP-3 to be declared
2. PIC S9(N) COMP-3 – N <=18 2. PIC S9(19) COMP-3 thru PIC S9(31) COMP-3 to be declared
COMP-3 3. PIC S9(M)9(N) COMP-3 – (M+N) <=18 3. PIC S9(M)V9(N) COMP-3 to be declared – (19 <= M+N <= 31)
ARITH(COMPAT) and ARITH(EXTEND) behave identically – for their 4. Number of significant digits to extend beyond 18 but fewer than 32 significant digits – before and after decimal
computation and DISPLAY 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.
Up to 18 digit-declarations only. BUT PRMISSION GIVEN TO PROCESS A FEW
COMP Up to 18 digit-declarations and up to 18-digit processing allowed. 19-DIGIT NUMBERS PERMITTED UP TO THEORETICAL LIMIT
COMP-3 Up to 18 digit-declarations and up to 18-digit processing allowed. 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
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.
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.
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 9’s are there in the PICTURE definition. If number of
digits in incoming number exceeds number of 9’s in the PICTURE definition, then apply truncation rule to drop excess digits on left. So, the
reference to decide truncation is number of 9’s in PICTURE definition. This is standard rule of storing.
COMP: But we have already seen that in the case of COMP, number of 9’s 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 9’s In PICTURE definition.
TRUNC(STD) means truncate using standard rule – which is, as per number of 9’s 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 9’s (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).
----- 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 9’s 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.
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.
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 X’6F82’ in the file. X’6F82’ 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 X’8000’ in the file. X’8000’ 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 9’s 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 9’s in the PICTURE? Can we predict the PICTURE definition by looking at the hexadecimal
value?
Ans: Answer is No.
allowed Hexadecimal
Nature of Allowed 'decimal' characters (without characters (in HEX ON
field Basic PICTURE definitions HEX ON mode) mode) Example
F(in odd numbered nibbles
from left)
PIC 9(N) Ex: +123
DISPLAY Unsigned 0 thru 9
PIC 9(N)V9(M) X'F1F2F3'
0 thru 9(in even numbered
nibbles from left)
F(in odd numbered nibbles
from left, except second
from right)
0 thru 9
PIC 9(N) COMP-3 Ex: 123
COMP-3 Unsigned hard to figure out….junk shown F(rightmost nibble)
PIC 9(N)V9(M) COMP-3 X'00123F'
PIC S9(N) COMP-3 0 thru 9. Ex: -123
Signed hard to figure out….junk shown
PIC S9(N)V9(M) COMP-3 C/D(rightmost nibble) X'00123D'
Ex: 123
COMP Unsigned PIC 9(N) COMP hard to figure out….junk shown 0 thru 9, A thru F
X'007B'
Ex: -123
Signed PIC S9(N) COMP hard to figure out….junk shown 0 thru 9, A thru F
X'FF85'
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, 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 9’s 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 let’s 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 9’s 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.
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 9’s 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 9’s after decimal.
PIC S9(03)V9(01) COMP - will have range from -3276.8 thru 3276.7.
PIC S9(02)V9(02) COMP - will have range from -327.68 thru 327.67.
PIC S9(01)V9(03) COMP - will have range from -32.768 thru 32.767.
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.
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 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
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.
PIC S9(06) COMP – 9-digit number was truncated to 7 digits.
PIC S9(07) COMP – 9-digit number was truncated to 8 digits.
PIC S9(08) COMP – 9-digit number was truncated to 9 digits.
Compile using TRUNC(BIN) – override from PARM of IGYCRCTL - and you will be good to go!!
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. 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 9’s?
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 9’s?
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.
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.
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)
It may not be clear what data is stored (true for other- It may NOT be clear how much size of memory
what is not clear? than-USAGE DISPLAY fields) the variable holds.
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 1’s and 0’s). 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 for system
DISPLAY Identical
non-DISPLAY 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’.
D De Hexa
ec ci deci
i m mal
m al repre
al val senta
V ue tion
al ac
u ce
e pt
m ed
ov
e
d
1
4
7
5
6
8
7
8
8
3
4
0
0
0
5
5
5
5
5
8
2
3
1
0
2
4
7
8
7
8
0
0
0
3
5
6
7
2
8
9
1
0
0
Change the option to TRUNC(STD). Fill the table again. Comment on the differences, if any, you observe, between using two
TRUNC options.
Decim
al Decimal Hexadecimal
Value value representatio
moved accepted n
147
56
8788
34000
55555
82310
247
87
8000
35672
89100
-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.
Decimal
value Decimal
Decimal accepted value
Value (TRUNC(BIN) accepted
moved ) (TRUNC(STD))
148
81
912
34000
55555
82310
247
35672
89100
-148
-81
-912
-34000
-55555
-82310
-247
-35672
-89100
10. 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?
11. In the context of data movement to a numeric variable of type COMP, does truncation mean same as conversion?
12. 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.
13. During HEX ON on a file opened in view mode, following value is seen. It is known to be a numeric field(without decimal)
7G
AF
Comment on possible variable declarations and corresponding decimal data in it.
14. 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?
15. 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?
16. During HEX ON on a file opened in view mode, following value is seen. It is known to be a numeric field(without decimal)
12
3F
Comment on possible variable declarations and corresponding decimal data in it.
17. During HEX ON on a file opened in view mode, following value is seen in a COMP field(without decimal)
81
27
Comment on possible variable declarations and corresponding decimal data in it.
18. What is the range of values that PIC 9(4) COMP has?
19. What is the range of values that PIC S9(4) COMP has?
20. How many digits are displayed in SYSOUT when a DISPLAY statement is made on a PIC S9(7) field?
21. How many digits are displayed in SYSOUT when a DISPLAY statement is made on a PIC S9(7) COMP field?
22. How many bytes are occupied by PIC S9(5) COMP? Does number of bytes used dependent on any compiler settings of ARITH and
BIN?
23. True or False - ARITH(EXTEND) is used to make COMP fields accept more than 18 digits of data.
24. True or False - Using ARITH(EXTEND), PIC S9(09) COMP can accept 15 digits numbers.
25. 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.
26. 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?