Highlighted
Trusted Contributor.
Trusted Contributor.
1651 views

NetExpress programs and Visual COBOL programs on the same computer

Jump to solution

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

0 Likes
1 Solution

Accepted Solutions
Highlighted
Trusted Contributor.
Trusted Contributor.

I ran into this problem again.  For months programs have been running smoothly and. suddenly, today, I must have changed something that had an effect on the calling sequences in DLLs because I started getting the same message about missing "pscore5.dll" when calling "DSGRUN" for all but a few programs. 

When I checked the MODULES debug screen, I saw that when the program called a subroutine which called DSGRUN to show a form, then, behind the scenes, the system was loading MFFH.dll for some reason, and loading library caused it to try to resolve an entry point in PSCORE5.dll for some strange reason.  That dll comes from ACTIAN and is a PSQL or Btrieve dll.  Why in the world DSGRUN needs to call Btrieve is beyond me.  I remembered, in vaguely similar problem, that Chris Glazier suggested I use a procedure pointer.  I set one up, pointed it at "DSGRUN" and the error went away.  I guess the software needs to have a little guidance as to where it should start resolving its entry points.  This is discussed in the Visual COBOL documentation article entitled "Loading a Dynamic Link Library Built as Native COBOL Code"  I don't know if either DSGRUN or MFFH are built as Native COBOL code but, evidently, just setting the procedure pointer causes the library to be loaded so that the entry point can be resolved without having to go search for it.

To set up the procedure pointer, I defined it in working storage:

01    PP        procedure-pointer.

Then just before my call, I set the procedure pointer to the name of the DLL:

SET PP TO ENTRY "DSGRUN".
CALL "DSGRUN"  USING DS-CONTROL-BLOCK

I don't encounter this problem when I call DSGRUN or _BTRV from my main program.  It occurs when I call them from a subroutine written in Native code COBOL as a DLL and I do dynamic linking.


View solution in original post

0 Likes
11 Replies
Highlighted
Absent Member.
Absent Member.
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
Highlighted
Micro Focus Expert
Micro Focus Expert

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.

Highlighted
Trusted Contributor.
Trusted Contributor.
Thank you Neil. I am already linking with dynamic binding.
0 Likes
Highlighted
Trusted Contributor.
Trusted Contributor.
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
0 Likes
Highlighted
Trusted Contributor.
Trusted Contributor.
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.
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert
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.
Highlighted
Trusted Contributor.
Trusted Contributor.
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.
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert
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...
Highlighted
Trusted Contributor.
Trusted Contributor.
Yep, copied the files from SysWOW64 and System32 a while back just to get the programs working on a workstation that had never had the Net Express programs. Looks like this is outside the realm of Visual COBOL and in the world of Btrieve and PSQL. I'll investigate that further. Thanks for the info and I'll look for the update on the documentation. I am running version 4.0 and VS2017.

I appreciate the answers and the thought put into them. At least now I know I am not missing anything on the Visual COBOL end of things.
0 Likes
Highlighted
Trusted Contributor.
Trusted Contributor.

I ran into this problem again.  For months programs have been running smoothly and. suddenly, today, I must have changed something that had an effect on the calling sequences in DLLs because I started getting the same message about missing "pscore5.dll" when calling "DSGRUN" for all but a few programs. 

When I checked the MODULES debug screen, I saw that when the program called a subroutine which called DSGRUN to show a form, then, behind the scenes, the system was loading MFFH.dll for some reason, and loading library caused it to try to resolve an entry point in PSCORE5.dll for some strange reason.  That dll comes from ACTIAN and is a PSQL or Btrieve dll.  Why in the world DSGRUN needs to call Btrieve is beyond me.  I remembered, in vaguely similar problem, that Chris Glazier suggested I use a procedure pointer.  I set one up, pointed it at "DSGRUN" and the error went away.  I guess the software needs to have a little guidance as to where it should start resolving its entry points.  This is discussed in the Visual COBOL documentation article entitled "Loading a Dynamic Link Library Built as Native COBOL Code"  I don't know if either DSGRUN or MFFH are built as Native COBOL code but, evidently, just setting the procedure pointer causes the library to be loaded so that the entry point can be resolved without having to go search for it.

To set up the procedure pointer, I defined it in working storage:

01    PP        procedure-pointer.

Then just before my call, I set the procedure pointer to the name of the DLL:

SET PP TO ENTRY "DSGRUN".
CALL "DSGRUN"  USING DS-CONTROL-BLOCK

I don't encounter this problem when I call DSGRUN or _BTRV from my main program.  It occurs when I call them from a subroutine written in Native code COBOL as a DLL and I do dynamic linking.


View solution in original post

0 Likes
Highlighted
New Member.

One thing to watch out for is people deploying applications without keeping to the Microsoft guidelines. Some of our customers purchased another application where it deployed runtime files into the windows\system32 folders.

Regardless of how you have compiled your application, if the windows\system32 contains runtimefiles it will load them and you then get strange behaviour in your application. Running procmon from sysinternals allowed me to validate that the runtime was being loaded from where I expect. 

 

 

 

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.