Quantcast
Channel: Visual COBOL Knowledge Base
Viewing all 214 articles
Browse latest View live

Cancel install of VCVS or VCE before finish leaves product not operational

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Robert Milligan on 2/15/2016 8:19:49 AM

Problem:

Installing the product ED or VC 2.3 Update 1 on a clean machine and hitting the Cancel button towards the end (just before the completion of the installer), might leave traces of the product installed on the system.

Similarly, when upgrading to 2.3 Update 1 from 2.3, if the installation of 2.3 Update 1 is cancelled towards the end, it might leave traces of the 2.3 Update 1 product installed on the system.

Solution:

In order to install the product successfully in the event of cancellation, in ‘Programs and Features’ (Windows Control Panel) either

  - perform a Repair to complete installation of the product, or

  - to remove the product, select Uninstall.


COBOL application fails with error code 245

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by MF_Fano on 2/26/2016 3:57:13 PM

Problem:

Although Micro Focus License Manager indicates COBOL Server licenses are installed, the COBOL application fails with the following error:
Execution error : file ''
error code: 245, pc=0, call=1, seg=0
245     There are no valid product licenses

Resolution:

Back in Net Express, the COBOL runtime system files were exactly the same as in Server for COBOL, so it was possible to use either files to be deployed with COBOL applications. This practice is no longer valid in Visual COBOL and COBOL Server.

The COBOL runtime system files in Visual COBOL and COBOL Server require their own specific license. That is, using the COBOL runtime system files from Visual COBOL requires Visual COBOL license, and using the COBOL runtime system files from COBOL Server requires COBOL Server license.

COBOL Server is the deployment product, and only its files should be used for deployment.

The above error is a result of running a COBOL application that uses COBOL runtime system files (e.g. CBLRTSM.DLL, CBLDWINM.DLL, etc.) from Visual COBOL on a deployment environment.

How to call a second windows form from a first Windows form in a .NET Framework Application

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Kim.Hoskin on 4/5/2016 10:35:40 AM

Problem:

How to call a second windows form from a first Windows form in a .NET framework application.

Resolution:

Assuming the Visual COBOL for Visual Studio .NET framework windows form application, has a second form called Form2 - call this Form2 Window by using code as follows:

declare myform2 as type call2ndform.Form2 = new call2ndform.Form2

invoke myForm2::Show() 


This declares a new object called myform2 which then can use the inherited properties and methods.

In this case, the Show() method which opens the Windows Form.

How to setup a dynamic SQL ADO connection.

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Kim.Hoskin on 4/7/2016 9:38:14 AM

Problem:

How to setup a dynamic SQL ADO connection.

Resolution:

The code below demonstrates how to populate a String variable with an ADO Connection String.

Use this string variable in the SQL CONNECT statement and the remainder of your SQL statements.

- Start of sample code:

- Create a variable ws-connection-str:
01 ws-connection-str pic x(5000).

- Then in the procedure division:

**** Create an ADO Connection String to establish the ADO.Net Connection.
string 'Data Source=localhost;'
'Initial Catalog=MFTest;'
'Integrated Security=False;'
'Persist Security Info=False;'
'User ID=Thisismyuserid;' *> Specified User ID
'Password=thisismypassword;' *> Specified Password
'Enlist=True;'
'Pooling=True;'
'Min Pool Size=0;'
'Max Pool Size=100;'
'Asynchronous Processing=False;'
'Connection Reset=True;'
'MultipleActiveResultSets=False;'
'Replication=False;'
'Connect Timeout=15;'
'Encrypt=False;'
'TrustServerCertificate=False;'
'Load Balance Timeout=0;'
'Packet Size=8000;'
'Type System Version=Latest;'
'Application Name=".Net SqlClient Data Provider";'
'User Instance=False;'
'Context Connection=False;'
'Transaction Binding="Implicit Unbind";'
'MultipleActiveResultSets=True;'
'factory=System.Data.SqlClient;' *> Factory used to point to the
*> Provider Class we will use.
*> Additional settings documented in Microsoft Help
delimited by size
into ws-connection-str
end-string


Next is the SQL Connect statement code:

EXEC SQL
CONNECT using :ws-connection-str
END-EXEC
IF SQLCODE = 0
DISPLAY "Connected via a Connection String"
DISPLAY "The Connection string could be in code"
EXEC SQL
DISCONNECT CURRENT
END-EXEC
IF SQLCODE NOT = 0
DISPLAY "DISCONNECT ERROR"
STOP RUN
END-IF
END-IF

