Problem:

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

Solution:

he 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.

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 (cs_23.exe, cs_231.exe, or cs_232.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\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)
8. Copy C:\Windows\SysWOW64\msvcr110.dll from the development machine to C:\Program Files (x86)\Micro Focus\COBOL Server\bin:
9. If the COBOL application is built as 64-bit, copy C:\Windows\System32\msvcr110.dll from the development machine to C:\Program Files (x86)\Micro Focus\COBOL Server\bin64:
10. Create a network share (e.g. COBOLsrv) off C:\Program Files (x86)\Micro Focus\COBOL Server 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

Problem:

Using Visual COBOL, a program that opens an indexed file for OUTPUT creates just one file on disk, as opposed to the behavior in earlier versions of MF COBOL, where two disk files were created: a data file and an .idx file.

Resolution:

In Visual COBOL, the default IDXFORMAT is now IDX8, which creates just one disk file holding both the data and the index.  To override this default behavior and configure Visual COBOL to create IDX4 files instead, a person can specify idxformat=4 in the File Handler Configuration file, or use the IDXFORMAT"4" compiler directive, or specify $set idxformat"4" in source code.

Problem:

When compiling a program, the following error is reported by the compiler:

Operand time-of-day is not declared

Resolution:

In both the Server Express documentation and the Visual COBOL documentation, the special register TIME-OF-DAY is documented as being applicable to the OSVS dialect. In addition, the documentation generally says:

 TIME-OF-DAY    9(6) DISPLAY

The TIME-OF-DAY special register contains the value of the current time of day (24-hour clock) (as supplied by the COBOL execution environment), in the form: hhmmss where hh =hour, mm=minutes, and ss= seconds.  TIME-OF-DAY is valid only as the sending area of a MOVE statement.

Based on the above, here is a sample program I wrote to test this:

000001 IDENTIFICATION DIVISION.
000002 PROGRAM-ID. TOD-TEST.
000003 ENVIRONMENT DIVISION.
000004 CONFIGURATION SECTION.
000005 DATA DIVISION.
000006 WORKING-STORAGE SECTION.
000007 01 TIME-OF-DAY-WS PIC 9(6).
000008 PROCEDURE DIVISION.
000009     MOVE TIME-OF-DAY TO TIME-OF-DAY-WS.
000010     DISPLAY 'TIME-OF-DAY IS ' TIME-OF-DAY-WS.
000011     STOP RUN.

This compiles successfully under Visual COBOL, and also under Server Express, if and only if one the following compiler directives is specified: OSVS or DOSVS or DIALECT"OSVS" or DIALECT"DOSVS".  Here are example command lines:

$> cob TOD-TEST.cbl                   <-- Fails
     9     MOVE TIME-OF-DAY TO TIME-OF-DAY-WS.
*  12-S********************                                                  **
**    Operand TIME-OF-DAY is not declared
cob32: error(s) in compilation: TOD-TEST.cbl

$> cob -C OSVS          TOD-TEST.cbl  <-- Succeeds
$> cob -C DOSVS         TOD-TEST.cbl  <-- Succeeds
$> cob -C DIALECT=OSVS  TOD-TEST.cbl  <-- Succeeds
$> cob -C DIALECT=DOSVS TOD-TEST.cbl  <-- Succeeds

To make it work with Visual COBOL, specify the OSVS compiler directive, or within a Visual COBOL for Eclipse project, under Properties > Micro Focus > Project Settings > COBOL, in the drop-down named "Language dialect", select "OS/VS COBOL".

Problem:

While trying to run the Micro Focus License Administration utility /var/microfocuslicensing/bin/cesadmintool.sh, the following error appeared: 

         Micro Focus License Administration 
        ================================== 
 
        Java not present on PATH(or wrong version). 
        A 32bit Java 1.5 runtime is required to run the license 
        administration tool. 
        Please add java to your PATH and retry. 

At the time of the error, the Java version was reported as follows:

 # java -version 
openjdk version "1.8.0_71" 
OpenJDK Runtime Environment (build 1.8.0_71-b15) 
OpenJDK 64-Bit Server VM (build 25.71-b15, mixed mode) 

