Highlighted
Absent Member.
Absent Member.
1946 views

sqlca.cbl vs sqlca.cpy in command line compiling

Jump to solution

For embedded DB2 SQL application, I figure it out that I can use command line to create the application.

cob64 -C MFSYNC -z -o myTest myTest.cbl sqlca.cpy -L/home/db2inst1/sqllib/lib64 -ldb2 -ldb2gmf

But I got this error :

/bin/ld:sqlca.cpy: file format not recognized; treating as linker script
/bin/ld:sqlca.cpy:1: syntax error
collect2: error: ld returned 1 exit status

But if I rename sqlca.cpy as sqlca.cbl.  run above command line as:

cob64 -C MFSYNC -z -o myTest  myTest.cbl  sqlca.cbl -L/home/db2inst1/sqllib/lib64 -ldb2 -ldb2gmf

Everything is fine. 

Why cob64 does not know to compile sqlca.cpy file but only compile sqlca.cbl file?

But in Visual COBOL, it uses sqlca.cpy without any issue.

Appreciated for the help.

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: sqlca.cbl vs sqlca.cpy in command line compiling

Jump to solution

Hi Jack,

It seems like you are trying to specify the location of the sqlca copy file as part of your cob command. There should be no need to specify COBOL copy files, such as sqlca.cpy, on the cob command line.

Assuming that your COBOL program includes a COPY or INCLUDE statement to reference the copy file, something like:

copy sqlca.

     or

EXEC SQL INCLUDE sqlca END-EXEC.

the copy file will automatically be included into your source at compile time.

If the copy file is not in your current directory, you can use the COBCPY environment variable to specify a path to search for copy files. For example [replace the directories with your actual copy file location(s)]:

export COBCPY=/copy/file/path1:/copy/file/path2

cob64 -C MFSYNC -z -o myTest myTest.cbl -L/home/db2inst1/sqllib/lib64 -ldb2 -ldb2gmf

Also, since your COBOL program is working with a database, I believe you should be creating a multithreaded executable. You might want to try adding the -t flag to your compile command:

cob64 -t -C MFSYNC -z -o myTest myTest.cbl -L/home/db2inst1/sqllib/lib64 -ldb2 -ldb2gmf

Blair McDonald

View solution in original post

0 Likes
4 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: sqlca.cbl vs sqlca.cpy in command line compiling

Jump to solution

Hi Jack,

It seems like you are trying to specify the location of the sqlca copy file as part of your cob command. There should be no need to specify COBOL copy files, such as sqlca.cpy, on the cob command line.

Assuming that your COBOL program includes a COPY or INCLUDE statement to reference the copy file, something like:

copy sqlca.

     or

EXEC SQL INCLUDE sqlca END-EXEC.

the copy file will automatically be included into your source at compile time.

If the copy file is not in your current directory, you can use the COBCPY environment variable to specify a path to search for copy files. For example [replace the directories with your actual copy file location(s)]:

export COBCPY=/copy/file/path1:/copy/file/path2

cob64 -C MFSYNC -z -o myTest myTest.cbl -L/home/db2inst1/sqllib/lib64 -ldb2 -ldb2gmf

Also, since your COBOL program is working with a database, I believe you should be creating a multithreaded executable. You might want to try adding the -t flag to your compile command:

cob64 -t -C MFSYNC -z -o myTest myTest.cbl -L/home/db2inst1/sqllib/lib64 -ldb2 -ldb2gmf

Blair McDonald

View solution in original post

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: sqlca.cbl vs sqlca.cpy in command line compiling

Jump to solution

Thank you, Blair

I tried your instruction.

echo $COBCPY
/home/db2inst1/sqllib/include/cobol_mf:/opt/microfocus/VisualCOBOL/cpylib

I have the $COBCPY setup correctly,  I also have "EXEC SQL INCLUDE sqlca END-EXEC" in mytest.cbl

cob64 -t  -C MFSYNC -z -o mytest  mytest.cbl -L/home/db2inst1/sqllib/lib64 -ldb2 -ldb2gmf

rwxr-xr-x 1 db2inst1 db2iadm1 13919 Apr 29 16:10 mytest

You can see the file size is 13919 bytes

cob64 -t  -C MFSYNC -z -o mytest  mytest.cbl sqlca.cbl -L/home/db2inst1/sqllib/lib64 -ldb2 -ldb2gmf

-rwxr-xr-x 1 db2inst1 db2iadm1 18582 Apr 29 16:06 mytest

The file sizes are different.  both work under DB2. it seems sqlca.o is linked into the later one. but the first one just call it at run-time.  I feel confused.

To my expectation, the file size for both should be the same. no matter explicitly or implicitly to include sqlca.cpy.

Thank you again,

-Jack

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: sqlca.cbl vs sqlca.cpy in command line compiling

Jump to solution

I really like the performance with "-t" flag as you suggested for multi-threading.

Thank you, Blair

-Jack

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: sqlca.cbl vs sqlca.cpy in command line compiling

Jump to solution

Hi Jack,

I'm glad to hear that the -t flag suggestion was helpful.

Typically, sqlca is just the name of a copy file, which contains additional source code for inclusion into your COBOL program. There is no need to separately compile sqlca. I believe you said you created sqlca.cbl by copying sqlca.cpy - this should not be necessary.

As you've noticed, when you add sqlca.cbl to the cob command, cob will treat it as a completely separate COBOL program, and compile it (just as any other .cbl file), creating a separate object file (.o) file for it. This (unnecessary) .o file would then be linked into the resulting shared object (.so) file, increasing the size of the resulting .so.

Blair McDonald

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.