How to convert .NET COBOL Application from SQL ODBC to use SQL ADO technology?

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Kim.Hoskin on 4/7/2016 9:39:39 AM

Problem:

Is it possible to convert a .NET COBOL Application from SQL ODBC to use SQL ADO technology?

If planning to migrate or creating a COBOL application using .NET Framework managed code, it is recommended to consider using SQL ADO technology rather than ODBC Technology.
ADO is designed to be used with managed code .NET Framework applications, giving potential easier integration and stability.

Resolution:

In terms of COBOL code changes,if you plan to make use of the additional ADO features change any SQL(DBMAN=ODBC) directives to SQL(DBMAN=ADO)

Additionally, configure the ADO Database Connection (similar concept to configuring an ODBC connection).

Do this via the ADO.NET Connection Editor tool that ships with Visual COBOL/Enterprise Developer (Accessible via the Windows Start Menu group for the Visual COBOL or Enterprise Developer Program Group > Data Tools > Data Connections).

Once the ADO connection is set up and SQL DBMAN directive updated, then recompile the application to start using ADO Technology.

For more information regarding how ADO works, try the ADO Sample Solution that ships with Visual COBOL/Enterprise Developer, usually located in path: Enterprise Developer: %PUBLIC%\Documents\Micro Focus\Enterprise Developer\Samples\sql\ado.net Visual COBOL: %PUBLIC%\Documents\Micro Focus\Visual COBOL\Samples\sql\ado.net

How to install Rumba after Enterprise Developer has been installed?

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Kim.Hoskin on 4/7/2016 9:44:43 AM

Problem:

How to install Rumba after Enterprise Developer has been installed?

The Enterprise Developer Installation Wizard presents the option to install Rumba, by enabling a checkbox to install the version of Rumba that is included in the Enterprise Developer Installation Package.
If this is not selected on the initial Enterprise Developer installation, how can it be installed at a later stage?

Resolution:

The options to consider are:

Uninstall Enterprise Developer, then when installing Enterprise Developer to enable the install Rumba checkbox,

Or

Locate the Rumba installation file from the Micro Focus SupportLine website and install that separately.

Profiling a Visual COBOL managed code application.

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Kim.Hoskin on 4/7/2016 9:48:02 AM

Profiling a Visual COBOL managed code application.


This article aims to provide a "getting started" overview of a possible profiling option for use with a Visual COBOL Managed code Solutions. Note, there are other 3rd party .NET managed code profiler tools available to use, but this article only looks at using the profiler tool that ships with Visual Studio.


Visual COBOL offers a profiling tool for native Cobol but currently there is no equivalent profiling tool available for managed Cobol, for  .NET Framework based managed code applications.

 

The Visual Studio Profiler can also be used to analyse Native code running within a managed Code Solution, but the profiler report is not as clear or easy to understand as many of the section names used in the Cobol Source are converted to internal .NET type names.

Fortunately the Visual Studio Profiler tool can still be used to great effect, as drilling down through the report will show the source code and same functionality as found with an only managed code project.


The Visual Studio Profiler can be used to analyse .NET COBOL applications, for example how long a certain code statements takes to execute.

Each use case would be different, depending on the issue to be determined, but in general the Visual Studio profiling tools offers a good  level of detail in the report it generates.

Please follow the series of screenshots below to see how to get started with the Visual Studio Profiler:
1. Ensure the solution open in Visual COBOL for Visual Studio, is the one to generate a profiler report against.
2. On the Visual Studio menu click on Analysis > Run Code Analysis:

 

3. This opens the Code Analysis View. From here right click on the relevant report Entry and click on Start Profiling:

 

The profiling tool is now executing, gathering data, depending on the size of the application this can take a few minutes.

 

4. When complete, the report should be shown and visible as seen in the screenshot below:

 

5. This view shows a high-level overview of the application. The next actions to take would be to select the components of the application to understand more about (profiling). For example, to understand which part of the application takes a long time to complete look at the Inclusive samples column, The screenshot below shows that the Micro Focus Cobol File handler component took roughly 35 % of the total time the application took to complete:

6. Next, click on that entry in the report to drill down to the Source code that took 35% of execution time, to help understand what the code is doing here.  

Once selected, the report will spilt into several box shaped entries, with each box representing different parts of the application, or methods contained.

Continue to click on the first box in the report diagrams such as the one shown in the screenshot below

7. Keep on clicking the first box/square/Calling Functions box until the source code view is shown, such as shown below:

 

8. This shows useful information, such as the highlighted Source Code statement with percentage values next to each statement. These percentages give more information regarding how long that part of the application took to execute, which can help to understand performance issues, or to highlight how to improve the Cobol application’s process flow.

 

This article is only intended to serve as a basic guide on how to get started with the Visual Studio profiler, to analyse Visual COBOL managed Code Applications. This tool has many more options and features. For further information for this tool, it is recommended to visit Microsoft’s resources to better understand it’s other features.

 

Debugging Using Core Dumps

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Mark B on 4/8/2016 4:19:46 PM

Problem:

How to generate and debug core dump with Visual COBOL.

Resolution: 

Restriction: The following information applies to NATIVE code only.

 

When an application crashes, its state can be saved to disk in a core dump file. Once a core dump is generated, it can be loaded into the development environment where it can be examined. The dump file can be used to help debug problems, as it indicates where in the source code the error occurred, along with the values of variables, expressions, and the contents of memory as they were at the moment the error occurred. This is most useful in a production environment where it is unlikely that a debugger can be dynamically attached: the core dump can be obtained and then analyzed on another system. The source files and .IDY file(s) must be available for the program(s) that fail, as this allows the core dump to show as much information as possible regarding the state of the program at failure time.

Run-time Tunables

Some run-time behavior cannot be configured using the IDE; this must be configured using run-time tunables, which are set in a run-time configuration file. A text-based run-time configuration file should be created specifying the run-time tunables. Alternatively an application configuration file, Application.config can be used (see below). Additionally a core dump file can be created using CBLCORED (see below).

The COBCONFIG_environment variable should be set to locate the configuration file, for example:

    SET COBCONFIG_=C:\Config\COBCONFIG.CFG

Configuration file contents

SET CORE_ON_ERROR=131
SET CORE_FILENAME=”C:\\COREDUMP\\CORE\\core.%f.@%t.%d”

CORE_ON_ERROR - Specifies the circumstances in which a core file is produced:

0 - The run-time system never produces a core file on any exception or run-time system error. This is the default behavior of the run-time system.

1 - The run-time system produces a core file when any exception is received that would normally produce a core file on the host system; for example, a run-time system error COBRT153, and so on.

2 - The run-time system produces a core file when any run-time system error occurs. After writing out the core file the process terminates immediately.

3 - The run-time system produces a snap shot core file when any run-time system error occurs. After writing out the core file the process continues as normal; for example, to display an RTS error message.

129 - Same as core_on_error=1, except no message box is displayed after the core file is created.

130 - Same as core_on_error=2, except no message box is displayed after the core file is created.

131 - Same as core_on_error=3, except no message box is displayed after the core file is created.

 

CORE_FILENAME - Specifies the name of the file that will be produced when a core file is generated:

Using the example above a file will be produced and placed in the directory C:\COREDUMP\CORE\ when a program 153core is run and produces a runtime error. The %f adds the base name of the program that encountered the error; %d adds the date and the %t adds the time to the filename.
By default the core file will be created in the same location as the executable files, however the file can be redirected to a specific location. On Windows platforms, in order to use the backslash in a path, it must be preceded with the escape character, which is also a backslash. The result would be:

C:\coredemo\core\core.153core.122536.20160401


Configuring Debug Settings

Load the Visual Studio solution / Project that created the application.

The Debug settings for the Visual Studio project need to be changed to Start external program and point to the core dump file:


Start debugging; the state of the program when it crashed is displayed. The program can now examined at the point at which the crash occurred:

 

Using an Application.config

This can be used as an alternative method to the one described above.

When building executables within the Visual Studio IDE, an Application.config file can be created in order to set various run-time tunables.

The build process will create an <executable-base-name>.exe.mfgcf file in the output folder, for example 153core.exe.mfgcf

To set run-time configuration options, select the Run-time Configuration tab > Error Handling.

  • Set the Core dump file name to required properties of the core_filename.

  • Set the Generate a core dump when a run-time error occurs = 131 (or any of the other core_on_error values as required).

