How come the compiler is accepting a PIC X field (alphanumeric) with usage COMP-5 ?
(but no comp-1,comp-2 etc ...
01status-codePICXXCOMP-5.
This definition i staken from CgnuCOBOL manual at
8.2.45. CBL READ KBD CHAR
CBL READ KBD CHAR Build-In Subroutine Syntax
CALL "CBL_READ_KBD_CHAR" USING char RETURNING status-code.
Waits until a character is typed from the terminal and then read it with no echo.
Parameters: char PIC X. Receives the character that was typed, in ASCII. status-code PIC XX COMP-5.
If RETURNING is not used the RETURN-CODE special register receives the status-code where
zero is success and non-zero it is not. [ Above information taken from MF WB manual ].
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-04-26
I presume PIC x(nn) COMP-5 is used primarily as it is accepted by Micro Focus and Accu.
It makes no sense from a Cobol perspective.
From the MF documentation:
COMP-5 is primarily used to communicate with external programs that expect native data storage.
The format of a COMP-5 data item is identical to a COMP-4 data item, except that the data is stored in a machine-dependent format.
If COMP-5 is used with a PIC X(n) data item and assigned an alphanumeric value, the results are undefined. For example, the following code fragment causes NUM to have an undefined number and the resulting value for the last line will be "100":
I wonder if PIC x(nn) COMP / COMP-4 is also valid ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes use comp-5 pic x(01) all the time. We do alot of binary hash tables and bit values. And this is the gnucobol 1.1 and we used to use Micro Focus and it is invalid on the mainframe.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If this isn't clear in the documentation it should be adjusted. To make it short:
PIC XX says: two alphanumeric positions, each one takes always one byte
PIC 99 says: two numerical positions
with USAGE DISPLAY, which you also get when not specifying this clause, you have "printable" data, each one takes always one byte
other USAGEs differ, if you leave out the float/double entries (which do not have a PICTURE clause you possibly a very different storage on different environments
USAGE COMP-5 is normally system-specific storage, and if you do PIC 9 USAGE COMP-5 you have a data field that has storage which could handle move than 0-9 (in most cases: 0-254), if you use -fno-trunc you can also see this (non-standard) behaviour (and a speedup)
PIC XX COMP-5 says: numeric data that takes two bytes - it does not specify the numerical positions that can be stored
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The data is still numeric, the difference is only that you specify the exact size of the field, instead of the numerical positions.
As COMP-5 is a data type that is often used to interact with C/C++ which also uses bytes, not numerical positions it is a good match. ... and this is also a reason that this extension only applies to COMP-5.
How come the compiler is accepting a PIC X field (alphanumeric) with usage COMP-5 ?
(but no comp-1,comp-2 etc ...
This definition i staken from CgnuCOBOL manual at
8.2.45. CBL READ KBD CHAR
CBL READ KBD CHAR Build-In Subroutine Syntax
CALL "CBL_READ_KBD_CHAR" USING char RETURNING status-code.
Waits until a character is typed from the terminal and then read it with no echo.
Parameters: char PIC X. Receives the character that was typed, in ASCII.
status-code PIC XX COMP-5.
If RETURNING is not used the RETURN-CODE special register receives the status-code where
zero is success and non-zero it is not.
[ Above information taken from MF WB manual ].
I presume PIC x(nn) COMP-5 is used primarily as it is accepted by Micro Focus and Accu.
It makes no sense from a Cobol perspective.
From the MF documentation:
COMP-5 is primarily used to communicate with external programs that expect native data storage.
The format of a COMP-5 data item is identical to a COMP-4 data item, except that the data is stored in a machine-dependent format.
If COMP-5 is used with a PIC X(n) data item and assigned an alphanumeric value, the results are undefined. For example, the following code fragment causes NUM to have an undefined number and the resulting value for the last line will be "100":
I wonder if PIC x(nn) COMP / COMP-4 is also valid ?
Yes use comp-5 pic x(01) all the time. We do alot of binary hash tables and bit values. And this is the gnucobol 1.1 and we used to use Micro Focus and it is invalid on the mainframe.
If this isn't clear in the documentation it should be adjusted. To make it short:
PIC XXsays: two alphanumeric positions, each one takes always one bytePIC 99says: two numerical positionsUSAGE DISPLAY, which you also get when not specifying this clause, you have "printable" data, each one takes always one byteUSAGEs differ, if you leave out the float/double entries (which do not have aPICTUREclause you possibly a very different storage on different environmentsUSAGE COMP-5is normally system-specific storage, and if you doPIC 9 USAGE COMP-5you have a data field that has storage which could handle move than 0-9 (in most cases: 0-254), if you use-fno-truncyou can also see this (non-standard) behaviour (and a speedup)PIC XX COMP-5says: numeric data that takes two bytes - it does not specify the numerical positions that can be storedOk but then what is the goal of this specification.
Why and when can it be useful to define a field of two bytes PIC XX but with usage COMP-5?
The data is still numeric, the difference is only that you specify the exact size of the field, instead of the numerical positions.
As COMP-5 is a data type that is often used to interact with C/C++ which also uses bytes, not numerical positions it is a good match. ... and this is also a reason that this extension only applies to COMP-5.