I'm entirely new to COBOL. I have a small COBOL program and a small C file. According to this article: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea400/sdtpt.htm
the equivalent of a C signed integer in COBOL is
PIC S9(9) USAGE IS BINARY
I want to call the functions in the C file from COBOL, and display the result in COBOL. I am able to call the function, and it seems to behave as expected, data being passed as expected, but I'm not able to display the binary value with DISPLAY in COBOL.
My COBOL program:
IDENTIFICATION DIVISION.
PROGRAM-ID. MSQLTST5_COBHELPER.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 SQLCODE PIC S9(9) USAGE IS BINARY VALUE 100.
PROCEDURE DIVISION.
HEAD SECTION.
MAIN.
DISPLAY "COBOL, sqlcode is: " SQLCODE.
CALL "CONNECT_DEFAULT" USING SQLCODE.
DISPLAY "COBOL, sqlcode is: " SQLCODE.
STOP RUN.
END PROGRAM MSQLTST5_COBHELPER.
The C function I'm calling:
void connect_default(int* sqlcode)
{
printf("C, sqlcode is: %d\n", *sqlcode);
// internal code that places the expected error code -14006 in the variable sqlcode
printf("C, sqlcode is: %d\n", *sqlcode);
}
The output of running my COBOL program:
COBOL, sqlcode is: d
C, sqlcode is: 100
C, sqlcode is: -14006
COBOL, sqlcode is: J▒▒▒
It seems that the variable does indeed have the value 100 that I gave it, and then is passed correctly between C and COBOL, but when I ask COBOL to display the variable it seems to try to pick out the character that has the given ASCII code, rather than the numerical value, as the character 'd', which has the ASCII code 100, is displayed rather than the number 100.
How do I display this value as a numeric value in COBOL?
Why don't you transfer the contents of the SQLCODE field to a USAGE DISPLAY field using the MOVE instruction? It'll convert the binary number to a numeric one.
If the formatting is strange — here is why:
Signed numeric pictures without the SIGN SEPARATE clause must somehow include the sign without taking up space, so most compilers combine the last digit with the sign of the number. Most conventions use J for −1 till R for −9. They also pad the number with leading zeros. So -14006 will convert to 00001400O, because the last digit is a 6, and because it must be conbined with the minus sign, the last digit becomes -6, which is represented by an O. Roughly the same reasoning counts for 00000010{.
In order to reformat the number, you could actually use another picture, like
pic S9(9) sign leading separate
That will display -14006 as -000014006
This should achieve your intended results.
IDENTIFICATION DIVISION.
PROGRAM-ID. MSQLTST5_COBHELPER.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 SQLCODE PIC S9(9) USAGE IS BINARY VALUE 100.
01 SQLCODE-E PIC -9(9).
PROCEDURE DIVISION.
HEAD SECTION.
MAIN.
PERFORM DISPLAY-SQLCODE.
CALL "CONNECT_DEFAULT" USING SQLCODE.
PERFORM DISPLAY-SQLCODE.
STOP RUN.
DISPLAY-SQLCODE.
MOVE SQLCODE TO SQLCODE-E.
DISPLAY "COBOL, sqlcode is: " SQLCODE-E.
END PROGRAM MSQLTST5_COBHELPER.
The standard way to do this is to move the binary field to a "numeric edited" field:
01 DISPLAY-SQLCODE PIC -(9)9.
Then
MOVE SQLCODE TO DISPLAY-SQLCODE
Full example:
IDENTIFICATION DIVISION.
PROGRAM-ID. MSQLTST5_COBHELPER.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 SQLCODE PIC S9(9) USAGE IS BINARY VALUE 100.
01 DISPLAY-SQLCODE PIC -(9)9.
PROCEDURE DIVISION.
HEAD SECTION.
MAIN.
MOVE SQLCODE TO DISPLAY-SQLCODE
DISPLAY "COBOL, sqlcode is: " DISPLAY-SQLCODE
CALL "CONNECT_DEFAULT" USING SQLCODE
MOVE SQLCODE TO DISPLAY-SQLCODE
DISPLAY "COBOL, sqlcode is: " DISPLAY-SQLCODE
STOP RUN
.
END PROGRAM MSQLTST5_COBHELPER.
Move the variable to the display field and then just display the field
01 WS-FIELD-FOR-DISPLAY PIC -(9)9.
Related
What am I doing wrong with the following piece of code under GnuCOBOL 3.1-rc1.0?
IDENTIFICATION DIVISION.
PROGRAM-ID. NUMTEST.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 NUM PIC 999V99.
PROCEDURE DIVISION.
DISPLAY "ENTER NUMBER: ".
ACCEPT NUM.
DISPLAY "NUMBER = ".
DISPLAY NUM.
STOP RUN.
I enter 123.45 as my input. I'm expecting 123.45 as the output, but instead I get 123.40
These are plain ACCEPTs, they only read in data from the command line (you can also enter a big lorem ipsum there).
While I think it is a reasonable request to have this working "as expected" the best option you currently have is ACCEPTing only PIC X and then use MOVE FUNCTON NUMVAL (INPUT-DATA) TO NUM (maybe test the data with FUNCTION TEST-NUMVAL() before). For DISPLAY you likely want an edited field with a PICTURE like ZZ9.99.
In any case: be aware that V is an implied decimal point, it is not part of the actual storage.
Using "extended" screenio (= input not from the command line) gives some benefits (like only allowing numeric data and not more than the fields's size) but has different culprits (for example you should use COLUMN/LINE for it and numeric ACCEPT still has some issues in GC 3.1).
As suggested by JoelFan I've tested edited fields - these work currently only correctly when in "command line mode" (so not if any attributes like positioning is used):
PROGRAM-ID. NUMTEST.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 NUM-INP PIC 999.99.
01 NUM PIC 999V99.
01 NUM-OUT PIC zz9.99.
PROCEDURE DIVISION.
DISPLAY "ENTER NUMBER: ".
ACCEPT NUM-INP.
DISPLAY "NUMBER = ".
MOVE NUM-INP TO NUM
MOVE NUM TO NUM-OUT
DISPLAY NUM "/" NUM-OUT.
STOP RUN.
Producing the expected result:
ENTER NUMBER:
123.45
NUMBER =
123.45/123.45
ENTER NUMBER:
1.2
NUMBER =
001.20/ 1.20
ENTER NUMBER:
a
NUMBER =
000.00/ 0.00
ENTER NUMBER:
1234567
NUMBER =
567.00/567.00
Note: the third case should actually raise an exception when compiled with -fec=all / -debug (currently doesn't), the last case is completely correct as numbers are right justified.
Still: ACCEPTing alphanumeric data, do explicit checks/conversions, and display as edited field like NUM-OUT above is the safest option.
I'm trying to write a COBOL module and having some variables in this file too:
IDENTIFICATION DIVISION.
PROGRAM-ID. UTIL.
DATA DIVISION.
LINKAGE SECTION.
01 MY_VAR PIC X(100).
DATA DIVISION.
WORKING-STORAGE SECTION.
01 RESULT PIC X(200) value SPACES.
PROCEDURE DIVISION USING MY_VAR.
STRING INPUT DELIMITED BY SPACE
' ' DELIMITED BY SIZE
MY_VAR BY SPACE
INTO RESULT
DISPLAY RESULT
EXIT PROGRAM.
For the input argument (MY_VAR) I use LINKAGE SECTION. I'm not sure how to use the WORKING-STORAGE SECTION statement to declare the RESULT variable.
How can I do that?
You should have 1 Data Division. Also, I think the order is not good for the Sections.
I advise looking at some Cobol documentation before coding.
IDENTIFICATION DIVISION.
PROGRAM-ID. UTIL.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 RESULT PIC X(200) value SPACES.
LINKAGE SECTION.
01 MY_VAR PIC X(100).
PROCEDURE DIVISION USING MY_VAR.
STRING INPUT DELIMITED BY SPACE
' ' DELIMITED BY SIZE
MY_VAR BY SPACE
INTO RESULT
DISPLAY RESULT
EXIT PROGRAM.
Are you using Cobol program on the mainframe of PC? If on PC - which Cobol program are you using?
If you are using a linkage section, first 2 bytes specify the length of the variable.
Also - I don't see the definition of the INPUT variable, unless INPUT is some kind of Cobol command (not recognized on the mainframe computers).
The correct syntax (on the mainframe) is:
LINKAGE SECTION.
01 link-parms.
05 LNK-PARM-LENGTH PIC S9999 COMP.
05 MY_VAR PIC X(100).
PROCEDURE DIVISION USING MY_VAR.
STRING INPUT DELIMITED BY SPACE
' ' DELIMITED BY SIZE
MY_VAR BY SPACE
INTO RESULT
DISPLAY RESULT
STOP RUN.
Is it possible to assign a string of hexadecimal to a comp or binary declared variable?
Example:
01 COMP-VAR PIC 9(4) COMP.
MOVE X'04D2' TO COMP-VAR.
should output +1234.
Edited:
Sorry for the lack of the information, I just gave an example. The real scenario is that the data will come from an external source, a dataset. I need to store the data in an alphanumeric variable before I move it to a comp declared variable. My problem is that the data is incorrect when I move the alphanumeric data to the comp variable. Your help is very much appreciated.
I think you are looking for REDEFINES. Redefine the binary value as character, do the assignment
which will not violate any of the assignment rules and then use the binary representation in
subsequent operations. This program illustrates your example:
IDENTIFICATION DIVISION.
PROGRAM-ID. EXAMPLE.
DATA DIVISION.
WORKING-STORAGE SECTION.
01.
02 COMP-VAR PIC 9(4) COMP.
02 COMP-X REDEFINES COMP-VAR PIC X(2).
PROCEDURE DIVISION.
MOVE X'04D2' TO COMP-X
DISPLAY COMP-VAR
GOBACK
.
This displays 1234.
The larger question is why would you need to do this? I suspect that you are attempting to
read a file with multiple record formats in it. Based on some common record identifier you
need to read part of the record as character or as binary. Typically this is done a little
differently in COBOL.
Here is a larger example of what I mean. Suppose you have an input
record that is 3 bytes long. When the first byte is a 'B' it is telling you that the next two bytes should be
treated as a binary (COMP) value. When the first byte is an 'X' you need to read the next two
bytes as text (X) data. As an example this is what two records might look like:
X'E7C1C2'
X'C204D2'
The first record is a text record containing the value 'AB' (EBCDIC). The second record is binary containing
the value 1234. The program to process these records might look something like:
IDENTIFICATION DIVISION.
PROGRAM-ID. EXAMPLE.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 INPUT-RECORD.
02 REC-TCD PIC X.
88 REC-TCD-BIN VALUE 'B'.
88 REC-TCD-CHAR VALUE 'X'.
02 REC-DUMMY PIC X(2).
02 REC-COMP-VAR REDEFINES REC-DUMMY PIC 9(4) BINARY.
02 REC-CHAR-VAR REDEFINES REC-DUMMY PIC X(2).
PROCEDURE DIVISION.
*
* THIS IS A CHARACTER RECORD
*
MOVE X'E7C1C2' TO INPUT-RECORD
PERFORM DISPLAY-INPUT-RECORD
*
* THIS IS A BINARY RECORD
*
MOVE X'C204D2' TO INPUT-RECORD
PERFORM DISPLAY-INPUT-RECORD
GOBACK
.
DISPLAY-INPUT-RECORD.
EVALUATE TRUE
WHEN REC-TCD-BIN
DISPLAY 'REC TYPE: ' REC-TCD
' BINARY DATA: ' REC-COMP-VAR
WHEN REC-TCD-CHAR
DISPLAY 'REC TYPE: ' REC-TCD
' CHAR DATA : ' REC-CHAR-VAR
WHEN OTHER
DISPLAY 'UNKNOWN RECORD TYPE: ' REC-TCD
END-EVALUATE
.
The output from this program is:
******************************** Top of Data ***********************************
REC-TYPE: X CHAR DATA : AB
REC-TYPE: B BINARY DATA: 1234
******************************* Bottom of Data *********************************
Look at the INPUT-RECORD definition. The first byte determines how the rest of the
record is to be intrepreted. REC-DUMMY is generally defined as a "generic" buffer area
to be subsequently redefined. In the case of variable length input records, REC-DUMMY
is defined to be as long as the longest record variant so the subsequent REDEFINEs of it
do not "upset" the compiler. All data items following REC-DUMMY begin with the same level
number (02 in the example) and REDEFINE it to the the appropriate format. Subsequent
processing uses whatever record redefinition is appropaiate based on the value in REC-TCD.
Is there anyway to get a SUBSTRING of string literal in COBOL without using a temporary variable?
Let's say in the following code:
MOVE "HELLO" TO MY-VAR.
MOVE MY-VAR(1:3) TO SUB-STR.
Is there any way to do the same thing, but without MY-VAR?
EDIT:
I did tried following code, but it's failed.
MOVE "HELLO"(1:3) TO SUB-STR * COMPILE ERROR
You can accomplish what you are trying to do by type-laundering the literal through a function. You can then substring, or reference modify, the output of the function. Consider that calling reverse twice on the same data returns the original data.
Move function reverse
( function reverse(
'abcdefg'
)
) (3:1) to text-out
The above will result in a 'c' being moved to text-out.
Of course, the example code in your question does not make any sense, as why would you write "HELLO"(1:3) when you could just write "HEL".
So you must be wanting to use a variable (or 2) in the reference modifier field(s).
If you are wanting to get the first 'N' characters of the literal, you can do this by using the reference modifier on the destination item. For example, if you compile and run the following program:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 LEN PIC 99 VALUE 8.
01 SUB-STR PIC X(80).
PROCEDURE DIVISION.
MOVE "HELLO WORLD" TO SUB-STR(1:LEN).
DISPLAY SUB-STR.
STOP RUN.
You get the resulting output:
HELLO WO
Unfortunately this method only works if you want the first 'N' characters of the literal string.
Also, the destination string must be empty before you start. In the above program, if you changed the definition of SUB-STR to be:
01 SUB-STR PIC X(80) VALUE "BLAH BLAH BLAH".
Then the result of running the program becomes:
HELLO WOH BLAH
Put the "literal" into a field, like a constant.
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 LITERAL-HELLO PIC X(5) VALUE 'HELLO'.
PROCEDURE DIVISION.
DISPLAY LITERAL-HELLO(1:3).
STOP RUN.
I'm coding routines like:
READ-A.
READ FILE-A
AT END
MOVE 1 TO EOF-A
NOT AT END
ADD 1 TO CN-READ-A
END-READ.
F-READ-A. EXIT.
to read several files and I was wondering if there's a way to code a routine that is able to read the filename from a variable so I don't have to code the same thing for each file. Thanks!
One solution as said above is to use multiple programs or nested program, for which
I have included an example below, which is solution 1.
Another solution is to COBOL classes, which might not be to your liking but I like them, so I've included an example, which is solution 2.
Solution 1:
program-id. TestProgram.
working-storage section.
01 file-name pic x(128).
01 file-lines pic 9(9).
procedure division.
move 0 to file-lines
move "d:\rts_win32.txt" to file-name
call "program1" using file-name file-lines
display file-lines
stop run
end program TestProgram.
program-id. Program1.
file-control.
select file-a assign to myfile
organization is line sequential.
data division.
fd file-a.
01 file-a-line pic x(80).
working-storage section.
01 EOF-A pic 9 value 0.
linkage section.
01 lk-filename pic x(128).
01 CN-READ-A pic 9(9).
procedure division using lk-filename
CN-READ-A.
move lk-filename to myfile
open input file-a
perform READ-A until EOF-A equals 1
close file-a
goback.
READ-A.
READ FILE-A
AT END
MOVE 1 TO EOF-A
NOT AT END
ADD 1 TO CN-READ-A
END-READ.
F-READ-A.
EXIT.
end program Program1.
Solution 2
program-id. TestProgram.:
working-storage section.
01 file-counter type FileLineCounter.
procedure division.
set file-counter to new type FileLineCounter("d:\rts_win32.txt")
display file-counter::LineCount
stop run
end program TestProgram.
class-id FileLineCounter.
file-control.
select file-a assign to myfile
organization is line sequential.
data division.
fd file-a.
01 file-a-line pic x(80).
working-storage section.
01 cn-read-a binary-long property as "LineCount".
method-id New.
01 EOF-A pic 9 value 0.
procedure division using by value filename as string.
set myfile to filename
open input file-a
perform READ-A until EOF-A equals 1
close file-a
goback.
READ-A.
READ FILE-A
AT END
MOVE 1 TO EOF-A
NOT AT END
ADD 1 TO CN-READ-A
END-READ.
F-READ-A.
EXIT.
end method.
end class.
May not be "in the wild" yet with compiler support, but the current ISO Draft 20xx standard includes FUNCTION-ID in place of PROGRAM-ID. It adds a parameter friendly function call computing paradigm to COBOL.
Might not help today, but maybe in the near future. If I'm not mistaken, User Defined Functions are actually from the COBOL 2002 spec, but it seems compiler vendors are hit or miss on support for the feature.
FUNCTION-ID support is in closed trials for OpenCOBOL 2.0, but the timeline for the 2.0 release is undetermined and could be another year or more before it's made public.
The proper Cobol way to parameterize routines is via the nested subprogram.
You can do what you want, but it is dependant upon your compiler and environment, you can pass a file, or a file name, or a DDname.
What platform are you on?
Edit: On z/OS, you can change what FILE-A points to at runtime using putenv() to adjust the dataset name associated with the DDNAME that FILE-A uses.
See:
http://ibmmainframes.com/post-57281.html
http://cicswiki.org/cicswiki1/index.php?title=How_do_I_allocate_a_file_dynamically_using_COBOL%3F
You will need a OPEN-A and CLOSE-A paragraph as well between switching files.
It isn't exactly passing parameters to your read statement, but it lets you reuse your OPEN/READ/WRITE/CLOSE statements for different files. But only serially.
There was a way, under VS COBOL II, where you could pass an FD to a subprogram, that would look something like:
CALL MYREADPGM USING FILE-A
CALL MYREADPGM USING FILE-B
This possible with Enterprise Cobol but IIRC VisualAge does not support that.
I realize this is an old thread, but hopefully someone might find this useful in the future: IBM's Enterprise COBOL on z/OS 6.4 compiler supports user-defined functions (released May 2022). User-defined functions could be a useful alternative to the other suggestion for internal programs. In contrast to program calls, there are compile time checks for parameters to user-defined function invocations. Also, you can invoke the function in a lot of places where you couldn't call a program, like within a
n expression.
Here's an example based on passing a file name to a function. It might be possible to combine this with the PUTENV() suggestion above.
IDENTIFICATION DIVISION.
FUNCTION-ID. READ-FILE.
DATA DIVISION.
LINKAGE SECTION.
1 FILE-NAME PIC X(50).
1 RET PIC 9(9).
PROCEDURE DIVISION USING FILE-NAME RETURNING RET.
* DO STUFF WITH FILE-NAME
* ...
GOBACK
.
END FUNCTION READ-FILE.
IDENTIFICATION DIVISION.
PROGRAM-ID. MAINPROG.
DATA DIVISION.
WORKING-STORAGE SECTION.
1 READ-RESULT PIC 9(9).
PROCEDURE DIVISION.
COMPUTE READ-RESULT = FUNCTION READ-FILE('MYINPUTFILE')
GOBACK
.
END PROGRAM MAINPROG.
More examples can be found in the Programming Guide Chapter 32 Using user-defined functions.
https://www.ibm.com/support/pages/enterprise-cobol-zos-documentation-library#Table642
You could create a data file of filenames, treat each one as an individual record, and then read each file. In the "SELECT ...ASSIGN" you would need to use a working-storage variable for the filename and move the value from the 'file of filenames' into it.
As you are using VisualAge, I assume in UNIX, you might also be able to run the program from the shell (sh,ksh), with the filename as a parameter, and repeatedly run the program from the shell for each file name.