Running the program from within the Visual Studio IDE (CTRL+F5):

Or running the program from a Visual COBOL command prompt:

The core dump will be created in the same location as the program executable, unless a specific path is specified,

For example C:\coredemo2\coredemo2\bin\x86\Debug\core.153core.20160407.120711

Configuring Debug Settings

Load the Visual Studio solution / Project that created the application.

The Debug settings for the Visual Studio project need to be changed to Start external program and point to the core dump file:

Start debugging; the state of the program when it crashed is displayed. The program can now examined at the point at which the crash occurred:


 

Using CBLCORED

 

CBLCORED is a command line utility that can be enabled before running a COBOL application.

In a COBOL Server production environment a core dump can be created and then analyzed on another system that has the development environment together with the source and .idy files available.

When CBLCORED is run a dialog is displayed in order to determine how the utility will behave.

  • Disabled - core dump not required.

  • Enabled with prompt– a message box is displayed when a core dump is about to be created, for example:

  • Enabled with no prompt– no message box displayed when a core dump is about to be created.

When the program fails, a core dump file CBLCORE will be created in the same folder as the application:

Configuring Debug Settings

Load the Visual Studio solution / Project that created the application.

The Debug settings for the Visual Studio project need to be changed to Start external program and point to the core dump file:

Start debugging; the state of the program when it crashed is displayed. The program can now examined at the point at which the crash occurred:

6648.coredemo.zip

3034.coredemo2.zip

 


Unable to Install the MFLicenseServer on SUSE 12 SP1

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by ppimental on 4/13/2016 1:01:37 PM

Problem:

During the Visual COBOL or Enterprise Developer installation on SUSE 12 SP1 installation, the Visual COBOL product will be installed, but the MFLicenseServerInstall.sh call made during the installation will fail to extract the binaries necessary to install the licensing system. During debug, a pax: Bad Option: -O. error message will be noted.

 

Resolution:

At line 1989 in MFLicenseServerInstall.sh
Change the following line and remove ! from the if statment. 

if [ "$platform.x" != "Linux_ppc.x" ] 

to 

if [ "$platform.x" ="Linux_ppc.x" ] 

Then the installer should work and extract the binaries and complete successfully.

This issue will be resolved in Visual COBOL and Enterprise Developer 2.3 Update 1 Hotfix1.

How to configure CTF to capture events for RunUnits in COBOL

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Kim.Hoskin on 4/18/2016 1:24:26 PM

Problem:

How to configure CTF to capture events for RunUnits in COBOL.

This article assumes an understanding of CTF (Consolidated Tracing Facility), but requires additional tracing enabled for code executing within Run Units.
CTF (Consolidated Tracing Facility) can capture events for Run Units but it is not clearly stated which emitters are needed to enable this.

Resolution:

The CTF Configuration file should have the the following emitters:

mftrace.emitter.textfile#Format = $(RUNUNIT) $(TIME) $(THREAD) $(COMPONENT) $(EVENT) $(LEVEL) $(DATA)
mftrace.emitter.textfile#RununitID=True
mftrace.emitter.textfile#MultiProc=True

No revoke option seen in Visual COBOL Version 2.0 and above.

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Kim.Hoskin on 4/18/2016 1:24:35 PM

Problem:

In Visual COBOL 2.0 and earlier product versions, there was an option in the license system to revoke a license, but with newer product versions there is only a remove option - Why?

Resolution:

Visual COBOL version 2.0 onwards uses Pre-Authorised license technology and will be received in form of a license file.

These are pre-authorised meaning revoking a license is not necessary.

When Licencing Visual COBOL version 2.0 and later versions, use the aforementioned license file when, for example reinstalling the product.

How to set the default userID for remote reconnections in the Eclipse IDE

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Kim.Hoskin on 5/3/2016 1:45:58 PM

Problem:

How to change the default userID for remote reconnections in the Eclipse IDE.

When creating a new remote connection the userID field in the Eclipse IDE will be populated with the currently logged on Windows user ID.  This can lead to problems when connecting to a remote Linux/UNIX machine as the userID’s on those Operating Systems are case sensitive whereas this is not the case in a Windows environment.

Resolution:

The Eclipse IDE allows for the setting of the default userID values per remote connection type.

To make these changes:

Start the Eclipse IDE and from the pull-down menu, select Window\Preferences\Remote Systems to display the list of remote connections defined on the machine.

The userID fields can be edited by clicking on them.  Click on the “Default User ID” field for the relevant remote connection and ensure the value exactly matches (case sensitive) the Linux userID.  Click OK to save the new settings which will now be used when creating a new remote connection in the Eclipse IDE.

This same approach should be adopted for each connection type planned to be used, e.g. Micro Focus DevHub using RSE, Micro Focus DevHub using Samba, etc. 

Setting COBCPY outside of Visual COBOL project

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Mark B on 6/2/2016 6:00:31 PM

Problem:

Many Visual COBOL projects may use the same copybooks, this usually would require setting the Copybook Paths within the properties of a project.

How can the Copybook Paths be set for a Visual COBOL project externally in the environment?

Resolution:

Setting up COBOL Copybook Paths within a Project

The location of copybooks can be specified in the project properties of a project, on the Copybooks tab, or adding them to the project as linked files or folders.

This would need to be set for each project within a solution.

  • Select the Copybook Paths tab and select the New Line icon.
  • Enter the value or browse to locationand select the Check Entries icon.

 

Setting up COBOL Copybook Paths within the environment

The COBCPY environment variable can be set in the environment before launching Visual COBOL.

When Visual COBOL is started, it will inherit the settings from the environment, a batch file or script can be used to set up various environment variables and file mappings etc. before launching Visual COBOL.

In the example below Visual COBOL has been started and the COBCPYSAMP project has been loaded. The copybook search path has not been defined.

When the COBOL source program is loaded into the text editor the copybooks cannot be found.

The most straight-forward way to set the COBCPY variable externally is to start a Visual COBOL command prompt, then set COBCPY and start Visual Studio:

When Visual COBOL is started, it will inherit the settings from the environment.

In the example below Visual COBOL has been started and the COBCPYSAMP project has been loaded. The copybook search path has not been defined.

When the COBOL source program is loaded into the text editor the copybooks are found.

Creating a script to set COBCPY and launch Visual Studio

 