Resolution:

As explained in the Release Notes, the Visual COBOL product and the Micro Focus License Administration utility require Oracle's Java Platform, Enterprise Edition (Java EE) 7 or Java 8.  The Visual COBOL product was not tested or certified with OpenJDK.
 
The solution is to download Oracle's Java EE from Oracle's Web site and install it anywhere on your machine, then set JAVA_HOME to its location, then set PATH to include $JAVA_HOME/bin, for example:

export PATH=$JAVA_HOME/bin:$PATH

Problem:

Under Visual COBOL, the tool named FaultFinder appears to be absent.

Resolution:

The FaultFinder tool, which had been available in the Server Express and Net Express products, has been removed from the Visual COBOL and Server for COBOL products on both Windows and Linux/UNIX.  Here is a documentation link mentioning this:

http://documentation.microfocus.com/help/topic/com.microfocus.eclipse.infocenter.cobolruntime.win/GUID-B77D3A01-EB52-4775-99D8-0EFB9AAE8D37.html

The main alternative diagnostic tool in place of FaultFinder is the Consolidated Tracing Facility:

http://documentation.microfocus.com/help/topic/com.microfocus.eclipse.infocenter.cobolruntime.win/HRCTRHUCTF01.html

For Native COBOL applications, another alternative is Debugging Using a Core Dump. This is similar to FaultFinder, because it allows the state of an application to be saved to disk in a core dump file when the application crashes.  You can then use the dump file 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:

http://documentation.microfocus.com/help/topic/com.microfocus.eclipse.infocenter.visualcobol.vs2015/HHDGCHDEBG09.html

Another alternative for Native COBOL applications is Just-In-Time Debugging, which allows a debugger to be connected to a running application at the moment an error occurs:

http://documentation.microfocus.com/help/topic/com.microfocus.eclipse.infocenter.visualcobol.vs2015/GUID-1DAAD120-1845-47DC-93B6-61276C7E2CD9.html

If the application is running on a production machine separate from the workstation on which a developer is running the Visual Studio for Visual COBOL IDE, the application can be debugged using Remote Debugging, as described here:

http://documentation.microfocus.com/help/topic/com.microfocus.eclipse.infocenter.visualcobol.vs2015/GUID-797E8732-2483-494A-AA4E-B942A1F6A065.html

For applications and services running under Enterprise Server, a person can take these debugging approaches:

http://documentation.microfocus.com/help/topic/com.microfocus.eclipse.infocenter.visualcobol.vs2015/HHDGCHDEBGF1.html

Problem:

Many Visual COBOL projects may use the same EXTERNAL data files, this usually would require setting an environment variable for each file within an Application.config.

How can these file mappings be achieved without the use of an Application.config?

Resolution:

Setting EXTERNAL file variables within a Visual COBOL project

In the example below, an entry needs to be added to an Application.config file (Environment) in order for the physical file assignment for the SELECT clause to be resolved:

If EXTERNAL does not appear in the SELECT statement, the program must be compiled with the directive ASSIGN(EXTERNAL):

To add an application configuration file, right-click your project in the Solution Explorer:

    Click Add> New Item

• Select Application Configuration File
• Specify a filename in the Name field (or leave as is)
• Click OK
  

Edit the Application.config; add the variable name and file name:

Setting EXTERNAL file variables within the environment

The environment variable can be set in the environment before launching Visual COBOL. An entry in the Application.config would not be necessary.

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.

The most straight-forward way to set the variables externally is to start a Visual COBOL command prompt, then set the file mapping and start Visual COBOL:

Creating a script to set COBCPY and launch Visual Studio

REM *
REM * Set File mappings 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 file mappings
REM *
SET MASTDAT1=C:\ExternalFilesDemo\DATA\MASTER.DAT
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

Problem:

How do I use COBOL Source Information (CSI) with Visual COBOL?

Resolution:

Overview

COBOL Source Information (CSI) is a well-established code analysis view of COBOL programs, and is available within Visual COBOL.

