NetExpress programs and Visual COBOL programs on the same computer

I have existing programs compiled using Net Express that I run from a shared folder on a file server and I have programs compiled using native Visual COBOL which I run from a shared folder residing on a COBOL Server.  How do I run the native Visual COBOL programs on a computer where the user is also running Net Express programs?  Since all of the runtime files are on the COBOL Server, can I run a batch file or something to set the PATH environment to run the Visual COBOL programs?  When I try now I receive a message that says "The program can't start because api-ms-crt-runtime-l1.dll is missing"  When I copy one of the 20 instances of api-ms-crt-runtime-l1.dll from another computer into my COBOL Server folder containing the EXE file, I receive a message saying "entry point ucrtbase.abort cannot be found in dynamic link library api..."   How do I get the files that I need onto the COBOL Server?

On computers that do not run Net Express programs, the native Visual COBOL programs run without these messages.  I am running them using at Batch file that pre-pends the COBOL Server folders to the PATH environment variable.

rem --------------------------------------------
rem   batch file to run Visual COBOL programs
rem --------------------------------------------
PATH=\\SQLPRDSVR1\COBOLServer\bin;\\SQLPRDSVR1\APPS\COBOL\BIN;%PATH%
TMS010DV.exe SC
pause

  • If you compile your main executable with dynamic binding it will use the registry to locate the runtime and you don't need to set any PATH variables.

    If you need to set COBDIR or COBPATH you can set it in code as your executable starts to run.

    You can then have NetExpress and Visual COBOL programs running on the same machine without problems.

    Neil
  • If you compile your main executable with dynamic binding it will use the registry to locate the runtime and you don't need to set any PATH variables.

    If you need to set COBDIR or COBPATH you can set it in code as your executable starts to run.

    You can then have NetExpress and Visual COBOL programs running on the same machine without problems.

    Neil
  • If you compile your main executable with dynamic binding it will use the registry to locate the runtime and you don't need to set any PATH variables.

    If you need to set COBDIR or COBPATH you can set it in code as your executable starts to run.

    You can then have NetExpress and Visual COBOL programs running on the same machine without problems.

    Neil
  • The file that is being reported as missing appears to be a part of the C Redistributable run-time for Visual Studio 2015. I don't know of any dependency on this file from within the Visual COBOL application but I would recommend that instead of copying it from another computer into the bin folder on the server that you install the C run-time on the workstations directly.

    You must keep the paths to the server products separate on the workstations. If you run a NX application then you should only have the PATH and COBDIR set to point to the Server for COBOL folders on the server. Likewise for Visual COBOL the PATH should only contain the COBOL Server\bin folders and for VC, COBDIR should only be set to point to the install folder of the COBOL Server product. This is not the bin folder as it may have been under NX. In VC COBDIR should point to the main folder. If this is on your server then it might be something like \\SQLPRDSVR1\COBOLServer.

    When you are running from a workstation on which no COBOL Server is installed we recommend that you use a run-time launch file and set the PATH and the licensing location in this file.

    SET SERVERPATH=\\SQLPRDSVR1\COBOLServer

    SET CESDYNAMIC=ces.ini

    The instructions for setting this up are in the Deployment section here.

  • Thank you Neil. I am already linking with dynamic binding.
  • Thank you Chris. As you can see from my question, my path is set as you suggested. My mfdefault.exe.mfcfg looks like this:
    SETENV MFCES_INIT_LOCATION=\\SQLPRDSVR1\COBOLServer\Bin\ces.ini
    SETENV PATH=\\SQLPRDSVR1\COBOLServer\Bin;\\sqlprdsvr1\apps\cobol\bin;%path%
    SETENV TESTDATA=NO
    SETENV MFVSSW=/c/f
    SET SERVERPATH=\\SQLPRDSVR1\COBOLServer
    SET CESDYNAMIC=ces.ini
  • There must be some dependency on the C redistributable run-time if the message appears. I would expect it to be resolved from the server rather than locally. The idea of using the server is that I would not have to install software on the client workstation in order to run the programs. I'll try installing the C redistributable on one workstation and see if that works as a temporary work-around for the problem.
  • All COBOL code is dependent on a version of the Microsoft C run-time so although there won't necessarily be a direct reference to ucrtbase.abort anywhere in the COBOL code any one of the C run-time dlls may require it so the C redistributable files have to be installed for the references to be resolved. The folder(s) containing the COBOL Server do not, as far as I am aware, contain the C run-time.
  • That makes sense to me. I would still expect them to be resolved from the server. Just now I downloaded and installed the C redistributable for Visual Studio 2017 (that is what I am using to compile and link my COBOL programs) and I am receiving a different message "pscore5.dll is missing from your computer" Using Process Explorer, I see that it might be a problem with the Btrieve subroutines I am calling rather than the Visual COBOL software.
  • The C redistributable run-time files installed on the server are not available to your application which runs on a workstation. That is because they are installed into the C:\Windows\system32 and C:\Windows\SysWOW64 folders on the server. They are not available unless you copy them from the system folders to your COBOL bin folder which is part of the process documented in the link I provided.

    There is a bug report for the docs because they currently reference the C run-time files for Visual Studio 2012 which were the ones required in the 3.0 product release. They should be referencing the ones for Visual Studio 2017 instead. This will be fixed in a patch update.

    If you copy over the correct run-time files for VS2017 on your server into your COBOL bin folder then you shouldn't have to install the run-times locally on the workstations.

    I don't know anything about Btrieve requirements...