Rocket COBOL extension for VSCode fails to find Copy Books or other COBOL files located in different folders

Hi.

We are trying to setup a COBOL project, originally setup with Enterprise Developer (Micro Focus) for Eclipse, within VSCode using the Rocket COBOL extension.

This project uses multiple folders, each of one hosted within different Git repositories.

At first, we just imported the main folder, containing the main .cobolProj file from the original Eclipse project.

However, no copybooks or other COBOL files referred from this .cobolProj file seems to be discovered by the extensión.

We get COBCH0008 errors showing  "unknown copy file filename" for example, on COBOL files using the COPY directive.

We then tried to import additional folders containing these copybooks into a VSCode workspace, but to no avail.

Our question is :  Does the Rocket COBOL extension for VSCode work as expected, with a multi-folder project ?

Just as an example, the <copybook> section of the main .cobolProj file looks like this:

<copybook-paths xsi:type="copybookPathsSettings">
         <path enabled="true" name="/FF" type="mfpath"/>
         <path enabled="true" name="/FF/DTLS" type="mfpath"/>
         <path enabled="true" name="/FF/FUENTES" type="mfpath"/>
         <path enabled="true" name="/FF/FUENTES/_COMPINFO" type="mfpath"/>
         <path enabled="true" name="/FF/PROCS" type="mfpath"/>
         <path enabled="true" name="/FF/SISTEMA" type="mfpath"/>
         <path enabled="true" name="/FF/SORTS" type="mfpath"/>
         <path enabled="true" name="D:\\Cobol\\REHOSTIN\\COMUNES\\COPYS" type="syspath"/>
         <path enabled="true" name="D:\\Cobol\\REHOSTIN\\CopysTER\\COPYS" type="syspath"/>
         <path enabled="true" name="D:\\Cobol\\REHOSTIN\\INFRA\\MFA.COBOL" type="syspath"/>
         <path enabled="true" name="D:\\Cobol\\REHOSTIN\\INFRA\\MFA.COPYLIB" type="syspath"/>
         <path enabled="true" name="D:\\Cobol\\REHOSTIN\\INFRA\\MFA.COPYLIB.BATCH" type="syspath"/>
         <path enabled="true" name="D:\\Cobol\\REHOSTIN\\INFRA\\RP.COPYS.ASM" type="syspath"/>
      </copybook-paths>

We tried changing some of the paths using Unix-style slashes, or adding double backslashes on Windows etc... but to no avail.

Copy books are not recognized, even the COBOL Language Server is up and running correctly.

Any ideas as to why this is not working ?

Thanks

Miguel

Hi Miguel,

The VSCode extension does not recognize directives such as the copy path which are set in an Eclipse project file, for use in a background parse in the editor.  The .cobolBuild project file can be used in a build task, if you have Ant installed and setup correctly within your VSCode Default Directives settings, and it will use the directives set within the project file.

If you wish to set directives to be used by the background parse you can set them in a couple of ways.

1. You can set the directives such as copypath in the Default Directives section of the Rocket Extension settings.
   
2. Create a directives.mf file in the work folder that contains the directives which you would like to set:
   
3. For the copy paths you could also set the COBCPY environment variable in your computer's environment prior to starting VSCode.

Thanks for the reply.

So far, we have configured Ant + Java, and we have been able to call the COBOL: Ant (.cobolBuild) , which apparently can compile the whole source code successfully.

So, we tried adding the directive copypath(c:\\mycopy1;c:\\mycopy2)   (using our own paths of course) into the Rocket Extension settings, but the problem persists. Not sure if using directives.mf or the COBCPY environment will make any difference.

Are we missing anything here ? It's worth noticing that folders containing our copybook files have "spaces" in the folder name. Does this require special handling ?

Thanks in advance,

Miguel

Try enclosing each of the path names within quotes.

copypath("c:\\my copy1";"c:\\my copy2")

Yeah that's the first thing we tried, but no effect !!

Let us know if there is anything else we can try.

Thanks.

Miguel

Adding the quotes works for me.

Can you show me what your copypath directive looks like?

Something to consider:

Do the copybook folders have to be added as part of the VSCode workspace, (so we could probably refer to them with relative paths within the copypath directive) ? Or can they just be referenced from the copypath directive, using absolute paths, no matter if they are available inside the workspace or not ? 

No, the copybook paths can be absolute paths as in my example.

Can you show me what one of your copy statements looks like?

Actually, instead of surrounding each path with quotes, try surrounding the whole thing with quotes.

Instead of: copypath("c:\\my copy1";"c:\\my copy2")

Use: copypath("c:\\my copy1;c:\\my copy2")

That was it !!

Working perfectly now !

Many thanks for the great tip

Miguel