CSI displays information about programs based on queries and displays the results in the Micro Focus Code Analysis window.

CSI queries provide a wide range of information about a program, for example:

• Where data items are defined, used, and modified.
• Where paragraphs and sections are executed.
• Which procedures a paragraph or section executes.
• Where subprograms are called.
• The copybook structure of a program.

Running CSI Queries 

There are a number of ways to run a CSI Query:

• Click the Quick Browse button  on the COBOL toolbar.
  

  This invokes the CSI query control. A CSI query can be entered followed by Enter. In the example below the Special Query COPY has been entered:
  
  The query results are displayed in the Micro Focus Code Analysis window:
  

  There are a number of Special Queries that return a range of information about a program. Please refer to the product documentation for further details.

  In addition some of these Special Queries are available from the Micro Focus Code Analysis context menu.

  COBOL verbs and groups of verbs can also be typed into the CSI query control, for example to find all file operations: OPEN, CLOSE, READ, WRITE, DELETE, START, and REWRITE

  the key word I-O can be used:

• Alt+Q
  Placing the cursor on a data item and using the shortcut Alt+Q, will return information about where the item is defined, referenced, modified etc.:
  
  
  Placing the cursor on a section or paragraph name and using the shortcut Alt+Q, will return information about where the section is executed from, what it executes and any data items used:
  
• Context menu
  Right click to invoke the context menu after placing the cursor on a section or paragraph name or data item etc.:
  
  

Micro Focus Code Analysis window

There are a number of different operations that can be performed from Micro Focus Code Analysis Window:

Run a previous query - select a report from the list box to run it again.

Rerun a query - Rerun a query.

Hide copybooks from the report– exclude results for copybooks, toggle to show the details for all files listed in a report (includes copybooks).

Hide the details from the report – show / hide report details. Right-click and select Expand All / Collapse All.

Navigate to the code - Double-click on a line in the window to navigate to that line in the source code in the editor.

Arrange the results - Toggle between arranging the results - Group By Program or Group By Rule.

Toggle highlighting of results in the code – show / hide highlighting in source code.

Copy lines from the report - highlight and copy results to the clipboard.

Problem:

I need to show that I have tested all logical paths through a program.

Resolution:

Note: This facility is supported in native COBOL only.

Code Coverage

Visual COBOL provides support for code coverage of native COBOL applications directly from within the IDE. In order to produce reports, code coverage needs to be enabled within a project's properties, programs need to be compiled and run with code coverage to produce the relevant reports.

Follow these instructions to enable code coverage and produce code coverage reports:

• Enable Code Coverage on the COBOL page in the properties of the project.

• Rebuild the project to apply the changesThe application can now be run in code coverage mode by selecting Debug > Start With Micro Focus Code Coverage.

Running the application with code coverage will produce a Results.tcz file in the folder specified in Tools > Options > Micro Focus > Code Coverage > Results Options. This file provides statistics in the Micro Focus Code Coverage window and includes information about the percentage of the code that has been executed, as well using color to indicate areas of the code in the editor that have been executed or not executed. Code execution is logged for each program and sub-program. In addition HTML reports can be created from within the Micro Focus Code Coverage window. If the window is not visible, to display it click View > Micro Focus Code Coverage.

Double-clicking on a line within Code Coverage window will place the cursor on the relevant code within the Editor window.

The color preferences for the colorization of covered and missed blocks can be changed in Tools > Options > Environment > Fonts and Color:

The history of running the application with code coverage is saved in a History subfolder in the location of the Results.tcz file. The results from previous runs with code coverage can be loaded into the Micro Focus Code Coverage window (see below).

Micro Focus Code Coverage Window Toolbar

Export code coverage information and save it as a .tcz results file.

Import code coverage information from an existing .tcz results file.

Merge results files from different executions with code coverage, this will create a MergedCoverageFile_datetime.tcz.

Toggle the code coverage colorization on or off in the editor.

Delete the Results_datetime.tcz that is currently loaded, this will unload the file from the IDE and deletes it from disk.

