Skip to main content

Creating a COBOL console application solution I don't seem to be able to run the compiled EXE file by double-clicking it.

I get a system error message telling me that "cblrtsm.dll" is missing:

 

I can debug the file without flaw from within the IDE.

Am I missing something? How can I start the EXE file from the Windows shell?

I read through the documentation at Building COBOL Applications and Running Applications (Native COBOL), but the information there couldn't shed any light on my problem. The only issue I found in the forums so far didn't yield a result, too.

Creating a COBOL console application solution I don't seem to be able to run the compiled EXE file by double-clicking it.

I get a system error message telling me that "cblrtsm.dll" is missing:

 

I can debug the file without flaw from within the IDE.

Am I missing something? How can I start the EXE file from the Windows shell?

I read through the documentation at Building COBOL Applications and Running Applications (Native COBOL), but the information there couldn't shed any light on my problem. The only issue I found in the forums so far didn't yield a result, too.

When you debug/run from Visual Studio the COBOL environment has already been set up. So to run the application outside VS of you need to do one of the following :

a. Run from somewhere in which the environment is set up eg a Visual COBOL or Enterprise Developer command prompt.

b. Run using an executable that sets it up automatically using the registry. To do that, in the COBOL Link settings you need to select the 'Dynamic' option.

c. Add the location of the COBOL run-time to the PATH.

Gael


When you debug/run from Visual Studio the COBOL environment has already been set up. So to run the application outside VS of you need to do one of the following :

a. Run from somewhere in which the environment is set up eg a Visual COBOL or Enterprise Developer command prompt.

b. Run using an executable that sets it up automatically using the registry. To do that, in the COBOL Link settings you need to select the 'Dynamic' option.

c. Add the location of the COBOL run-time to the PATH.

Gael

Thanks a lot, Gael, for the information. I'll try that tomorrow.

Actually, I was about to create two new ASP.NET Core web sites in the near future (right after I'm done with my COBOL course) and I was wondering whether I could code one or two .NET class files for these sites using COBOL instead of C# (just to get/keep in touch with the COBOL language). Would I need the COBOL runtime in this case, too? I wonder because I want to publish my websites to Microsoft Azure. I don't think I can upload/install a runtime up there. I was expecting the COBOL compiler basically to transpile to .NET IL.


Thanks a lot, Gael, for the information. I'll try that tomorrow.

Actually, I was about to create two new ASP.NET Core web sites in the near future (right after I'm done with my COBOL course) and I was wondering whether I could code one or two .NET class files for these sites using COBOL instead of C# (just to get/keep in touch with the COBOL language). Would I need the COBOL runtime in this case, too? I wonder because I want to publish my websites to Microsoft Azure. I don't think I can upload/install a runtime up there. I was expecting the COBOL compiler basically to transpile to .NET IL.

You can run COBOL programs, both native and managed, under Azure; but you need the COBOL runtime and a license to do so.

The COBOL compiler, when targeting .NET, does produce MSIL. The COBOL runtime is required because COBOL supports a wide range of data types and operations which have no direct .NET equivalent. Something has to implement those in the CLR world, and that something is the COBOL runtime.


You can run COBOL programs, both native and managed, under Azure; but you need the COBOL runtime and a license to do so.

The COBOL compiler, when targeting .NET, does produce MSIL. The COBOL runtime is required because COBOL supports a wide range of data types and operations which have no direct .NET equivalent. Something has to implement those in the CLR world, and that something is the COBOL runtime.

BlackKnight,

Just to add to what Michael has said, in the original question you had created a native code COBOL application which is dependant on the native COBOL run-time cblrtsm,.dll (plus other dlls) so the application  has to be able to find those dlls in order to be able to run.

If you create a managed code COBOL application such as an ASP.NET application the code is compiled to .NET IL, but it uses the managed COBOL run-time MicroFocus.COBOL.Runtime, also a NET IL assembly, plus other assemblies so again, all of the necessary assemblies need to be available in order for the application to run. If your aim is to deploy to Azure you may find the Azure samples in the product helpful.

Also, if you look at the product documentation there is  a section on Deployment for both native and managed applications that will go into much greater detail than myself and Michael have done here.

Gael


BlackKnight,

Just to add to what Michael has said, in the original question you had created a native code COBOL application which is dependant on the native COBOL run-time cblrtsm,.dll (plus other dlls) so the application  has to be able to find those dlls in order to be able to run.

If you create a managed code COBOL application such as an ASP.NET application the code is compiled to .NET IL, but it uses the managed COBOL run-time MicroFocus.COBOL.Runtime, also a NET IL assembly, plus other assemblies so again, all of the necessary assemblies need to be available in order for the application to run. If your aim is to deploy to Azure you may find the Azure samples in the product helpful.

Also, if you look at the product documentation there is  a section on Deployment for both native and managed applications that will go into much greater detail than myself and Michael have done here.

Gael

Ah, I see. So, if the run-time is being deployed as an assembly then everything is fine.

However, even after doing some intensive search I still couldn't find information in the docs about where to find the run-time in order to add it to the path. I would have expected the information somewhere near Running Applications (Native COBOL), Run-time System Configuration, Deploying the Micro Focus Run-Time System, or by searching the docs for "Run-time path".

Could you please point me to the necessary information in the docs?

And may I advise to revise the docs accordingly?


Ah, I see. So, if the run-time is being deployed as an assembly then everything is fine.

However, even after doing some intensive search I still couldn't find information in the docs about where to find the run-time in order to add it to the path. I would have expected the information somewhere near Running Applications (Native COBOL), Run-time System Configuration, Deploying the Micro Focus Run-Time System, or by searching the docs for "Run-time path".

Could you please point me to the necessary information in the docs?

And may I advise to revise the docs accordingly?

BlackKnight,

The native COBOL run-time can be found in the 'bin' folder (or 'bin64' for a 64-bit app) of wherever you installed the product to. However, adding it to the PATH would only be done as a last resort, hence it being the third of the options I suggested. As the documentation you referred to indicates, normally you would  provide the COBOL Server with your application which will set the system up to run the native code application.

The COBOL run-time for the ,NET Framework will be found in Reference Assemblies folder on your machine when building the application and will be loaded from the GAC when running, so on a machine with the development environment or COBOL Server product installed that would be set up for you. You should not need to manually add references to run your application in such a scenario. The exception to that is the Azure samples that I mentioned which do have explicit references to the COBOL run-time assemblies within the projects because an Azure VM will not have COBOL Server installed.

With a .NET Core application the run-time is in a NuGet package.

If you think that the documentation needs updating then of course you can suggest that.

Gael


Ah, I see. So, if the run-time is being deployed as an assembly then everything is fine.

However, even after doing some intensive search I still couldn't find information in the docs about where to find the run-time in order to add it to the path. I would have expected the information somewhere near Running Applications (Native COBOL), Run-time System Configuration, Deploying the Micro Focus Run-Time System, or by searching the docs for "Run-time path".

Could you please point me to the necessary information in the docs?

And may I advise to revise the docs accordingly?

There is an entire "Deployment" book in the product documentation specifically about deploying COBOL applications. The first section of it, comprising numerous topics, is "Deploying Applications". Under that is a section "Deploying the Micro Focus Run-Time System".

https://www.microfocus.com/documentation/enterprise-developer/ed50/ED-VS2017/GUID-6A559EB3-C911-45CB-958E-F05A6DBBF1FE.html

Of course anyone is free to propose changes to the documentation, but may I suggest those be specific, not vague generalizations; and that they show an understanding of the existing documentation?