Just to shed a little more light on this, there are 2 separate things at play here.

1. The VS Code extension with its Language Server
2. Eclipse project file (.cobolBuild)...along with the build task which uses ant and the .cobolBuild project/ant file.

The VS Code extension and the Language Server used for background parsing aren't aware of the Eclipse project file. Those errors are a result of the Language Server not being able to resolve the copybooks. However, the project still builds, because you are using the Build task configured with ant and the .cobolBuild project file...i.e. 2 separate things.

If you turn off the Language server the parsing errors go away and you can still build using the Build task that uses ant and the .cobolBuild project file. However, you also lose the Language Server functionality.

To leverage both you can follow the suggestions that Chris gave.

The directives.mf file especially works well with the Language Server and lets you set directives per folder structure with the ability to override. It also is useful if you want to setup other build tasks that don't use the .cobolBuild file. It is nice for setting up directives outside of the Eclipse project file to be used on a project by project basis.

Here is a sample directives.mf file that could be placed in your project folder (or wherever you choose).

e.g.

A project folder that contains:

ProjectFolder

    --> cbl

    --> copybooks

    --> directives.mf

    --> .etc.

--- beginning of directives.mf file

Thanks for the detailed explanation. Much clear now.

Nonetheless, there's one thing we didn't figure out yet.

If we set the Windows environment variable COBCPY , and then we use the following sentence inside directives.mf:

@root

[*.cbl]

COPYPATH("${env.COBCPY}")

Compilation of a COBOL file works fine, and copybooks can be found.

However, if we set the value of COBCPY directly inside the COPYPATH directive (exactly as we did with the Default Directives configuration of the Rocket Extension), such as:

@root

[*.cbl]

COPYPATH("D:\\Jose curro\\REHOSTIN\\COMUNES\\COPYS;D:\\Jose curro\\REHOSTIN\\CopysTER\\COPYS;D:\\Jose curro\\REHOSTIN\\INFRA\\MFA.COBOL;D:\\Jose curro\\REHOSTIN\\INFRA\\MFA.COPYLIB;D:\\Jose curro\\REHOSTIN\\INFRA\\MFA.COPYLIB.BATCH;D:\\Jose curro\\REHOSTIN\\INFRA\\RP.COPYS.ASM")

compilation of a COBOL file fails with the following exception:

It looks like it does not like the backslash character.  We tried using double backslash "\\\\" but same problem arises.

It's not a big issue as long as using the env.COBCPY works, but the team mentioned that they would prefer to have the paths "hardcoded" on the directives.mf, as the idea is that everyone will have the copybooks on the same folders. (and probably commited to a git repo). So there should be no need to set the Windows environment variable (which would need to be re-created every time a dev gets a new laptop)

Thanks & Best regards,

Miguel

Is COPYPATH("${env.COBCPY}") really working or is it just the fact that you have the COBCPY environment variable set anyways and that is being picked up?

In your screenshot it is the compile build task that is failing.

Are the copybooks found using directives.mf for the background parse if you have your source file open in the editor?

I noticed that in your build task you seem to be referencing a source file which is in a different folder on the D drive. I find that when specifying this that the directives.mf file needs to be present in the same folder as the source resides as this becomes the current directory when the compile is run.

Can you show me what your build task looks like?

I tested this here using V9.0 PU10 and it is all working correctly.

Thanks.

 Hi, sorry for late reply.

So if I understand correctly, if we have this build configuration from MF (simplified for readability)

<copybook-paths xsi:type="copybookPathsSettings">
         <path enabled="true" name="/FF" type="mfpath"/>
         <path enabled="true" name="/FF/SORTS" type="mfpath"/>
         <path enabled="true" name="D:\\Cobol\\REHOSTING\\COMUNES\\COPYS" type="syspath"/>
         <path enabled="true" name="D:\\Cobol\\REHOSTING\\CopysTER\\COPYS" type="syspath"/>
 </copybook-paths>

What you are saying is that we should have a directives.mf file on each of those 4 folders ( each of the <path> xml tags ), or in other words, the folders of the current workspace, plus the external D:\\ folders which may not be opened on the current VSCode workspace.

 Thanks & Best regards,

Miguel

The source and copybook paths set in an Eclipse project will be used for the build with ant. You do not need a directives.mf file for that. You need the directives.mf (or COBCPY or default directives), for the background parse being done on a source file open in the editor.

If you are using different folder locations to hold your source files and you are opening these folders in VSCode then each of those folders should have a directives.mf file which contains a copypath directive pointing to the folders that contain the copybooks used in those sources.

If the source file folders have a common parent folder, then the directives.mf can be placed there instead. Please see the docs here:

The copypath directive is for locating copybooks only. (files specified in a COPY statement) and not main source programs.

Does this answer your question?