Generate the code coverage HTML format reports. This creates the index report file, TCIndex.htm, and any of the reports in HTML format.

The IDE preferences determine whether to produce a single HTML report file or multiple reports (individual .HTM files produced for each program):

Single report file:

Click on of the tcreport.htm link to view the report.

Multiple report files:

Click on the links to view the individual reports.

Example report file:

The report includes a summary of the percentage of statements, Call statements, blocks etc. that have been executed in the program:

For further information, please refer to the product documentation.

Problem:

Installing Visual COBOL 2.3 Update 2 for Visual Studio 2012 fails with Error 0x80048bc7 on Windows 10, and the installation log also reports Error 0x80070002 in the following entries:

e000: Error 0x80070002: Failed to find payload: visualcobolvisualstudio2012_232x86 in working path: C:\Users\********\AppData\Local\Temp\{f11aaffb-b9a5-4799-96a7-a30788065141}\visualcobolvisualstudio2012_232x86 and unverified path: C:\ProgramData\Package Cache\.unverified\visualcobolvisualstudio2012_232x86
e000: Error 0x80070002: Failed to cache payload: visualcobolvisualstudio2012_232x86
e314: Failed to cache payload: visualcobolvisualstudio2012_232x86 from working path: C:\Users\********\AppData\Local\Temp\{f11aaffb-b9a5-4799-96a7-a30788065141}\visualcobolvisualstudio2012_232x86, error: 0x80070002.
e349: Application requested retry of payload: visualcobolvisualstudio2012_232x86, encountered error: 0x80070002. Retrying...
e000: Error 0x80048bc7: Process returned error: 0x80048bc7
e000: Error 0x80048bc7: Failed to execute EXE package.
e000: Error 0x80048bc7: Failed to configure per-machine EXE package.
i319: Applied execute package: vs2012isoshell, result: 0x80048bc7, restart: None
e000: Error 0x80048bc7: Failed to execute EXE package.
e000: Error 0x80048bc7: UX aborted cache verify begin.
[...]
i399: Apply complete, result: 0x80048bc7, restart: None, ba requested restart:  No

Resolution:

The McAfee anti-virus software for some reason causes the Error 0x80070002, so disabling this software temporarily before installing Visual COBOL resolves that error.

As for the Error 0x80048bc7, it means "Restart is required before installation can continue." See https://msdn.microsoft.com/en-us/library/ee225238.aspx

On the machine where this problem occurred, there were some Windows 10 updates in pending and requiring a machine reboot. Restarting the machine does not initiate the update installation in Windows 10. The restart has to be done from Windows Update.

After installing Windows updates, restarting the machine, and disabling the McAfee anti-virus temporarily, it was possible to install Visual COBOL successfully.

Problem:

I want to use the Micro Focus Data Tools from within the Visual Studio IDE. How do I do this?

Resolution:

Add the MF Data Tools to the Tools menu within the IDE.

From within the Visual Studio IDE menu select Tools> External Tools

In the External Tools dialog box, select Add.

Enter a name for the menu option in the Title box - MF Data Tools

In the Command box, enter the path to MFDATATOOLS.EXE, or select Browse to navigate to C:\Program Files (x86)\Micro Focus\Visual COBOL\bin\mfdatatools.exe(installation folder for Visual COBOL).

Select OK.

A command for the tool, using the text you entered as the Title, now appears on the Tools menu. You can start the tool by choosing the new menu command.

The Micro Focus Data File Tools appear:

Problem:

I have an existing application that uses Indexed Sequential files - IDXFORMAT(3), and they are approaching their size limit.

I need to continue to add additional records to the file.

Resolution:

Use REBUILD to convert to IDXFORMAT(8)

In order to convert existing files to other formats, use the Rebuild utility.

Rebuild is a file management utility invoked from the command prompt which enables you to:

    Reorganize an indexed file

•     Rebuild a corrupt indexed file
•     Convert files from one organization to another
•     Validate an indexed file

In the example below Rebuild is used to display information about the file MUSTOCK.DAT using the /n parameter :

Note: the file format is IDX-3 - IDXFORMAT(3).

