Visual Cobol R3 Development Hub - Project path

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

I have installed the Visual Cobol R3 Development Hub on Linux.

I want to make a new remote project from my Windows Eclipse Environment, but i get the following error :

The remote location does not match the directory on the local path. Make sure the remote location is mapped by the local path.

On Windows my project directory is c:\viscob\TestRemote, on Linux my project directory is /ux/microfocus/VisualCOBOL/progs/viscob/TestRemote.

Is something wrong in my configuration ?


  • According to the docs, the location field should contain the Windows pathname to the project containing an NFS mapped drive and the remote location should contain the Linux pathname to that same location.

    The example they give is:

    a Location of X:NFS-mounted-drive location\project name should be represented by a Remote location of /NFS-mounted-drive location/project name.

    So the names should point to the same location on the remote computer.

    So your location field should be set to the NFS mounted drive on the remote computer not the local C: drive.
    So if you mapped X: to /ux/microfocus/VisualCOBOL/progs/viscob then your settings would be:
    Location = X:\TestRemote
    Remote Location: /ux/microfocus/VisualCOBOL/progs/viscob/TestRemote

    This is how I interpret the docs but I don't have the Linux hub installed at the moment so I cannot test this.

  • Chris,

    when someone works on a remote project, what access does he need to that remote project ?
    What protocols and ports are used ?

    Ssh and/or telnet for Eclipse Remote Systems AND a samba share to the development system ?


  • Verified Answer

    Samba is the most common way of accessing the projects, though we have tested nfs between Unix machines as well. As long as the portion of the Unix disk is accessible on the Windows box it shouldn't matter whether Samba, nfs or something else is used.

    Ssh and/or telnet aren't necessarily required, but depending on how you want to run your program (for example if you wanted to start it on a terminal, then attach to it) you might find them useful.

    The default port used by the daemon that handles connections is 4075, though it can be started on a different one if you want. If you connect to that, it will start a new server and dynamically assign a port for that (usually a number in the 5 digit region). Though you can configure things differently if you do not want the dynamic port allocation.

    When debugging is started one more port is used, by default a the number being dynamically allocated, but you can specify the number on the debug configuration dialog if required.