I'm learning about cobol alone and when I was coding my first code I had some doubts.
I'm using GnuCOBOL v2.2 at websites (TutorialsPoint and JDoodle) and I didn't understand how I can put inputs by comand window. Do anyone know how do it at these websites ?
Other thing is about how to clean terminal, when I use "DISPLAY WINDOW ERASE" I have that error message: "140: warning: GRAPHICAL WINDOW is not implemented". Do I need to use any library or exist any other comand ?
One more doubt: function integer-of-date do not convert that it proposes, the output is coming zero just. Code is below:
WORKING-STORAGE SECTION.
77 DATA1 PIC 9(006).
77 DATA2 PIC 9(006).
77 INTEIRO-1 PIC 9(008).
77 INTEIRO-2 PIC 9(008).
77 DIAS PIC 9(005).
PROCEDURE DIVISION.
ACCEPT DATA1 FROM DATE
SET DATA2 TO 930217
MOVE FUNCTION INTEGER-OF-DATE (DATA1) TO INTEIRO-1 *> wrong convertion?
MOVE FUNCTION INTEGER-OF-DATE (DATA2) TO INTEIRO-2
COMPUTE DIAS = INTEIRO-2 - INTEIRO-1
DISPLAY X"0A"DATA1 " " DATA2
SET INTEIRO-1 TO FUNCTION INTEGER-OF-DATE(DATA1)
DISPLAY INTEIRO-1 " " INTEIRO-2
DISPLAY "DIAS: " DIAS
The output of that code is:
180516 930217
00000000 00000000
DIAS: 00000
Answering the integer-of-date question
FUNCTION INTEGER-OF-DATE(ccyymmdd)
You need to use full 4 digit years in a PIC 9(8) field for this function.
ACCEPT FROM DATE returns a PIC 9(6), and there is now an
ACCEPT FROM DATE YYYYMMDD form that returns a PIC 9(8).
The INTEGER-OF-DATE() intrinsic function takes a date in 8 digits format (YYYYMMDD). You could use FUNCTION CURRENT-DATE to get an 8 digit date.
The syntax SET datum TO value is normally reserved for indices, for general data you should use MOVE value TO datum.
Related
problem
I'm a beginner in COBOL and I'm running into this annoying problem which I can not find a solution for.
I want to add the value of the amount of sales to another numeric variable so that I can use it as a condition for a perform loop but when it tries to add that value to this new variable it triggers this error:
"libcob: PROG-PAGOS-F.cbl: 57: 'WS-CANTIDAD-VENTAS' not numeric: '2 '
WARNING - Implicit CLOSE of REG-VENDEDORES ('REG-MAESTRO.DAT')"
and I can not find a way around it; I'm stuck.
current code (not finished)
What this program is supposed to do is output data of employees' salary, sells, price of each sell into a file and then do some other operations with them but I can't do any progress because of this error, I'd love some help, and perhaps some advices to makes this code better. Thank you!
My variables are in Spanish because I'm Argentinian, sorry if it's hard to understand.
IDENTIFICATION DIVISION.
PROGRAM-ID. PROG-PAGOS-F.
AUTHOR. LUCAS GALEANO.
DATE-WRITTEN. 1/2/2023.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT REG-VENDEDORES ASSIGN TO "REG-MAESTRO.DAT"
ORGANIZATION IS LINE SEQUENTIAL.
SELECT REG-VENTAS ASSIGN TO "REG-VENTAS-MAESTRO.DAT"
ORGANIZATION IS LINE SEQUENTIAL.
DATA DIVISION.
FILE SECTION.
FD REG-VENDEDORES.
01 VENDEDORES PIC 9(11).
FD REG-VENTAS.
01 COBRO-VENTAS PIC 9(5).
WORKING-STORAGE SECTION.
01 WS-VENDEDORES.
05 WS-EMPLEADO PIC 999.
05 WS-SUELDO-BASE PIC 9(5).
05 WS-CANTIDAD-VENTAS PIC 999.
77 WS-COBROS PIC 9(5).
77 WS-SUM-VENTAS PIC 99.
77 WS-CONTADOR PIC 99 VALUE ZEROS.
01 WS-TABLAS.
05 WS-REGISTRO-COBROS PIC 9(5)
OCCURS 100 TIMES.
PROCEDURE DIVISION.
BEGIN-OUTPUT.
OPEN OUTPUT REG-VENDEDORES.
DISPLAY "INGRESE DATOS SOLICITADOS".
PERFORM INGRESO-DATOS-EMPLEADOS.
PERFORM UNTIL WS-VENDEDORES EQUALS SPACES
WRITE VENDEDORES FROM WS-VENDEDORES
PERFORM INGRESO-DATOS-EMPLEADOS
END-PERFORM.
DISPLAY "INGRESE COBROS DE CADA VENTA:".
PERFORM INGRESO-VENTAS WITH TEST AFTER
UNTIL WS-CONTADOR EQUALS WS-SUM-VENTAS
MOVE WS-COBROS TO WS-REGISTRO-COBROS(1)
CLOSE REG-VENDEDORES.
STOP RUN.
INGRESO-DATOS-EMPLEADOS.
DISPLAY "EEE$$$$$VVV".
ACCEPT WS-VENDEDORES.
ADD WS-CANTIDAD-VENTAS TO WS-SUM-VENTAS.
INGRESO-VENTAS.
ADD 1 TO WS-CONTADOR.
DISPLAY "$$$$$".
ACCEPT WS-COBROS.
example input data
INGRESE DATOS SOLICITADOS
EEE$$$$$VVV
1 400002
There is no implicit conversion in ACCEPT data-item, so you need to convert - and validate it on your own (or switch to "extended" screenio with ACCEPT data-item AT / SCREEN SECTION, but then the result would be depending on the actual COBOL environment).
The easiest option to convert (will sip leading/trailing spaces and invalid data) is something like the following:
ACCEPT WS-VENDEDORES. *> all data may now be invalid
MOVE FUNCTION NUMVAL (WS-EMPLEADO) TO WS-EMPLEADO
MOVE FUNCTION NUMVAL (WS-SUELDO-BASE) TO WS-SUELDO-BASE
MOVE FUNCTION NUMVAL (WS-CANTIDAD-VENTAS) TO WS-CANTIDAD-VENTAS
*> all data is now valid
For validation you may want to use FUNCITON TEST-NUMVAL (data-to-verify).
In any case I'd suggest to check out SCREEN SECTION, as this would allow you to input the data in three separate fields and commonly would do validation and conversion "on the fly".
According to the COBOL code below when I try to sum WS-NUM1 with WS-NUM2, COBOL seems to supress the last number. For example: variable WS-NUM1 and WS-NUM2 are 10.15, I get 20.20 as result but expected 20.30. What's wrong?
WS-NUM1 PIC 9(2)V99.
WS-NUM2 PIC 9(2)V99.
WS-RESULTADO PIC 9(2)V99.
DISPLAY "Enter the first number:"
ACCEPT WS-NUM1.
DISPLAY "Enter the second number:"
ACCEPT WS-NUM2.
COMPUTE WS-RESULTADO = WS-NUM1 + WS-NUM2.
Thanks in advance.
PIC 9(2)v99 defines a variable with an implied decimal place not a real one. You're trying to enter data containing a decimal point and it's not working because you have to strip out the '.' to get the numeric part of your data to properly fit in the 4 bytes that your working storage area occupies.
PROGRAM-ID. ADD2.
data division.
working-storage section.
01 ws-num-input pic x(5).
01 WS-NUM1 PIC 9(2)V99 value 0.
01 redefines ws-num1.
05 ws-high-num pic 99.
05 ws-low-num pic 99.
01 WS-NUM2 PIC 9(2)V99 value 0.
01 redefines ws-num2.
05 ws-high-num2 pic 99.
05 ws-low-num2 pic 99.
01 WS-RESULTADO PIC 9(2)V99.
PROCEDURE DIVISION.
DISPLAY "Enter the first number:"
*
accept ws-num-input
unstring ws-num-input delimited by '.'
into ws-high-num, ws-low-num
DISPLAY "Enter the second number:"
accept ws-num-input
unstring ws-num-input delimited by '.'
into ws-high-num2, ws-low-num2
*
COMPUTE WS-RESULTADO = WS-NUM1 + WS-NUM2.
DISPLAY WS-RESULTADO
STOP RUN
.
This is just a simple demonstration. In a real world application you would have to insure much more robust edits to ensure that valid numeric data was entered.
If I declare it like this
01 WS-NUM1 PIC 9(2)V99.
01 WS-NUM2 PIC 9(2)V99.
01 WS-RESULTADO PIC 9(2)V99.
and define and sum them up like this
SET WS-NUM1 TO 10.15.
SET WS-NUM2 TO 10.15.
COMPUTE WS-RESULTADO = WS-NUM1 + WS-NUM2.
DISPLAY WS-RESULTADO.
I get the expected result of 20.30.
This looks like a job for a special type of PICture : Edited picture
Indeed you seem to know about the vanilla PICture clause (I'm writing PICture because as you may know it you can either write PIC or PICTURE).
A vanilla number PIC contains only 4 different symbols (and the parentheses and numbers in order to repeat some of the symbols)
9 : Represents a digit. You can repeat by using a number between parentheses like said before.
S : Means that the number is signed
V : Show the position of the implicit decimal point
P : I've been told that it exists but I honestly never found it in the codebase of my workplace. Its another kind of decimal point used for scaling factors but I don't know much about it.
But there are other symbols.
If you use theses other mysterious symbols the numeric PIC becomes an edited numeric PIC. As its name says, an edited PICture is made to be shown. It will allow you to format your numbers for better presentation or to receive number formatted for human reading.
Once edited, you cannot use it to make computations so you will have to transfer from edited to vanilla to perform computations on the latter. And you move from vanilla to edited in order to display your results.
So now I shall reveal some of these mysterious symbols :
B : Insert a blank at the place it is put
0 : Insert a zero at the place it is put
. : Insert the decimal point at the place it is put
: Insert a + if the number is positive and a - if the number is negative
Z : Acts like a 9 if the digits it represents has a value different than 0. Acts like a blank if the digits has the value of 0.
To my knowledge there are also : / , CR DB * $ -
You can look up for it on the internet. They really show the accountant essence of cobol.
For your problems we are really interested by the "." which will allow us to take into account the decimal point you have the write when you type down your input.
For a bonus I will also use Z which will make your result looks like 2.37 instead of 02.37 if the number is less than ten.
Note that you cannot use the repeating pattern with parenthesis ( 9(03) for instance) when describing an edited picture ! Each digits has to represented explicitly
IDENTIFICATION DIVISION.
PROGRAM-ID. EDITCOMP.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-NUM1-EDITED PIC 99.99.
01 WS-NUM2-EDITED PIC 99.99.
01 WS-NUM1-CALC PIC 9(2)V99.
01 WS-NUM2-CALC PIC 9(2)V99.
01 WS-RESULTADO-EDITED PIC Z9.99.
PROCEDURE DIVISION.
ACCEPT WS-NUM1-EDITED.
ACCEPT WS-NUM2-EDITED.
MOVE WS-NUM1-EDITED TO WS-NUM1-CALC.
MOVE WS-NUM2-EDITED TO WS-NUM2-CALC.
COMPUTE WS-RESULTADO-EDITED = WS-NUM1-CALC + WS-NUM2-CALC.
DISPLAY WS-RESULTADO-EDITED.
STOP RUN.
You should note that there also exist edited alphanumeric picture. You can insert Blank (B), zeroes (0) or / (/) in it.
IDENTIFICATION DIVISION.
PROGRAM-ID. TEMP1 .
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-A PIC 9(2).
01 WS-B PIC 9(2).
PROCEDURE DIVISION.
ACCEPT WS-A.
COMPUTE WS-B ROUNDED = ( ( 9 / 5 ) * WS-A ) + 32.
DISPLAY WS-B.
STOP RUN.
This is my program for accepting temperature in Celcius and converting it to Fahrenheit. I have created a LOADLIB and a COPYLIB. Also one JCL for compilation and RUNJCL. No error is coming, but when I give any input (e.g. 98) in RUNJCL, it always shows 32 as output. What is the problem?
If the result you are getting is always 32, then WS-A is zero, because something multiplied by zero and adding 32 will always be 32.
I suspect that you have in your JCL something like this:
//SYSIN DD *
00212
When you do the ACCEPT, you will only get 00 from that.
When using ACCEPT for little testing programs it is a good idea to DISPLAY what you get, so you can see.
Either make WS-A larger, or the value on the card following your SYSIN smaller.
It if also possible you have other problems causing the value of WS-A to be treated as zero. So, can you paste the JCL from file 2 on the spool for your JOB. With the line-numbers it generated :-)
And the SYSIN card data (your 98). Look out particularly for any "SYSIN generated" statements in your JCL output.
Here's your program. I've got rid of unnecessary things, and changed the names of WS-A and WS-B. Now that WS-B has a proper name, you can see as you create it that it is the wrong length, it needs to be at least three digits.
ID DIVISION.
PROGRAM-ID. TEMP1.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 INPUT-CENTIGRADE PIC 9(2).
01 OUTPUT-FARENHEIT PIC 9(3).
PROCEDURE DIVISION.
ACCEPT INPUT-CENTIGRADE
DISPLAY
"CELSIUS COMING IN "
">"
INPUT-CENTIGRADE
"<"
COMPUTE OUTPUT-FARENHEIT ROUNDED
= ( ( 9 / 5 )
* INPUT-CENTIGRADE )
+ 32
DISPLAY
"FARENHEIT GOING OUT "
">"
OUTPUT-FARENHEIT
"<"
GOBACK
.
The output from running the program is:
CELSIUS COMING IN >98<
FARENHEIT GOING OUT >208<
Running this version of your program with "0098" for input gives this:
CELSIUS COMING IN >00<
FARENHEIT GOING OUT >032<
I would like to write a function in COBOL that converts characters from a PIC X(60) data type to uppercase. While I know one way of doing this, I would like to be able to manually go through the letters and add a constant to go from lower case to upper case, but I cannot seem to be able to perform any arithmetic on PIC X data types, unless I redefine them as something else, but then I seem to corrupt the original X character.
Can someone give me an example of how, given a PIC X variable, you can increment it by 1 letter (i.e. a -> b, d -> e... etc). In other words, I would like to be able to add 1 to this variable:
01 char-temp pic x.
Thanks,
Ivan
It is usually a very bad idea to do case folding this way, it really only works for 7-bit ASCII. What you ask is possible, and even easy to do, but I'll mention some other ways to uppercase your data first.
Easiest way:
Move function upper-case(my-src-field) To my-tgt-field
Very easy way:
Inspect my-field
converting 'abc...z' to 'ABC...Z'
End-Inspect
Hard way, to add one to 01 char-temp pic x:
01 my-working-storage.
02 char-temp-area.
03 filler pic x.
03 char-temp pic x.
02 char-temp-9 redefines char-temp-area pic s9(4) comp
.
Then you can:
Move 'A' to char-temp
Add +1 to char-temp-9
And char-temp will contain a 'B'. As others have mentioned, Cobol is not nice about single byte binary math, so you have to make your character fit in the low byte of a binary number, in this case a 2 byte binary number.
You could be naughty and use redefines eg:
01 char-temp pic x.
01 char-temp9 pic 99 comp-x redefines char-temp.
move 65 to char-temp9
display char-temp
Or use reference modification:
01 char-temp pic x.
01 char-temp9 pic 99 comp-x.
move 65 to char-temp9
move char-temp9(1:length of char-temp9) to char-temp
display char-temp
and I am sure they are other approaches too...
A single character generally takes one byte of memory. Standard COBOL does not have a binary numeric data type of one byte (Note: PIC 9 USAGE DISPLAY is a character representation of a digit not the binary representation of the digit). So, doing binary arithemetic on single characters in COBOL isn't going to work for you.
Even if you could perform arithementic on characters, you may be making a bad assumption about the binary representation of characters - the letter 'b' is not necessarily equal to the binary representation of 'a' plus 1 (it might work for ASCII but not for EBCDIC).
Finally, if you want to replace one character by another you should investigate the COBOL INSPECT statement. Unlike bit twiddling, INSPECT is completely portable.
Can someone give me an example of how, given a PIC X variable, you can
increment it by 1 letter (i.e. a -> b, d -> e... etc). In other words,
I would like to be able to add 1 to this variable:
01 char-temp pic x.
For COBOL 85, intrinsic functions CHAR and ORD may be used.
program-id. add1.
data division.
working-storage section.
1 char-temp pic x.
procedure division.
begin.
move "a" to char-temp
display char-temp "->" with no advancing
perform add-1-to-char
display char-temp
stop run
.
add-1-to-char.
move function char (function ord (char-temp) + 1)
to char-temp
.
end program add1.
Result:
a->b
I'm having the following problem in a COBOL program running on OpenVMS.
I have the following variable declaration:
01 STRUCT-1.
02 FIELD-A PIC S9(6) COMP-3.
02 FIELD-B PIC S9(8) COMP-3.
01 STRUCT-2.
03 SUB-STRUCT-1.
05 FIELD-A PIC 9(2).
05 FIELD-B PIC 9(4).
03 SUB-STRUCT-2.
05 FIELD-A PIC 9(4).
05 FIELD-B PIC 9(2).
05 FIELD-C PIC 9(2).
And the following code:
* 1st Test:
MOVE 112011 TO FIELD-A OF STRUCT-1
MOVE 20100113 TO FIELD-B OF STRUCT-1
DISPLAY "FIELD-A : " FIELD-A OF STRUCT-1 CONVERSION
DISPLAY "FIELD-B : " FIELD-B OF STRUCT-1 CONVERSION
* 2nd Test:
MOVE 112011 TO SUB-STRUCT-1.
MOVE 20100113 TO SUB-STRUCT-2.
MOVE SUB-STRUCT-1 TO FIELD-A OF STRUCT-1
MOVE SUB-STRUCT-2 TO FIELD-B OF STRUCT-1
DISPLAY "SUB-STRUCT-1 : " SUB-STRUCT-1
DISPLAY "SUB-STRUCT-2 : " SUB-STRUCT-2
DISPLAY "FIELD-A : " FIELD-A OF STRUCT-1 CONVERSION
DISPLAY "FIELD-B : " FIELD-B OF STRUCT-1 CONVERSION
Which outputs:
FIELD-A : 112011
FIELD-B : 20100113
SUB-STRUCT-1 : 112011
SUB-STRUCT-2 : 20100113
FIELD-A : 131323
FIELD-B : 23031303
Why FIELD-A and FIELD-B hold values different from what I move into them in the second test?
I've other moves from DISPLAY to COMP-3 variables in my program where I don't get this behavior.
In COBOL, Group level data are typeless and are moved without casting.
Element level data always have an associated data type. Typed
data are cast to match the type
of the receiving element during a MOVE.
In the first instance you MOVE a literal numeric value (112011) to a packed decimal field and the compiler converts it to the correct data type in the process. Just as you would expect in any programming language.
In the second instance you MOVE a literal value to a group item. Since this is a group item the compiler cannot 'know' the intended data type so it always does group moves as character data (no numeric conversions). This is fine when the receiving item has a PICTURE clause that is compatible with character data - which FIELD-A and FIELD-B
of SUB-STRUCT-1 are. There is no difference in the internal representation of a 9 when stored as PIC X and when stored as PIC 9. Both are assumed USAGE DISPLAY.
Now when you do a group level move from SUB-STRUCT-1 to a COMP-3 (Packed Decimal) you effectively tell the compiler not to convert from DISPLAY to COMP-3 format. And that is what you get.
Try the following modifications to your code. Using REDEFINES creates
a numeric elementary item for the move. COBOL will do the appropriate
data conversions when moving elementary data.
01 STRUCT-2.
03 SUB-STRUCT-1.
05 FIELD-A PIC 9(2).
05 FIELD-B PIC 9(4).
03 SUB-STRUCT-1N REDEFINES
SUB-STRUCT-1 PIC 9(6).
03 SUB-STRUCT-2.
05 FIELD-A PIC 9(4).
05 FIELD-B PIC 9(2).
05 FIELD-C PIC 9(2).
03 SUB-STRUCT-2N REDEFINES
SUB-STRUCT-2 PIC 9(8).
And the following code:
* 3RD TEST:
MOVE 112011 TO SUB-STRUCT-1.
MOVE 20100113 TO SUB-STRUCT-2.
MOVE SUB-STRUCT-1N TO FIELD-A OF STRUCT-1
MOVE SUB-STRUCT-2N TO FIELD-B OF STRUCT-1
DISPLAY "SUB-STRUCT-1 : " SUB-STRUCT-1
DISPLAY "SUB-STRUCT-2 : " SUB-STRUCT-2
DISPLAY "FIELD-A : " FIELD-A OF STRUCT-1
DISPLAY "FIELD-B : " FIELD-B OF STRUCT-1
Beware: Moving character data into a COMP-3 field may give you the dreaded SOC7 data exception abend when the receiving item is referenced. This is because not all bit patterns are valid COMP-3 numbers.
You have 2 Issues.
COBOL has several Numeric Data Structures. Each has its own set of rules.
For PACKED DECIMAL ( COMP-3 )
• The numeric components of the PIC clause should ALWAYS add up to an ODD number.
• The decimal marker “V” determines the placement of the decimal point.
• The individual element MOVE and math functions will maintain the decimal value alignment – both high and low level truncation is possible
• Numeric data type conversion (zone decimal to packed & binary to packed) is handled for you.
e.g. S9(5)V9(2) COMP-3.
including the 2 decimal positions>
Length is calculated as ROUND UP[ (7 + 1) / 2] = 4 bytes
S9(6)V9(2) COMP-3.
including the 2 decimal positions >
Length is calculated as ROUND UP[(8 + 1) / 2] = 5 bytes
But the 1st ½ byte is un-addressable
The last ½ byte of the COMP-3 fields is the HEXIDECIMAL representation of the sign.
The sign ½ byte values are C = signed positive D = signed negative F = unsigned (non COBOL).
S9(6)V9(3) COMP-3 VALUE 123.45.
Length is calculated as ROUND UP[(9 + 1) / 2] = 5 bytes
Contains X’00 01 23 45 0C’
Note the decimal alignment & zero padding.
Group Level MOVE rules
COBOL Data field structures are define as hierarchical structures.
The 01 H-L group field – & any sub-group level field –
Is almost always an implied CHARACTER string value
If an individual element field is a 01 or 77 level – then it can be numeric.
Individual element fields defined as a numeric under a group or sub-group level will be treated as numeric if referenced as an Individual element field.
Numeric rules apply.
o Right justify
o decimal place alignment
o pad H-L (½ bytes) with zeros
o Numeric data type conversion
The receiving field of a MOVE or math calculation determines if a numeric data conversion will occur.
Numeric Data Conversion
If you MOVE or perform a math calculation using any sending field type (group or element) to any receiving individual element field defined using a numeric PIC clause --- then numeric data conversion will occur for the receiving field. S0C7 abends occur when non-numeric data is MOVE ‘d to a receiving numerically defined field OR when math calculations are attempted using non-numeric data.
No Numeric Data Conversion
If you move any field type (group or element) to any group or sub-group level field then there will be NO numeric data conversion.
• Character MOVE rules apply.
• Left Justify & pad with spaces.
This is one of the primary causes of non-numeric data in a numerically defined field.
One of the primary uses of a sending group level MOVE containing numeric element fields to a receiving group level containing numeric element fields (mapped identically) is for re-initializing numeric element fields using 1 MOVE instruction.
A Clear Mask – or – a data propagation MOVE is also possible for table clears - where the table group level is greater than 255 bytes.