In order to convert this file to IDXFORMAT(8) (large format) follow these steps:

• Create a sub-directory to receive the new file (this is optional):
  
  md NEW
• use the following Rebuild command line to create the new IDXFORMAT(8) file:
  
  REBUILD MUSTOCK.DAT,new\MUSTOCK.DAT /t:MF8

This will create a new copy of the file as IDXFORMAT(8) in the new sub-directory:

Display information about the new file MUSTOCK.DAT using the /n parameter :

Note: the file format is IDX-8 - IDXFORMAT(8).

Problem:

In general, the ADISCTRL file is usually placed in the same folder as the application, and it gets picked up automatically. What if this file is located in a different folder?

Back in Net Express, this was resolved by adding the location of this file in the COBDIR environment variable, but in Visual COBOL, the COBDIR can only be used to point to the product's installation folder. 

Resolution:

If the ADISCTRL file is in a different location, then setting the dd_ADISCTRL environment variable to point to the ADISCTRL file (not to its location) will allow the COBOL runtime to find it, e.g. SET dd_ADISCTRL=X:\Folder\SubFolder\ADISCTRL

Problem:

I have deployed a Dialog System application to my server, however when I run the application from a client PC the following error appears:

How can I avoid this?

Solution:

The solutions offered here assume that the COBOL Server and application deployment have followed the guidelines in the following article:

Network deployment of Visual COBOL 2.3 native applications

Set the environment variable COBDATA to point to the folder where the screenset is located.

There are two options that can be applied in order to make sure that the screenset is found.

Option 1:

When building the application, add an Application.config file and add the detail for COBDATA as shown:

(Note: the Value \\10.0.0.21\Appdir represents the application deployment folder (shared) on the server)

Option 2:

Set the environment variable COBDATA on the client PC to point to the folder where the screenset is located on the server,

typically this can be set in a batch file that would the launch the application:

rem *
rem * Set COBDATA to find the screenset
rem * Use UNC with server IP address and share name
rem *
SET COBDATA=\\10.0.0.21\Appdir

rem * now set path etc...... and launch the application

or

rem *
rem * Set COBDATA to find the screenset
rem * Use UNC with server name and share name
rem *
SET COBDATA=\\MyServer\Appdir

rem * now set path etc...... and launch the application

Problem:

I have deployed Dialog System application that is launched from a shortcut on the desktop.

The console window briefly appears and disappears before my application starts.

I have a batch file that sets up some environment variables before running the application:

rem *
rem * Set COBDATA to find the screenset
rem * Use UNC with server IP address and share name
rem *
SET COBDATA=\\10.0.0.21\Appdir

rem * Enable Microsoft Visual Styles

SET MFVSSW=/f/c

rem * Now launch the application

START DSCUSTCLASSIC.EXE

exit

shortcut details:

Solution:

Change the Run property of the shortcut to Minimize :

Problem:

Stepping on a CALL to a GNT simply runs through. The debugger is unable to step in the GNT or stop at any of the breakpoints in a GNT program.

This problem occurs only in Windows 10, not in any other Windows versions.

Resolution:

Microsoft released a major update for Windows 10 in August or September 2016, which is called the "Windows 10 Anniversary update." This update somehow broke the possibility of debugging GNT programs in Visual COBOL.

To determine if you have the Windows 10 Anniversary update, click the Start button, then click Settings> System> About.

• If the About window shows Version 1511 (OS Build 10565), it means the Windows 10 Anniversary update is not installed, and debugging GNT should work fine.
• If the About window shows Version 1607 (OS Build 14393), it means the Windows 10 Anniversary update was already installed, and debugging GNT does not work.

Microsoft will release another major update of Windows 10 in spring of 2017, and we were unable to recreate the problem with the preview build starting with 14931.

In the meantime, you might want to consider one of the following alternatives:

• remove Windows 10 Anniversary update
• compile the GNT to DLL
• use another machine running one of the supported environments (e.g. Windows 7, Windows 8.1, Windows Server 2012, etc.)

It is not recommended to install the preview build of Windows 10 as it is still on a test phase.

