Highlighted
Absent Member.
Absent Member.
2260 views

COPYBOOK Naming Conventions in Visual COBOL versus RM/COBOL

Jump to solution

[Migrated content. Thread originally posted on 24 February 2011]

Hello, I'm having an issue when I try to build my project. My initial program has a copybook statement as follows: COPY "LS/POPUP". My copybooks are stored under a folder called COPY with subfolders called DS, LS, FC, FD, WS, etc.. The compiler is trying to use the wrong copybook. It is locating WS/POPUP instead of LS/POPUP. When I check the dependencies under the program's COBOL File Properties, it shows COPY\WS\POPUP.cbl. How can I alter the dependency to point to the correct copybook, or do I have to change my naming conventions for my copybooks?
0 Likes
1 Solution

Accepted Solutions
Highlighted
Absent Member.
Absent Member.

RE: COPYBOOK Naming Conventions in Visual COBOL versus RM/COBOL

Jump to solution
As an alternative based on your copybooks directory structure , the following may be used:

Specify copybooks location relative to the COBOL source:
copy "Copylib/RM/Copy01".
copy "../RMCopy/Copylib/RM/Copy01".
copy Copy01 of "../RMCopy/Copylib/RM".
copy Copy01 of ../RMCopy/Copylib/RM.

Under Windows SUBSTitute a drive letter to your base copybook directory
(for example subst Z: Y:\...\RMS6111\COM)

copy "Z:/RM/Copy01".

Using "/" or "\" will be accepted.

View solution in original post

0 Likes
4 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: COPYBOOK Naming Conventions in Visual COBOL versus RM/COBOL

Jump to solution
There may actually be a bug here that I will investigate but the only way that I can currently get this to work is:

Modify copybook to point to full path name:

COPY "C:\Copy\LS\POPUP".

or to remove the folder name from the copy and add a copybook Path to the Copybook Path tab of the Properties page:

COPY "POPUP".
with Copybook Path set to:
C:\Copy\LS\
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: COPYBOOK Naming Conventions in Visual COBOL versus RM/COBOL

Jump to solution
Thanks Chris for looking into this. I'm not sure your solutions will work for us. Unfortunately, we use the same copybook name in different parts of our code. For example, we have a file called SICNTL. We create copybooks, "FC/SICNTL", "FD/SICNTL", "DS/SICNTL" and "PD/SICNTL". These are four different copybooks stored in four different subfolders. We have multiple versions of our software and each version is using a different main folder, i.e. \RMS620\COM\FC versus \RMS611\COM\FC. I was using "\COPY" as an example in my original post. So we can't hardcode the path and pointing the program to use a specific copybook will not allow me to use all four.

Any other suggestions?
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: COPYBOOK Naming Conventions in Visual COBOL versus RM/COBOL

Jump to solution
It appears that this form of the copy statement is not currently supported but development is looking into it.
Thanks for your patience!
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: COPYBOOK Naming Conventions in Visual COBOL versus RM/COBOL

Jump to solution
As an alternative based on your copybooks directory structure , the following may be used:

Specify copybooks location relative to the COBOL source:
copy "Copylib/RM/Copy01".
copy "../RMCopy/Copylib/RM/Copy01".
copy Copy01 of "../RMCopy/Copylib/RM".
copy Copy01 of ../RMCopy/Copylib/RM.

Under Windows SUBSTitute a drive letter to your base copybook directory
(for example subst Z: Y:\...\RMS6111\COM)

copy "Z:/RM/Copy01".

Using "/" or "\" will be accepted.

View solution in original post

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.