REM *
REM * Set COBCPY externally then start Visual Studio
REM *
REM *
REM * Call createenv.bat to set the COBOL environment
REM *
CALL "C:\Program Files (x86)\Micro Focus\Visual COBOL\createenv.bat"
REM *
REM * Add the project / solution copyfile location
REM *
SET COBCPY=C:\COBCPYSAMP\CPY;%COBCPY%
REM *
REM * Start Visual Studio ( use MFDEVENVnn - where nn represents version of Visual Studio)
REM * Alternatively start Visual Studio using DEVENV ("C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\DEVENV:)
REM * The example above uses Visual Studio 2015.
REM *
mfdevenv14.0
REM *
REM * Close the command prompt
REM *
EXIT

Unable to determine the status of the product license: MFCES_ERROR_SECURITY_UNCONFIRMED

$
0
0
Revision 1 posted to Visual COBOL Knowledge Base by Kim.Hoskin on 6/15/2016 10:08:18 AM

Problem:

When opening a project, intermittently, the following error message might appear:
Unable to determine the status of the product license: Unable to retrieve error details for error MFCES_ERROR_SECURITY_UNCONFIRMED 

See sample screenshot below for further details:
 

Resolution:

This error can occur if the Micro Focus CES Daemon is not started using the Local Windows  System account. Check that the Local System account is used to start this service.

return code of proxy is 2000 instead of 0

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Peter.Kalfsbeek on 10/5/2016 10:02:10 AM

Problem

Compiling the proxy with SIGN(EBCDIC) directive, causes a return code returned by the proxy of 2000 instead of 0. The problem is linked with xs:integer definition in the WSDL file that generate S9(18) COBOL data definition.
If the SIGN(EBCDIC) is set, the content of the input S9(18) COBOL variables generate this SOAP Issue.

Resolution

Currently the generated client proxy must be SIGN(ASCII). SIGN(EBCDIC) is not supported for imtkmake webservices.


imtkmake -genwsdl creates code for first endpoint but not for second endpoint

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by Peter.Kalfsbeek on 10/5/2016 12:17:30 PM

Problem

imtkmake -genwsdl generates code for the first endpoint, how can you make use of the second endpoint?

In a WSDL file used to generate the COBOL Proxy,  the service has different endpoints (See below).
<wsdl:service name="DosCom_1_SOAP.serviceagent">
       
     <wsdl:port name="ControlerAdrPstlAssiste_1_s12-edpt" binding="tns:ControlerAdrPstlAssiste_1_s12-edptBinding">
                         <soap1:address location="http://localhost:12345/esb/service/DosCom_1/ControlerAdrPstlAssiste_1_s12"/>
       
    </wsdl:port>
       
      <wsdl:port name="ControlerAdrPstlRNVP_1-edpt" binding="tns:ControlerAdrPstlRNVP_1-edptBinding">
           
            <soap:address location="http://localhost:12345/esb/service/DosCom_1/ControlerAdrPstlRNVP_1"/>
       
      </wsdl:port>
       
      <wsdl:port name="ControlerAdrPstlAssiste_1-edpt" binding="tns:ControlerAdrPstlAssiste_1-edptBinding">
           
             <soap:address location="http://localhost:12345/esb/service/DosCom_1/ControlerAdrPstlAssiste_1"/>
       
       </wsdl:port>
       
       <wsdl:port name="ControlerAdrPstlRNVP_1_s12-edpt" binding="tns:ControlerAdrPstlRNVP_1_s12-edptBinding">
                          <soap1:address location="http://localhost:12345/esb/service/DosCom_1/ControlerAdrPstlRNVP_1_s12"/>
       
         </wsdl:port>
   
        </wsdl:service>

Resolution

You will have to modify the WSDL manually in order to keep only the second endpoint to have the proxy code to access  http://localhost:12345/esb/service/DosCom_1/ControlerAdrPstlRNVP_1

      <wsdl:port name="ControlerAdrPstlRNVP_1-edpt" binding="tns:ControlerAdrPstlRNVP_1-edptBinding">
           
            <soap:address location="http://localhost:12345/esb/service/DosCom_1/ControlerAdrPstlRNVP_1"/>
       
      </wsdl:port>.

Error 5487 Failed to write the updated manifest to the resource of file

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by MF_Fano on 10/5/2016 1:32:23 PM

Problem:

Although there were no compile and link errors, the build failed and displayed the following error message in the Output window:

Error 5487 Failed to write the updated manifest to the resource of file "obj\x86\Release\Program1.exe"

Resolution:

This issue is caused by some antivirus software that prevents the .exe or .dll files to be created on the machine, so the solution has to be addressed with the vendor.

In the meantime, the workaround is to disable the antivirus software during program build or to configure your antivirus software to exclude your project folder and its subfolders from its scan.

Multi-dimensional Tables: Subscript out of Range

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by NickCook on 10/11/2016 2:47:46 PM

Problem:

When attempting to access a multi-dimensional table outside of its subscript range, a “subscript out of range” error is not always generated at runtime.

Given an array M_TABLE:

01    M_TABLE OCCURS 8.

02   D-TABLE OCCURS 8.

       03   TABLE_DATA   PIC X(5).

And the Procedure Division statement:

MOVE “DATA”   TO TABLE_DATA (x, y).

 

If the values of x and y were 1 and 9 respectively, a ‘subscript out of range’ error is not generated at runtime even though the value in y is greater than the second dimension of the table.

 

The compiler directives that affect subscripting are SSRANGE and BOUND.

http://documentation.microfocus.com/help/topic/com.microfocus.eclipse.infocenter.visualcobol.vs2013/HRCDRHCDIR6Q.html?resultof=%22%73%73%72%61%6e%67%65%22%20

http://documentation.microfocus.com/help/topic/com.microfocus.eclipse.infocenter.enterprisedeveloper.vs2012/HRCDRHCDIR1H.html?resultof=%22%62%6f%75%6e%64%22%20

 

The comments in the BOUND section state:

For multi-dimensional tables, only the composite subscript is checked. If any of the individual subscripts or indices is beyond its limit, but the reference remains within the table, no error is produced.

 

In the example above, as the combined subscript (ie 1,9) is still within the physical bounds of the array, no error is produced at runtime, and the data will still be stored within the tables boundaries. This action means that any data already stored in the table could be overwritten and lost. Unpredictable results may be obtained when this area of the table is accessed further in the program.

Resolution

As the Micro Focus compiler and run time processor can allow an individual subscript of a multi-dimensional table to be outside the range of its own occurrence, it is recommended that checking of subscripts is always coded to ensure this situation does not occur.

For example, in the above table:

 

IF (x < 1 OR > 8)

OR (y < 1 OR > 8)

THEN

               PERFORM SUBSCRIPT_RANGE_ERROR

               GO TO EXIT_PARA

END_IF.

Network deployment of Visual COBOL 2.2 native applications

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by MF_Fano on 10/24/2016 1:22:19 PM

Problem:

How to deploy native applications built with Visual COBOL 2.2 on the network?

Solution:

The following instructions are based on a 64-bit Windows environment where:

  • the 32-bit software is installed in C:\Program Files (x86)
  • Windows keeps the 32-bit system files in C:\Windows\SysWOW64
  • Windows keeps the 64-bit system files in C:\Windows\System32.

On a 32-bit Windows environment, the software is installed in C:\Program Files, and Windows keeps the system files in C:\Windows\System32.

There are two series of preparations to be done on both server and client sides to allow the COBOL applications to be launched from client machines.

Server setup:

1. Install COBOL Server for the intended Visual Studio version (cs201x_22.exe)
2. Go to Start > All Programs > Micro Focus License Manager > License Administration
3. Install the license
4. Click Options > Advanced Configuration
5. Change the value for License Server with the current server's name or IP address
6. Click Save and close License Administration
7. Copy the following files to C:\Program Files (x86)\Micro Focus\COBOL Server 201x\bin:
   - C:\Program Files (x86)\Common Files\Safenet Sentinel\Sentinel RMS License Manager\WinNT\mfcesd.exe
   - C:\Program Files (x86)\Common Files\Safenet Sentinel\Sentinel RMS License Manager\WinNT\mfcesdchk.exe
   - C:\ProgramData\Micro Focus\ces.ini (note: C:\ProgramData is hidden by default, so the "Show hidden files, folders, and drives" option under Control Panel > Folder Options has to be enabled to make it visible)
   - C:\Windows\SysWOW64\msvcr100.dll
8. Copy one of the following files (if applicable) from the development machine to C:\Program Files (x86)\Micro Focus\COBOL Server 201x\bin:
   - C:\Windows\SysWOW64\msvcr110.dll if the COBOL application was built as 32-bit with VS 2012
   - C:\Windows\SysWOW64\msvcr120.dll if the COBOL application was built as 32-bit with VS 2013
9. Copy one of the following files (if applicable) from the development machine to C:\Program Files (x86)\Micro Focus\COBOL Server 201x\bin64:
   - C:\Windows\System32\msvcr100.dll if the COBOL application was built as 64-bit with VS 2010
   - C:\Windows\System32\msvcr110.dll if the COBOL application was built as 64-bit with VS 2012
   - C:\Windows\System32\msvcr120.dll if the COBOL application was built as 64-bit with VS 2013
10. Create a network share (e.g. COBOLsrv) off C:\Program Files (x86)\Micro Focus\COBOL Server 201x and give read-only access to users

Client setup:

Here is the content of the batch file to launch 32-bit applications:
set COBDIR=\\ServerName_Or_IPaddress\COBOLSRV
set MFCES_INIT_LOCATION=%COBDIR%\Bin\ces.ini
rem comment out the following PATH for running 64-bit applications
set PATH=%COBDIR%\bin;%PATH%
rem uncomment the following PATH for running 64-bit applications
rem set PATH=%COBDIR%\bin64;%COBDIR%\bin;%PATH%

rem Checks if MF CES Daemon is running
mfcesdchk.exe >nul
if errorlevel 1 goto startlic
goto startapp

:startlic
rem  Starts MF CES Daemon
start /B mfcesd.exe -b

:checkloop
rem Checks if MF CES Daemon is running
mfcesdchk.exe >nul
if errorlevel 1 goto checkloop

:startapp
rem Run your application

Network deployment of Visual COBOL 2.2.1 & 2.2.2 native applications

$
0
0
Current Revision posted to Visual COBOL Knowledge Base by MF_Fano on 10/24/2016 1:22:53 PM

Problem:

How to deploy native applications built with Visual COBOL 2.2 Update 1 and Update 2 on the network?

Solution:

The following instructions are based on a 64-bit Windows environment where:

  • the 32-bit software is installed in C:\Program Files (x86)
  • Windows keeps the 32-bit system files in C:\Windows\SysWOW64
  • Windows keeps the 64-bit system files in C:\Windows\System32.

On a 32-bit Windows environment, the software is installed in C:\Program Files, and Windows keeps the system files in C:\Windows\System32.

There is a new method of running an application over the network since Visual COBOL 2.2 Update 1. It consists of using the "runtime launch configuration file", which does not require to run mfcesd.exe explicitly from a .bat file from the client machines.

Development requirements:

Compile the native COBOL programs with the dynamic link setting.
   - click Properties under project
   - click the Link property
   - select Dynamic checkbox
   - rebuild solution

There are two series of preparations to be done on both server and client sides to allow the COBOL applications to be launched from client machines.

Server setup:

1. Install COBOL Server for the intended Visual Studio version (cs201x_221.exe or cs201x_222.exe)
2. Go to Start > All Programs > Micro Focus License Manager > License Administration
3. Install the license
4. Click Options > Advanced Configuration
5. Change the value for License Server with the current server's name or IP address
6. Click Save and close License Administration
7. Copy the following files to C:\Program Files (x86)\Micro Focus\COBOL Server 201x\bin:
   - C:\Program Files (x86)\Common Files\Safenet Sentinel\Sentinel RMS License Manager\WinNT\mfcesd.exe
   - C:\Program Files (x86)\Common Files\Safenet Sentinel\Sentinel RMS License Manager\WinNT\mfcesdchk.exe
   - C:\ProgramData\Micro Focus\ces.ini (note: C:\ProgramData is hidden by default, so the "Show hidden files, folders, and drives" option under Control Panel > Folder Options has to be enabled to make it visible)
   - C:\Windows\SysWOW64\msvcr100.dll
8. Copy one of the following files (if applicable) from the development machine to C:\Program Files (x86)\Micro Focus\COBOL Server 201x\bin:
   - C:\Windows\SysWOW64\msvcr110.dll if the COBOL application was built as 32-bit with VS 2012
   - C:\Windows\SysWOW64\msvcr120.dll if the COBOL application was built as 32-bit with VS 2013
9. Copy one of the following files (if applicable) from the development machine to C:\Program Files (x86)\Micro Focus\COBOL Server 201x\bin64:
   - C:\Windows\System32\msvcr100.dll if the COBOL application was built as 64-bit with VS 2010
   - C:\Windows\System32\msvcr110.dll if the COBOL application was built as 64-bit with VS 2012
   - C:\Windows\System32\msvcr120.dll if the COBOL application was built as 64-bit with VS 2013
10. Create a network share (e.g. COBOLsrv) off C:\Program Files (x86)\Micro Focus\COBOL Server 201x and give read-only access to users
11. if the COBOL application is deployed on the server:
   - Create a run-time launch file with a text editor as progname.exe.mfcfg (where progname is the same name as the .exe) with the following two lines:
   SET SERVERPATH=\\ServerName\COBOLsrv
   SET CESDYNAMIC=ces.ini
   where ServerName should be replaced by the actual server's name or IP address.
   - Place the run-time launch file in the same folder as the .exe file

Client setup:

1. Set the PATH on the client machine to include the COBOLsrv share and application folder:
   - if the COBOL application is built as 32-bit:
   PATH=\\ServerName\COBOLsrv\bin;<AppFolder>;%PATH%
   where ServerName is the actual server's name or IP address
   where <AppFolder> is the actual application folder
   - if the COBOL application is built as 64-bit:
   PATH=\\ServerName\COBOLsrv\bin64;\\ServerName\COBOLsrv\bin;<AppFolder>;%PATH%
   where ServerName is the actual server's name or IP address
   where <AppFolder> is the actual application folder
2. if the COBOL application is deployed on the client machine:
   - Create a run-time launch file with a text editor as progname.exe.mfcfg (where progname is the same name as the .exe) with the following two lines:
   SET SERVERPATH=\\ServerName\COBOLsrv
   SET CESDYNAMIC=ces.ini
   where ServerName should be replaced by the actual server's name or IP address.
   - Place the run-time launch file in the same folder as the .exe file
3. Run the application

Note:

The instructions for "Network deployment of Visual COBOL 2.2 native applications" are still valid to deploy Visual 2.2.1 and 2.2.2 native applications.

Viewing all 214 articles
Browse latest View live


Latest Images

<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>