Problem:

Problem:

Each Server (region) running under Enterprise Server shows, on its Server > Properties > General tab, settings named Shared Memory Pages and Shared Memory Cushion.  These have default values such as 512 and 32, for example.  But the values might need to be adjusted upward to be certain the Server has enough shared memory.  If a region under load exceeds the shared memory settings, you might see the following error in the console.log:  'CASKC0007W Shared memory storage constrained'.  How should a person decide what values to specify?

Solution:

The product documentation contains charts to help estimate the amount of shared memory a server might require, for example as shown on this page:

http://documentation.microfocus.com/help/topic/com.microfocus.eclipse.infocenter.visualcobol.eclipseux/BKCACACONFS011.html

But in practice Micro Focus end-users usually establish values for the Shared Memory Pages and Shared Memory Cushion heuristically, that is by trial and adjustment, instead of by making precise calculations.

While a particular Server (region) is running, look in Server > Properties > Control > ES Monitor & Control, in other words ESMAC.  On the ESMAC screen, press the "Server" button at top-left, and view at the Server Information screen.  You can see:

Shared Memory (number of 4k pages) -- this is the amount originally configured on the Server > Properties > General tab

SM Total (in k) – just 4 times the 4k number above

SM Cushion (in k) -- the active value of the cushion in k.  Notice that when configuring, you specify this number in units of 4k pages, but here it is shown in k.

SM Free (in k) -- this is the number to pay attention to; this is the important number -- the amount not currently in use

The number in parenthesis following the SM Free, is the FAQE chain length.  This is freed shared memory and is related to how the system manages the shared memory area.  When a block of shared memory is freed it is chained into the FAQE chain. Memory requests will get satisfied from this chain of blocks.

The heuristic approach to setting shared memory for a Server is to set some initial values, run the region for a while, and check the "SM Free" and the "SM Cushion" in ESMAC to see how much is actually being used.  Add some additional load to the region, and watch the SM Free and the SM Cushion.  Adjust the values for "Shared Memory Pages" and "Shared Memory Cushion" on the ES Admin > Server > Properties > General page, re-start the region, and test again.  Continue adjusting the values until the SM Free shows a comfortable value even when the region is under heavy load.

You can allocate generous amounts.  Begin by allocating 5120 4k pages.  That's 5120*4*1024 bytes = 20 meg.  By today's standards, 20 meg is a reasonable amount of memory for a process.  If the machine has 16 gig of RAM, 20 meg is 0.12% of RAM, that is, twelve hundredths of one percent.  And this memory is not allocated individually for each ES process such as mfcs, casmgr, SEPs, etc, instead this memory is allocated once and shared between ES processes.  You can use relatively high values without a performance impact.  Try 5120 with 10% cushion 512, then monitor the SM Free and the SM Cushion in ESMAC and decide whether the amount can be adjusted up or down.

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 COBOL Server's "bin" and application folders:
   - 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. Set COBDIR to point to the COBOL Server's share name:
   PATH=\\ServerName\COBOLsrv
3. 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
4. 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.

Problem:

There is an issue in tool-tip during a debug session when a variable contains a low-value. In this case, the shown content is cut after the low-value and you are not able to see the whole content. This also happens in the auto-window and the monitor-window.

In Net Express the content was fully shown.

Resolution:

This behaviour is expected in Visual Studio.

The tool-tip displays the value of the item as a string and strings are terminated by a null byte. If you hover over a buffer in a C/C++ program containing a null byte you see exactly the same behaviour. 

The tool-tip has a magnifying glass and if you click the arrow next to it and select the Text Visualizer the entire content of the item is displayed when debugging native code, with the null byte shown as '.'.

Problem:

Back in Net Express, the location of the Dialog System's .icn side file had to be added to the COBDIR environment variable if it did not reside in the current folder.

How does the Dialog System's .icn side file get resolved then in Visual COBOL if COBDIR is now strictly used for pointing to the installation folder?

Solution:

In Visual COBOL or COBOL Server, the COBDATA environment variable can be used to resolve the Dialog System's .icn side file.