All knowledge base posts in Visual COBOL

COBOL – Here’s to the Next 60 Years

COEST — Tue, 20 Aug 2019 10:44:11 GMT

Using a BackgroundWorker Thread to Run a Task in a Windows Form

Chris Glazier — Thu, 15 Aug 2019 17:43:51 GMT

Problem:

From within a Windows Forms application, when a button is clicked the program would disable the button and then perform the task associated with the button from within the button Click event handler. If this is a long-running task then the UI thread can become unresponsive and start queuing events, even for those such as a mouse click on the disabled button. When the button is enabled again the queued events would be run and the event handler code would be invoked again in error.

Solution:

This demo shows one possible method of avoiding this scenario by executing a long-running task by creating a BackgroundWorker thread and running the task separately from the main UI thread. In this manner the UI thread is free to keep processing events and the BackgroundWorker thread can report its progress and also be canceled if need be.

The zipped up Visual Studio 2019 solution for BackgroundWorkerDemo is attached to this article.

$set ilusing"System.Threading" $set ilusing"System.ComponentModel" *---------------------------------------------------------------------------* * BackgroundWorkerDemo * * * * The original problem that a customer had was from within a Windows Forms * * application, when a button was clicked they would disable the button and * * then perform the task associated with the button from within the button * * Click event handler. If this was a long-running task then the UI would * * become unresponsive and starting queuing events, even for those such as * * a mouse click on the disabled button. When the button was enabled again * * the queued events would be run and the event handler would be run again. * * * This demo shows one possible method of avoiding this scenario by execut- * * ing a long-running task by creating a BackgroundWorker thread and running* * the task separately from the main UI thread. In this manner the UI thread* * is free to keep processing events and the BackgroundWorker thread can re-* * port its progress and also be canceled if need be. * *---------------------------------------------------------------------------* class-id BackgroundWorkerDemo.Form1 is partial inherits type System.Windows.Forms.Form. working-storage section. method-id NEW. procedure division. invoke self::InitializeComponent *> tell the backgroundWorker task to report its progress by calling the *> associated event handler which can update the UI set backgroundWorker1::WorkerReportsProgress = true *> allow the backgroundWorker task to be canceled set backgroundWorker1::WorkerSupportsCancellation = true *> set initial state of the Start and Canel buttons set btnStart::Enabled to true set btnCancel::Enabled to false goback. end method. method-id BackgroundWorker1_DoWork final private. procedure division using by value sender as object e as type System.ComponentModel.DoWorkEventArgs. declare worker as type BackgroundWorker = sender as type BackgroundWorker perform varying i as binary-long from 1 by 1 until i > 10 if worker::CancellationPending = true set e::Cancel = true goback else *> Perform a time consuming operation and report progress. invoke type Thread::Sleep(1000) invoke worker::ReportProgress(i * 10) end-if end-perform end method. method-id BackgroundWorker1_RunWorkerCompleted final private. procedure division using by value sender as object e as type System.ComponentModel.RunWorkerCompletedEventArgs. if e::Cancelled = true set lblPercent::Text = "Task Canceled!" else if e::Error not = null set lblPercent::Text = "Error: " & e::Error::Message else set lblPercent::Text = "Done!" end-if end-if set btnStart::Enabled to true set btnCancel::Enabled to false end method. method-id BackgroundWorker1_ProgressChanged final private. procedure division using by value sender as object e as type System.ComponentModel.ProgressChangedEventArgs. set lblPercent::Text = e::ProgressPercentage::ToString & "%" end method. method-id btnStart_Click final private. procedure division using by value sender as object e as type System.EventArgs. set btnStart::Enabled to false set btnCancel::Enabled to true if backgroundWorker1::IsBusy not = true *> Start the asynchronous operation. *> This will invoke the method BackgroundWorker1_DoWork invoke backgroundWorker1::RunWorkerAsync end-if end method. method-id btnCancel_Click final private. procedure division using by value sender as object e as type System.EventArgs. if backgroundWorker1::WorkerSupportsCancellation = true *> Cancel the asynchronous operation. invoke backgroundWorker1::CancelAsync set btnCancel::Enabled to false end-if end method. end class.

Join our COBOL FB group

COEST — Sun, 11 Aug 2019 16:07:46 GMT

RT to your followers to invite them to join our COBOL FB group

Visual Cobol Information (in German, Italian, Russian and Spanish)

COEST — Thu, 18 Jul 2019 14:54:44 GMT

read more at microfocus

Visual COBOL | Micro Focus

Visual COBOL bietet Ihnen unabhängig davon, ob Sie sich für Visual Studio oder Eclipse entscheiden, COBOL-Entwicklungs- und Integrationstools, die Ihr Entwicklungsteam beim Bereitstellen neuer Funktionen unterstützen....

Visual COBOL | Micro Focus

Visual COBOL fornisce strumenti di sviluppo e integrazione COBOL con Visual Studio o Eclipse, che aiutano i team di sviluppo delle applicazioni a distribuire nuove funzionalità....

Visual COBOL | Micro Focus

Visual COBOL proporciona herramientas de desarrollo e integración COBOL en la plataforma Visual Studio o Eclipse de su elección que ayudan a los equipos de AppDev a entregar nuevas funciones....

Visual COBOL | Micro Focus

Visual COBOL® предоставляет инструменты разработки и интеграции COBOL (Visual Studio или Eclipse — на ваш выбор), которые помогают командам разработчиков приложений предлагать новые функциональные возможности....

Live Webinar: Visual COBOL 5.0 - DevOps & API-Entwicklung in der Cloud, 17. Juli (in German)

COEST — Thu, 11 Jul 2019 15:16:29 GMT

Tech Tips: Projecting COBOL into the future (pun intended)

COEST — Tue, 09 Jul 2019 16:22:57 GMT

read more at microfocus

Tech Tips: Projecting COBOL into the future (pun intended)

Introduction: Using Projects To make the most of Micro Focus Visual COBOL and Enterprise Developer, developers are recommended to move towards a project based build system. Over the years I have spoken to a number of people who have kept their existing......

Tech Tips: Debugging COBOL code in Visual Studio - Breakpoints and Watchpoints

COEST — Thu, 04 Jul 2019 11:09:02 GMT

read more at microfocus

Tech Tips: Debugging COBOL code in Visual Studio - Breakpoints and Watchpoints

Introduction An important part of the software development and maintenance process involves debugging code to fix problems or develop new functionality. Setting breakpoints and querying and modifying data items are key features of the debugging environ......

Tech Tips: Debugging COBOL code in Visual Studio – Data Items

COEST — Thu, 04 Jul 2019 13:03:54 GMT

read more at microfocus

Tech Tips: Debugging COBOL code in Visual Studio – Data Items

Advanced - Visual COBOL Customer Video

surie — Tue, 02 Jul 2019 14:38:21 GMT

Advanced - Visual COBOL customer video - YouTube

COBOL deployment using Docker enables optimized server infrastructure, rapid time-to-market, and DevOps practices for Advanced.

Case study for Advanced: https://www.microfocus.com/en-us/case-study/advanced

Visual COBOL supports digital banking strategy and delivers 65% faster time-to-market

surie — Mon, 17 Jun 2019 23:53:56 GMT

How can I direct the output from a JVM compilation to a different directory?

NickCook — Fri, 31 May 2019 10:39:03 GMT

Problem

I would like the .class file produced by the JVM compiler (cob -j) to be output to a different directory rather than be placed in the same directory as the source file.

Solution

You can use the command:

cob -j -C iloutput\"/home/project/bin\" program.cbl

Note: The directory /home/project /bin must already exist.

Function keys don't work when trying to animate a program using the PuTTY terminal emulator

NickCook — Fri, 31 May 2019 10:37:09 GMT

Problem.

I use the PuTTY terminal emulator and when I try to use the function keys whilst animating a program they do not work as they should.

In particular the F2 key should toggle between the program code and the program output, but the key press has no effect at all.

Solution.

In PuTTY configuration, select Terminal ->Keyboard and note that the default setting is ESC[~. This needs to be changed to VT100+. The anim function keys will then work as expected.

DevOps and API Development in the Cloud: Visual COBOL 5.0 Product Launch

surie — Wed, 22 May 2019 18:06:27 GMT

About this webinar

Join the Micro Focus COBOL product team for a closer look at the latest release of its distributed COBOL solution—Visual COBOL. Hear what’s new in version 5.0 and how to best leverage API development and DevOps in the Cloud. Have your questions ready for the product team as we explore the next generation of COBOL development in the Cloud.

Live online: Jun 26, 2019

Presented by: Ed Airey and Scot Nielsen, Micro Focus

AMC Tech Tips: Don’t know what’s been executed? Micro Focus has got you covered

surie — Wed, 22 May 2019 17:25:37 GMT

By gnlam

Working out which parts of a program have been executed and run can be a daunting task. Manually trying to work out the control flow is time consuming and error prone. In Micro Focus Visual COBOL and Enterprise Developer we have support for recording code coverage of native COBOL applications, making this task significantly easier. Code coverage is a measure of how much of an application is executed, usually as part of a test suite.

This is great for identifying areas of code that may not be executed during a run of the application. And better still for deciding which areas are in need of further testing. Micro Focus supports this functionality in both Eclipse and Visual Studio (VS) IDEs, but I will be showing VS as it is my IDE of choice.

AMC Tech Tips: 4 Slick ways to accelerate COBOL code editing

surie — Mon, 13 May 2019 15:52:52 GMT

By Ted John

Maintaining COBOL code, especially apps of tens of thousands of lines or more, can sometimes feel like a chore. With Micro Focus’ COBOL development products Visual COBOL and Enterprise Developer however, this a relatively painless and productive experience thanks to rich editing tools that significantly speed up the job of fixing and developing new COBOL programs.

The capabilities I will focus on here can be found in both the Visual Studio and Eclipse variants of the product, and behave in a similar fashion to C# and Java apps. In this blog I will explain and illustrate some of the editing features available using Visual COBOL for Visual Studio.

AMC Tech Tips: Creating COBOL code snippets

surie — Mon, 13 May 2019 15:04:50 GMT

By Paula Willis

The Micro Focus application development products from our Application Modernization and Connectivity business offer a range of capabilities for rapid application development. One example is our Code Snippets. This blog outlines how to use and create COBOL code snippets in Visual Studio, one of the two popular IDEs supported by Micro Focus Visual COBOL and Enterprise Developer.

Error: Failed dependencies:

Peter_Kalfsbeek — Fri, 10 May 2019 15:18:05 GMT

Problem:

Trying to install COBOL Server on the same machine as Visual COBOL dev Hub in rpm formatted files resulted in errors:

rpm -i --prefix=/opt/microfocus/COBOLServer cobol_server_4.0_redhat_x86_64.rpm

error: Failed dependencies:

Micro_Focus_visualcobol_devhub conflicts with Micro_Focus_cobol_server-4.0.0.0-186407.x86_64

Micro_Focus_cobol_server conflicts with (installed) Micro_Focus_visualcobol_devhub-4.0.0.0-186407.x86_64

Resolution:

To have two RPM products installed at the same time. "nodeps" needs to be added to the following command.

rpm --nodeps -i --prefix=/opt/microfocus/COBOLServer cobol_server_4.0_redhat_x86_64.rpm

The “--nodeps” command allows two RPM products to be installed on the machine when the –prefix option is used. Otherwise it is blocked as seen.

DBC database connectors performance when bulk loading data.

tonyt — Wed, 08 May 2019 14:50:36 GMT

Using 4GL_COMMIT_COUNT=1024 really increased performance when loading database.

fork() : rts64 : Error 96 encountered in child process

NickCook — Tue, 30 Apr 2019 12:43:25 GMT

Symptoms

In Server Express I could use the fork() call. Now, with Visual Cobol, I encounter ‘rts64 : Error 96 encountered in child process’ failure.

Diagnosis

Error 96 was introduced in Visual Cobol in response to error situations which customers reported regarding thread synchronisation and deadlocks. There are, and always have been, good reasons for the limitation with fork(), and the principle has always applied – in all versions of Net Express, Server Express, and now Visual COBOL and Enterprise Developer. In practice, earlier versions such as Server Express did not trap improper uses of fork() and that appeared to work in a limited fashion, but this has become increasingly problematic over time as OS vendors tighten up over successive releases. With the latest products, it was realised that continuing the effort was not sustainable. Therefore raising the RTS 96 error early avoids a potentially long investigation on later runtime errors.

Solution

The general advice, not specific to Micro Focus, is to avoid fork() and call, but instead use fork() and exec(). As an example, refer to the Posix documentation at:

http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html

The Micro Focus documentation can be found here:

https://www.microfocus.com/documentation/visual-cobol/vc40pu8/DevHub/GUID-84954707-C2F6-4158-B83A-43DF35A28674.html

Refer to Section 'COBRT096 Invalid use of fork() (Fatal)' :

“If a process has used COBOL functionality, it can only safely call fork() if the child then safely calls one of the exec() set of APIs”.

Alternatively, the CBL_EXEC_RUN_UNIT API can be used instead to create a child process. See here:

https://www.microfocus.com/documentation/enterprise-developer/ed40pu8/ED-Eclipse/HRCLRHCALL21.html

This is a positive step in contributing to stability for customers when deploying Micro Focus Products.

OpenJDK version of Java found. This release of Java is not supported by cesadmintool

Peter_Kalfsbeek — Mon, 29 Apr 2019 10:37:21 GMT

Problem

An error appears after installing Visual COBOL development Hub 4.0 when trying to run the cesadmintool.sh to install the licenses: OpenJDK version of Java found. This release of Java is not supported by cesadmintool.

Resolution

OpenJDK is supported from Patch Update 7 onwards which is available for download from our SupportLine website with your weblogin credentials: https://supportline.microfocus.com/websync/productupdatessearch.aspx

Debugging Visual Cobol GUI class from a core dump file

raquelc — Fri, 18 Oct 2019 08:17:41 GMT

Problem:

When debugging an application using a core dump from cblcore, the Visual Cobol GUI class library is seen as part of the call stack.

How can this be debugged?

Resolution:

The GUI class IDY files are needed in order to debug, so the class needs to be compiled to produce them.

Copy the "guicl" folder located in the directory below, into another directory.

C:\Program Files (x86)\Micro Focus\Visual COBOL\cpylib\guicl\

Open the contained project apiguim.cblproj with VCVS and compile it.

If windows.cpy is missing, search for it in C:\Program Files (x86)\Micro Focus\Visual COBOL\cpylib and copy it into the project directory.

If the compilation gives error

"LINK : fatal error LNK1181: cannot open input file 'imm32.lib'",

make sure the IDE can find the following files:

comctl32.lib
comdlg32.lib
shell32.lib

For a Windows 10 machine, they are located in the following directory:

C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\um\x86

The steps below describe how to link them in the project:

On the Solution Explorer, open the Project Properties.
Navigate to the COBOL Link tab and in the “Link with libs” field
Enter the absolute paths to those libs (For Windows 10, these would be):

"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\um\x86\Imm32.Lib"

"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\um\x86\ComCtl32.Lib"

"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\um\x86\ComDlg32.Lib"

"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\um\x86\shell32.lib"

Save the changes and Rebuild the Solution.

Patch Update uninstall reboots system

PhillR — Mon, 21 Jan 2019 14:34:43 GMT

Problem:

When performing a silent uninstall of a Patch Update, prior to the subsequent install of another Patch Update, the system reboots after the uninstall and the installation of the new Patch Update fails.

Resolution:

For Visual Cobol / Cobol Server versions 4.0 and earlier, the system reboot after the silent uninstall of a Patch Update it is unavoidable

The workaround is to install the new Patch Update first and then uninstall the old Patch Update, thereby the reboot will be performed only once the whole operation is complete.

This issue will be addressed from version 5.0 onwards.

Restricting Access to the Enterprise Server Web Administration Console

blairm — Tue, 09 Oct 2018 19:57:23 GMT

Problem

How do I restrict access to the Enterprise Server Web Administration Console?

Solution

Follow these steps to restrict the Enterprise Server Web Administration Console:

In a web browser, enter the URL to open your Enterprise Server Web console. (For example: http://myserver.com:86)
From the menu on the left, select Security
Select the MF Directory Server tab
Check the box next to Restrict administration access
At the bottom of the page, click Apply
You will receive a prompt, asking that you enter the current authentication details for the "SYSAD" account. This is the default account set up for securing the Enterprise Server Web Administration Console. The prompt reads: "A change in administration … has been requested"
Enter User ID that will secure the Console (the default user id is "SYSAD")
Enter Password (the default password is also "SYSAD")
If you wish, you can also change the default password for the SYSAD as you log in. To do so, enter the new password in both new password fields (these fields may appear greyed out, but will accept entry)
Click OK
On the left, select Log Off.
The Enterprise Server Web console will be reloaded, and you will be immediately prompted for logon, password
When the login security for the console has been activated, a new HTML "splash" page is displayed after login. The HTML for this page is stored at $COBDIR/lang/default/greeting.htmf (please note the file's extension ends with lower case "F", not lower case "L"). This file can be modified to display a desired custom message.

The steps above provide simple password protection for the Enterprise Server Web Administration Console. For a more comprehensive approach to securing access, please see this article.

Increasing the font size in ViewNow when debugging in Visual COBOL for Eclipse

blairm — Fri, 05 Oct 2018 22:08:50 GMT

Problem:

How can I increase the font size in ViewNow when debugging in Eclipse?

Solution:

When using Visual COBOL for Eclipse to debug remote projects, the debugger launches xterm on the Unix machine to send the user interface to ViewNow. There is a way to pass options to xterm to control the appearance of the X window in ViewNow.

In a Debug Configuration, go to the Environment tab, and define a new Environment variable COBTERMOPTS. Here is an example:

Variable:	COBTERMOPTS
Value:	"-font -adobe---r---20-------* -bg white -fg blue" (without the quotes)

The above is an example of specifying a font, background color and foreground color to xterm. This example has been tested on a RHEL 7.1 and SUSE 12 systems.

You can first test outside of Eclipse to confirm that a given xterm option will work for you by specifying it as part of the xterm command. For example:

export DISPLAY=XX.XX.XX.XX:Y   (replace XX.XX.XX.XX with IP Address of your machine running ViewNow, and Y with port number ViewNow is using)
xterm -font -adobe-*-*-r-*-*-20-*-*-*-*-*-*-* &

If the above example does not work, please check with your System Administrator to confirm which fonts you have installed, or other options supported on your system to control the appearance of xterm.

Issue: RPM Patch Update Installer for 4.0 Products may remove product

Chris Glazier — Thu, 04 Oct 2018 19:45:39 GMT

Issue:

When using the “-U” option with the 4.0 Patch Update product, the base product is removed leaving no product files on the machine.

Example Install Scenario:

Customer has Micro Focus Development Hub 4.0 installed.
They want to install Micro Focus Development Hub 4.0 Patch Update 1.
They run “rpm –U visualcobol_devhub_4.0_patchupdate01_redhat_x86_64.rpm”
This runs without error but once complete there are no product files on the machine.

Code was added into the 4.0 RPM installer to remove any files left behind in the installer directory when the product was removed. This was added to the post uninstall RPM section of the installer.

When an upgrade is performed the base products post uninstall actions are triggered and so the tidy code is run, resulting in all the product files being removed.

Fix:

Code has now been added to the tidy script to ensure it only runs on a true uninstall and not during an upgrade.

Affects:

This issue affects upgrading from the following products.

4.0 GA
4.0 Patch Update 1
4.0 Patch Update 2
4.0 Patch Update 3

This issue has been fixed in Patch Update 4 but because the uninstall function is run from the previous installed product this issue will only go away once Patch Update 4 is the base product and is being upgraded to Patch Update 5 or higher.

Workaround:

If the customer has installed a Patch Update via RPM -U and found the product is now missing they need to perform the following steps.

The product files have been removed from the machine but RPM still has the product installed. So the RPM database need to be updated.

rpm –qa | grep Micro
rpm -e <package name from above command that pertains to the product being updated>

This will remove the product from the RPM database and save any confusion in the future.

Now just run the Patch Update installer with the normal options used for an install.

rpm –I < Patch Update RPM file>

The Patch update is a full install so all files found in the GA product plus those fixed and delivered in the Patch Update are installed.

If the customer has not yet run the Upgrade process they just need to remove the currently installed product and then install.

rpm –qa | grep Micro
rpm -e <package name from above command>
rpm –I < Patch Update RPM file>

Cesadmintool: Java version 1.6.0_161 in the following location is incompatible.

PhillR — Wed, 26 Sep 2018 09:59:54 GMT

Problem:

Unable to install new licenses with version 4.0 as it is impossible to run the cesdamintool.sh.

It keeps showing the message: "incompatible java version, needs 1.5 or later."

Even with java version 1.6 being installed, "Cesadmintool: Java version 1.6.0_161 in the following location is incompatible." is displayed.

Resolution:

This is an incorrect message displayed by the installer because Java 1.7 is now the lowest version supported.

Unfortunately the scripts logic was updated to detect the new version of java but the message displayed was not.

So there is the need to update to Java 1.7, ideally 1.8 so it will include the latest security fixes etc.

This is fixed in patch update 3 and later to correct this wrong message displayed.

License files are by default created in /tmp directory. Can this be changed?

PhillR — Wed, 26 Sep 2018 09:44:30 GMT

Problem:

If the /tmp directory is cleaned up, it will remove license related files which are by default created in the /tmp directory.

Resolution:

There are two types of file stored in /tmp by default.

The socket file which is used to communicate between mfcesd and the COBOL apps.

This file can be relocated by setting socketdir (e.g. socketdir=/var/microfocuslicensing/socket) in ces.ini (needs version 10000.2.02090 or later and the folder will need to be created with 666 permissions ). NOTE: The file is abstract on Linux systems so there should be no issue.

The second type is the lock file (mfcesd.lock).

This is used to prevent a second copy of mfcesd from running and to help identify the mfcesd process when stopping it vis stopmfesd.sh etc.

This file being removed is less important, but you need to be aware this may cause issues with starting/stopping mfcesd.

Re: Example of Producing User-generated COBOL Run-Time System Errors

spgennard — Sun, 05 Aug 2018 21:21:00 GMT

The line:

move "Application Generated Runtime Error" to ws-error-str

Should be:

move z"Application Generated Runtime Error" to ws-error-str

Example of Producing User-generated COBOL Run-Time System Errors

TatyanaP — Fri, 03 Aug 2018 03:12:03 GMT

This example has been tested with Enterprise Developer 4.0 and with Visual COBOL 4.0 for Eclipse and Visual Studio.

In situations where an application fails with an error condition that it cannot recover from, you might want the application to terminate the process in such a way that error processing occurs. For such scenarios, Micro Focus provides the CBL_RUNTIME_ERROR library routine that enables you to display a custom message.

You need to call the CBL_RUNTIME_ERROR library routine from your code and provide a message string to indicate the error. The API that uses this routine takes a flags parameter. Setting the flag to 0 forces the application to terminate and generate the specified user COBOL Run-Time System error displayed as an RTS 150 message. The message enables the user to determine which (of potentially several) error condition caused the termination.

If the core_on_error tunable is also set, CBL_RUNTIME_ERROR makes it easier to debug application errors from a production environment.

CBL_RUNTIME_ERROR is a cross-platform library routine and can be used on both Windows and UNIX/Linux.

Example:

The following is an example of how to call this routine from your code:

identification division.

program-id. RTSERR1.

environment division.

configuration section.

data division.

working-storage section.

01 ws-flags pic x(4) comp-5.

01 ws-error-str pic x(255).

procedure division.

display "This program will generate a COBOL Runtime"

" error to force termination."

move 0 to ws-flags

**** Null Terminated String for text is required.

move z"Application Generated Runtime Error" to ws-error-str

call "CBL_RUNTIME_ERROR" using by value ws-flags

by reference ws-error-str

end-call

display "This will never be reached as RTS Error handling is"

" invoked."

goback.

end program RTSERR1.

This code produces an error message at run time:

Execution error : file 'RTSERR1'

error code: 150, pc=0, call=1, seg=0

150 Program abandoned at user request (Application Generated Runtime Error)

After Installation, Error Opening Workspace in Visual COBOL for Eclipse 3.0 on Windows Server 2016

Chris Glazier — Thu, 12 Jul 2018 18:59:39 GMT

Problem:

After installation, when opening any workspace you receive the following error.

"TSUIN0126 At least one exception occurred during the initialization of the AWM meta model. See error log for more information."

Resolution:

This error can be caused by a bug in the version of Eclipse that is delivered with Visual COBOL 3.0, which may not recognize Windows Server 2016 as a valid operating system. This can be resolved by manually specifying an Operating System version that Eclipse will recognize, following these steps:

1) Open "C:\Users\Public\Micro Focus\Visual COBOL\eclipse\eclipse.ini"

2) Add the following to the bottom of the file

-Dos.name=Windows Server 2015 R2

3) Save the file and then reload Eclipse

Note: This problem does not occur in Visual COBOL for Eclipse 4.0.

Licensing error 244 occurs when running native applications with COBOL Server 4.0

Fano_MF — Tue, 26 Jun 2018 15:01:01 GMT

Problem:

Running a native COBOL application from a network server with COBOL Server 4.0 works fine the first time. Any subsequent runs fail with the following:

Execution error : file ''
error code: 244, pc=0, call=1, seg=0
244 Licensing initialization error

Resolution:

The Micro Focus development team is looking into this issue, and the workaround in the meantime is to add the following entry in the .mfcfg file:

SETENV MFCES_INIT_LOCATION=\\ServerName\MicroFocusSrv\Bin\ces.ini

where Servername is the name or IP address of the server and MicroFocusSrv is the network share name on the COBOL Server 4.0 installation folder.

COBOL calling a C function within a library using the INITCALL directive.

raquelc — Fri, 15 Jun 2018 12:48:31 GMT

Problem:

On Linux/Unix, a COBOL program can call a C function within a library using INITCALL, but on Windows, it gives error: 173 Called program file not found in drive/directory.

Resolution:

INITCALL loads the dll/so, but it needs to know what entry is being called within it. One way to achieve this is by having the same entry name as the binary module itself. However, there might be several entries in the dll/so that would need to be called separately. In this scenario, INITCALL behaves differently in Linux/Unix compared to Windows.

When the entry and the shared object name are different, on Linux/Unix, the entry can be called by using the "-e name" flag at compilation time.

On Windows, if the Cobol program cannot find an entry with the same name as the dll/so, the first entry in ordinal position is called. To change this behaviour, any entry within the dll that is to be called by COBOL must be exported. For this, a .def file must be created for the dll containing the relevant entry points. Example:

EXPORTS

Entry1

Entry2

Entry3

…

Then, the .def file must be compiled together with the C source when creating the dll:

cl /LD program.c entryfile.def

Note that the Cobol program and the dll must be in the same directory or on %PATH%.

"ESPackage could not load" message shown when starting Visual COBOL for Visual Studio 2017, not all Visual COBOL components are loaded.

KimH — Mon, 28 May 2018 13:39:36 GMT

Problem:

"ESPackage could not load" message shown when starting Visual COBOL for Visual Studio 2017, not all Visual COBOL components are loaded.

Resolution:

To avoid this message ensure your Windows Operating System region settings are set as follows:
- English set as Windows display language
- In Windows regional settings > formats set to "match windows display ()"

Creating Record Layout (.str) files from the command line with DFSTRCL

Mark_B — Thu, 07 Mar 2019 09:49:33 GMT

Problem:

The Record Layout Editor within the Classic Data File Tools enables the creation of structure files (.str) for use when viewing and editing records in a structured or formatted way within the Data File Editor.

Typically a Record Layout File is created within a Visual COBOL project by right-clicking on the source file name within the solution explorer that contains the Data Division information you require, and selecting Create Record Layout File.

(Note: The program must be compiled and a .idy file must exist).

However if there are several data files that require layouts, this process must be repeated for each file.

Resolution:

Note: DFSTRCL creates DEFAULT record layout (.str) files, if conditional record layout files are required use the New Record Layout Wizard from within the Data File Editor

The Data File Structure Command Line (DFSTRCL) was added in Visual COBOL V2.3. The utility enables you to create DEFAULT record layout (.str) files from .idy files directly from the command line, and must be run from a Visual COBOL command prompt.
DFSTRCL can be used to process a single debug information (.idy) file. Alternatively, it can be configured to perform batch processing using a parameters file passed at the command line using the /r parameter. Please refer to the Visual COBOL documentation for further details.

In the example below a data file has two record layouts STUDENT-RECORD and COURSE-RECORD.
A default record layout based on the STUDENT-RECORD needs to be created, the .str will be saved in the same location as the .idy file.

The COBOL program must be compiled for debug
Run DFSCTRL passing the necessary parameters:

e.g. DFSTRCL STUDENTS.IDY /D STUDENT-RECORD
(where /D is record name)
Load the data file into the Data File Editor to view/edit in formatted mode

e.g. MFDATATOOLS STUDENTS.DAT

Click on the video to follow the necessary steps:

8802.DFSTRCLDemo.mp4

(Note: If conditional record layout files are required use the New Record Layout wizard from within the Data File Editor)

“java.lang.nullpointerexception” error shown when using COBOL Application Run Configuration - Visual COBOL for Eclipse 3.0

PhillR — Thu, 15 Mar 2018 12:43:12 GMT

Problem:

“java.lang.nullpointerexception” error shown when using COBOL Application Run Configuration - Visual COBOL for Eclipse 3.0

Resolution:

This is a known Eclipse IDE issue when using a monitor with high DPI settings (e.g. 4k monitor), see Eclipse Bug report:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=495849

To resolve this, consider upgrading Eclipse from version 4.6.0 to version 4.6.3 where handling of monitors with high DPI is improved.

"The ordinal 77 could not be loaded in dynamic link library utils.dll” shown when starting Visual COBOL for Eclipse.

KimH — Thu, 15 Mar 2018 12:37:20 GMT

Problem:

"The ordinal 77 could not be loaded in dynamic link library utils.dll” shown when starting Visual COBOL for Eclipse.

Resolution:

This can be related to other software being installed on the same machine that also uses the same utils.dll file which the Visual COBOL Product uses for normal operation. As an example the Dell Unified Wireless Suite uses a utils.dll, if you are using this Dell software you can consider to uninstall this and installing just the wireless card driver as per http://en.community.dell.com/support-forums/laptop/f/3518/t/19595964

The issue is caused by a filename clash and the 3rd party product not locating its version of this file correctly.

Visual COBOL EJB Demo for JBoss EAP 6.4 Java 8

Steven_Lalewicz — Wed, 07 Feb 2018 09:26:46 GMT

A version of the EJB Demo with project files updated for Java 8 and JBoss EAP 6.4 (JBoss 7.5).

Visual COBOL 3.0 and Visual COBOL 4.0

Run-time System Error Message - COBRT245 - There are no valid product licenses (Fatal), occurs when running application from a remote machine.

Mark_B — Thu, 14 Dec 2017 18:19:25 GMT

Problem:

I have shipped Selected Files from COBOL Server together with my application files. When I run the application from a remote PC the RT Error 245 occurs.

Resolution:

Note: Micro Focus recommends that you ship the whole of COBOL Server with your application. However to provide backward compatibility, you can still select and ship specific files.

Follow instructions in the Knowledgebase Article: Network deployment of Visual COBOL 2.3 native applications

For this type of installation/configuration the progname.exe.mfcfg should contain the following two lines:

SET BINPATH=\\ServerName\COBOLsrv

SET CESDYNAMIC=ces.ini

Installing the Oracle SCOTT schema for testing with Visual COBOL

Mark_B — Tue, 31 Oct 2017 19:40:49 GMT

Problem:

I have installed Oracle 11g Express and Pro*COBOL precompiler to test this COBOL program with embedded SQL that uses the SCOTT schema:

IDENTIFICATION DIVISION.

PROGRAM-ID. ORATEST.

ENVIRONMENT DIVISION.

DATA DIVISION.

WORKING-STORAGE SECTION.

EXEC SQL INCLUDE SQLCA END-EXEC

EXEC SQL BEGIN DECLARE SECTION END-EXEC.

01 USERNAME PIC X(10).

01 PASSWD PIC X(10).

EXEC SQL END DECLARE SECTION END-EXEC.

PROCEDURE DIVISION.

LOGON.

MOVE "SCOTT" TO USERNAME

MOVE "TIGER" TO PASSWD

EXEC SQL

CONNECT

:USERNAME IDENTIFIED BY :PASSWD

END-EXEC.

DISPLAY SQLCODE

STOP RUN.

However when I run my program I receive an error ORA-01017: invalid username/password; logon denied, what is wrong?

Resolution:

The SCOTT schema contains a number of tables that can be used for testing purposes, and needs to be installed.

The follow these steps to install the schema:

Open a command prompt
Change directory to C:\oraclexe\app\oracle\product\11.2.0\server\rdbms\admin
this directory contains a number of SQL scripts including SCOTT.SQL
Start SQLPlus as follows:

SQLPLUS /AS SYSDBA (this logs onto the database as SYSDBA in order to carry out some admin tasks :
Having successfully logged on, the SCOTT.SQL script needs to be run as follows:

@SCOTT
Now check the tables exist by running the following query:

SELECT TABLE_NAME FROM DBA_TABLES WHERE OWNER=’SCOTT’

Now run the program again - successfully:

Cannot start server/region: CASCF0052S casstart: Error reading console daemon configuration data

Dan Wright — Mon, 30 Oct 2017 21:43:20 GMT

Problem:

On Linux/UNIX, a server/region in Enterprise Server (ES) would not start. The error message was: CASCF0052S casstart: Error reading console daemon configuration data

Solution:

Here is a link into the documentation showing an explanation:

http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.eclipse.infocenter.visualcobol.vs2012%2FGUID-6081411C-F6E2-42BC-8FD8-3C748C9C05A8.html

It is a permissions problem with the "system directory" of the server/region, caused by trying to start the server/region using a different Linux/UNIX user-id than the user-id used when the server/region was last started.

The system directory is where files such as the console.log, log-1.html, etc. are kept. The directory is created and owned by the user-id that last started the server/region, and if you try to start the server/region with a different user-id, there will be a permissions problem on the system directory.

The quickest way to overcome this problem is to remove or re-name the existing system directory. On disk the system directory has the same name as the server/region, and by default it is located in /var/mfcobol/es, though the location can be configured using the "casperm" command or by modifying the file $COBDIR/etc/cas/cas.cfg. To reveal the current location, enter:

grep CASROOT $COBDIR/etc/cas/cas.cfg

Example:

$ grep CASROOT $COBDIR/etc/cas/cas.cfg
CASROOT=/var/mfcobol/es
$ cd /var/mfcobol/es
$ ls
ESDEMO
$ mv ESDEMO ESDEMO-old

After the existing system directory is removed or re-named, then when the server/region is next started, it will create a new system directory, and will start successfully.

If you start the server/region by clicking the "Start" button on the ES Admin page, then the user-id will be the "Default startup process user ID" that you see on the Start page. But if you use "casstart" or "casstop" from the command line, you could possibly be logged in as a different user-id. The long-term solution to this problem is to use the same user-id to start the server/region each time. If you want to use "casstart" or "casstop", and sometimes you also want to use the "Start" and "Stop" buttons on the ES Admin page, then when you use "casstart" or "casstop", make sure you are logged in as the "Default startup process user ID" from the Start page.

XML-PARSE fails with exception 791043 when compiling using the XMLPARSE(XMLSS) directive

Matthew Coronado — Mon, 30 Oct 2017 16:31:46 GMT

Problem:

Programs that use the XML-PARSE directive, fail to compile with an exception 791043 in Visual COBOL version 2.3 Update 2 and 3.0

Resolution:

In Visual COBOL 2.3 Update 2 and 3.0, the new parser used by XML-PARSE in XMLSS mode does not recognise the encoding "Windows-1252".

Changing the XMLPARSE directive to use XMLPARSE(COMPAT) or changing the XSD's encoding from "Windows-1252" to "ISO-8859-15" can be used as a workaround.

A fix for this compilation error will be available in the 4.0 version of Visual COBOL.

Re: Visual COBOL 2.2 - SOAP Web Services Tutorial

EdwinT — Wed, 25 Oct 2017 21:15:12 GMT

good day

I am very grateful to anyone who can collaborate with a tutorial or example to generate a Web service, but in VISUAL STUDIO 2015, I must also generate the WSDL. I can not generate it in VIsual since I can not find how to generate the WSDl or .War file

Thanks

Dialog System application fails with RTS 173 on mfdir2

Fano_MF — Thu, 19 Oct 2017 21:39:44 GMT

Problem:

A Dialog System application fails with the following error when it does a CALLOUT to "dsdir":

Load error: file 'mfdir2'
error code: 173, pc=0, call=1, seg=0,
173 Called program file not found in drive/directory.

Solution:

This RTS 173 on 'mfdir2' occurs when the application is linked as 'Console Application' in Visual COBOL. It should be linked as 'Windows Application' instead.

Here are the steps to resolve this issue:

open the project in Visual Studio
open the project properties
select Windows Application from the Output Type drop-down under Application properties
rebuild the project
redeploy the application

The equivalent of the above from the command line is to use the -g switch in the cbllink command, e.g. cbllink -g -v -re ...

How to build the .exe in a different folder leaving the other generated files in the output path?

Fano_MF — Wed, 18 Oct 2017 21:04:32 GMT

Problem:

When building a project, all output files are created in one location that is specified from the COBOL properties as Output Path. Is there a way to create the .exe in a different folder leaving all the other generated files in the output path?

Solution:

It is not possible to have the .exe created in a different folder while the rest of the generated files get created in the output folder. However, a post-build event can be used to have the .exe file to be copied to another folder after a successful build.

Here are the steps to create a post-build event that copies the .exe file to a folder (e.g. C:\Prod) after each successful build:
1. go to project properties
2. click on COBOL properties
3. click on Build Events
4. click on Edit Post-build
5. type copy or xcopy (with a trailing space)
6. click on Macros (to see all possible macro names)
7. double-click on TargetFileName
8. type the target folder to have the following:
xcopy $(TargetFileName) C:\Prod
9. click on OK
10. leave the Run the post-build event drop-down with On successful build
11. click on OK to exit

How to resolve the location of Dialog System's .icn side file?

Fano_MF — Wed, 18 Oct 2017 20:32:18 GMT

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.

Error connecting to SQL Server - Connection is busy with results for another command

Matthew Coronado — Tue, 17 Oct 2017 08:54:26 GMT

Problem:

'Connection is busy with results for another command ' error received when executing a COBOL application where the program tries to connect to an SQL Server database.

Resolution:

This SQL Server error message is thrown when there are multiple connections going to the same database, through the same connection driver e.g. ODBC.

The error is not specific to the COBOL language and can be resolved by enabling the MARS (multiple active results sets) SQL directive.

This can be set at a database level and/or in the SQL COBOL compilation directives by specifying SQL(MARS).

Content is cut after a low-value when using a tool-tip during a debug session

Robert Milligan — Tue, 17 Oct 2017 08:21:21 GMT

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

Visual COBOL - What to do for missing cblrtssi.lib?

KimH — Tue, 03 Oct 2017 14:55:33 GMT

Problem

With Net Express, to use the single threaded runtime, the following .lib file would need to be linked to the affected cobol program:
"C:\Program Files (x86)\Micro Focus\Net Express 5.1\Base\Lib\cblrtssi.lib".

In Visual COBOL this file is not present any more, so what is required?

Resolution

There are two types of the imported library of the COBOL runtime system in Net Express, one is for single-threaded runtime system (CBLRTSSI.LIB) and the other multi-threaded (CBLRTSMI.LIB).

In Visual COBOL, since everything is multi-threaded, there is no single-thread imported library.

For this reason, the solution is to link CBLRTSMI.LIB.

This library can typically be found in "C:\Program Files\Micro Focus\Visual COBOL\lib" in 32-bit Windows or in "C:\Program Files (x86)\Micro Focus\Visual COBOL\lib" in 64-bit Windows, depending on where Visual COBOL is installed to.

Cannot install Visual COBOL - exits automatically with: echo $? outputs 0

Peter_Kalfsbeek — Wed, 13 Sep 2017 13:57:29 GMT

PROBLEM

When trying to install *.rpm file - it exits without installing properly with the message:

echo $? outputs 0 and product has not been installed.

RESOLUTION

rpm -ivv will provide more information on what is going wrong.

If it shows openjdk which outputs "openjdk version" instead of "java version", it means it has not detected the correct java installation.

You will need the official Oracle java package for the *.rpm package to install properly.

Visual COBOL/Enterprise Developer fails to install - Error shown: A matching Microsoft Visual Studio Shell (Isolated) language pack is required

KimH — Tue, 12 Sep 2017 11:52:34 GMT

Problem

Visual COBOL or Enterprise 2.3.x can fail when installing on a Windows Operating Systems that use different locale to English.

Reviewing the installation log file, typically located in path:
e.g.
%temp%\Micro_Focus_Enterprise_Developer_for_Visual_Studio_2012_20170515140705_0_vs2012intshell.log

Entries such as the following are seen:
[1290:0F18][2017-05-16T11:21:13]: MUX: Stop Block: IsoShellLPBlock : A matching Microsoft Visual Studio Shell (Isolated) language pack is required, but it is not installed on this computer. Please install the Microsoft Visual Studio Shell (Isolated) language pack for this language and retry.

Resolution:

To resolve the issue the relevant language pack should be installed, see Microsoft’s download website e.g. URL: https://www.microsoft.com/en-us/download/details.aspx?id=30671.

Visual COBOL/Enterprise Developer - In Eclipse how to run with profiler?

KimH — Tue, 12 Sep 2017 11:46:37 GMT

Problem

How to run a COBOL program with the profiler enabled in the Eclipse IDE

Resolution

To enable this

open the Run Configuration used with the project,
locate the dynamic analysis tab,
locate the enable Profiler option “Enable Profiling”,
Click OK/Run.

The .ipf file is then generated in a ..\Profiler folder in the project directory for analysis.

Visual COBOL/Enterprise Developer for Eclipse - Compile only certain sources in project with target “all gnt/int files”

KimH — Tue, 12 Sep 2017 11:40:51 GMT

Problem

Using the Eclipse IDE how can only certain sources within a project with target “all gnt/int files” be compiled?

Resolution:

This can be achieved by clicking on the relevant source files in the cobol explorer view and holding down the ctrl key to multi select the ones that should be compiled. Once the source files are selected, then right click on one of the selected source files and click the compile option.

Only those selected source files will be compiled.

Using Visual COBOL compiled application does not run on Windows XP or Windows 2003

KimH — Tue, 12 Sep 2017 11:40:00 GMT

Problem

When running a Visual COBOL compiled application on Windows XP, it fails to start. Various errors can be shown, for example a "not a valid image" dialog.

Resolution

Ensure that the application is compiled using the command:

cbllink –y

Option y specifies that the application is to be built so that it can also run on Windows XP and Windows Server 2003.

If working within Visual Studio or the Eclipse IDE this option can be added to the Additional Directives area.

How to package Dialog system screenset .gs files into a LBR file using Visual COBOL

KimH — Tue, 12 Sep 2017 11:35:27 GMT

Problem

Visual COBOL Project contains .gs screenset files but these need to be packaged to one .lbr file.

When building the project the following error may be encountered:

File obj\x86\Debug\<Filename> could not be copied, as the file was not found.

Resolution

All the screenset files present in the project , by default, would be marked as Build Action "none" in all the screenset file's properties.

Change this property to Build Action "content", at the next build attempt the .lbr file will be generated without no error.

Enterprise Server deployed Java Web Service Interface calls COBOL program in UPPER case. How do you call a program in lower case?

KimH — Tue, 12 Sep 2017 11:05:53 GMT

Problem

An Enterprise Server deployed Java Web Service Interface calls COBOL program in UPPER case, resulting in RTS 173 errors as the COBOL program is compiled to lower case.

What needs to be done to set the Java Interface to call the COBOL program in lower case?

Resolution

Use the directive FOLD-CALL-NAME "LOWER" in the project that deploys the Java Web Service Interface to resolve this issue.

Re: The use of Python ctypes to call COBOL

Josemg — Tue, 05 Sep 2017 13:37:20 GMT

I run it only without my environment but I had errors. SLE 11 SP2 is very poor in the library.

The instalaltion for default do nto has a compilaer the probles is SLE a bad }very bad linux!!!

I will discard this solution a bad idea.

Re: The use of Python ctypes to call COBOL

Michael_Wojcik — Tue, 05 Sep 2017 12:45:44 GMT

The comments section of the Knowledge Base is the wrong place for an extended discussion. Please raise this as a new topic an appropriate MF Community forum.

I'll be frank: It will be difficult to help you get this running if you don't have a solid understanding of basic Linux concepts. libdl.so is one such concept. So is the use of PATH and LD_LIBRARY_PATH. PATH is not used to search for shared objects, so there's no reason to be changing it. Adding random application directories (such as /Oracle/apps/...) to LD_LIBRARY_PATH is not likely to be productive; and now your script is resetting its entire value, so commenting out the unset command is pointless, and you've undone any changes that cobsetenv made to it.

Re: The use of Python ctypes to call COBOL

Josemg — Mon, 04 Sep 2017 13:20:10 GMT

I search for libdl.so, I had not in my path. I added to PATH and LD_LIBRARY_PATH, the error is different.

With which libdl.so I had 3 places when I found it.

./usr/lib64/libdl.so

./home/oracle/app/oracle/product/11.2.0/client_1/lib/stubs/libdl.so

./home/oracle/app/oracle/product/11.2.0/client_2/lib/stubs/libdl.so

./oracle/app/oracle/product/11.2.0.4/db_1/lib/stubs/libdl.so

I add /usr/lib/libdl.so to my PATH and the fisrt Oracle path to LD_LIBRAY_PATH.

I change the script like this: (I need *.CBL, in UPPER case in my configuraiton...)

---------------------------------------------

# set cobol environment

# unset LD_LIBRARY_PATH

. /etc/profile.d/cobsetenv.sh

export ORACLE_HOME=/home/oracle/app/oracle/product/11.2.0/client_2

export PATH=$ORACLE_HOME/bin:$PATH:/lib64:/lib:/usr/lib64/

export LD_LIBRARY_PATH=/opt/microfocus/EnterpriseDeveloper/lib:/home/oracle/app/oracle/product/11.2.0/client_2/lib:/lib64:/lib:/home/oracle/app/oracle/product/11.2.0/client_1/lib/stubs

export COBCPY=$COBCPY:/home/equifax/copys

export COBDIR=/opt/microfocus/EnterpriseDeveloper

export LC_PRELOAD=/opt/microfocus/EnterpriseDeveloper/lib:/lib64

COBMODE=64

export COBMODE

# create c program

cat >helloworld.c <<EOF

/* Hello World program */

#include<stdio.h>

#include<cobmain.h>

#include<cobtypes.h>

int cobinit (void);

main()

{

cobinit ();

printf("Started Hello World\n");

program1();

cobtidy();

}

EOF

# create cobol program

cat >program1.CBL <<EOF

program-id. program1 as "program1.CBL".

environment division.

configuration section.

data division.

working-storage section.

01 in_data pic x(10) value "prog1 data".

procedure division.

display "program 1 has started"

* call "Program2" using in_data.

goback.

end program program1.

EOF

# build the .so file

cob -Zv helloworld.c program1.CBL

# create python script

cat >mytest.py <<EOF

import ctypes

import sys, os

print "LD_LIBRARY_PATH <" + os.environ['LD_LIBRARY_PATH'] + ">"

print "LD_PRELOAD <" + os.environ['LD_PRELOAD'] + ">"

print "sys.path <"

print sys.path

print ">"

mylib = ctypes.CDLL("./libhelloworld.so")

print "before c call"

mylib.main()

print "after c call"

exit()

EOF

# run the python file

# get these modules loaded

export LD_PRELOAD=$COBDIR/lib/libcobcrtn64.so:$COBDIR/lib/libcobrts64.so:$COBDIR/lib/libcobmisc64.so:$COBDIR/lib/libcobscreen64.so:$COBDIR/lib/libcobtrace64.so

# run the python script

python mytest.py

# remove the LD_PRELOAD

# unset LD_PRELOAD

# end

---------------------------------------------------

When I run now the output is this:

--------------------------------------------------------

pccdesa@DSuseBilling01:/home/equifax/python/fuentes/TEST03> ./doit.sh

COBDIR set to /opt/microfocus/EnterpriseDeveloper

cob64 -C nolist -Zv helloworld.c program1.CBL

helloworld.c:

program1.CBL:

* Micro Focus COBOL V2.2 revision 002 Compiler

* Accepted - verbose

* Accepted - nolist

* Compiling program1.CBL

1 program-id. program1 as "program1.CBL".

*1641-S************************************** **

** '.' in source filename or PROGRAM-ID in native code

* Total Messages: 1

* Unrecoverable : 0 Severe : 1

* Errors : 0 Warnings: 0

* Informational : 0 Flags : 0

* Data: 178 Code: 0

cob64: error(s) in compilation: program1.CBL

LD_LIBRARY_PATH </opt/microfocus/EnterpriseDeveloper/lib:/home/oracle/app/oracle/product/11.2.0/client_2/lib:/lib64:/lib:/home/oracle/app/oracle/product/11.2.0/client_1/lib/stubs>

LD_PRELOAD </opt/microfocus/EnterpriseDeveloper/lib/libcobcrtn64.so:/opt/microfocus/EnterpriseDeveloper/lib/libcobrts64.so:/opt/microfocus/EnterpriseDeveloper/lib/libcobmisc64.so:/opt/microfocus/EnterpriseDeveloper/lib/libcobscreen64.so:/opt/microfocus/EnterpriseDeveloper/lib/libcobtrace64.so>

sys.path <

['/home/equifax/python/fuentes/TEST03', '/usr/lib/python26.zip', '/usr/lib64/python2.6', '/usr/lib64/python2.6/plat-linux2', '/usr/lib64/python2.6/lib-tk', '/usr/lib64/python2.6/lib-old', '/usr/lib64/python2.6/lib-dynload', '/usr/lib64/python2.6/site-packages', '/usr/local/lib64/python2.6/site-packages']

Traceback (most recent call last):

File "mytest.py", line 11, in <module>

mylib = ctypes.CDLL("./libhelloworld.so")

File "/usr/lib64/python2.6/ctypes/__init__.py", line 353, in __init__

self._handle = _dlopen(self._name, mode)

OSError: ./libhelloworld.so: cannot open shared object file: No such file or directory

pccdesa@DSuseBilling01:/home/equifax/python/fuentes/TEST03>

---------------------------------------

And these are the objects in the folder

------------------------------------------------

pccdesa@DSuseBilling01:/home/equifax/python/fuentes/TEST03> dir

total 76

-r-xr--r-- 1 root root 1400 Sep 1 10:01 cobmain.h

-r-xr--r-- 1 pccdesa users 3694 Sep 1 10:03 cobtypes.h

-rwxr-xr-- 1 pccdesa users 2052 Sep 4 09:02 doit.sh

-rw-r--r-- 1 pccdesa users 202 Sep 4 09:03 helloworld.c

-rw-r--r-- 1 pccdesa users 1744 Sep 4 09:03 helloworld.o

drwxr-xr-x 2 pccdesa users 4096 Sep 1 10:36 lang

drwxr-xr-x 2 pccdesa users 4096 Sep 1 10:35 lib

-rw-r--r-- 1 pccdesa users 336 Sep 4 09:03 mytest.py

-rw-r--r-- 1 pccdesa users 394 Sep 4 09:03 program1.CBL

-rw-r--r-- 1 pccdesa users 39168 Sep 4 09:03 program1.idy

pccdesa@DSuseBilling01:/home/equifax/python/fuentes/TEST03>

-----------------------------------------------

In my installation there was not compiler, then I have installed gcc4.1 and I done a link symbolic to cc for python. I am new with python, but I found this sample that could be good for my job.

Thanks

Re: The use of Python ctypes to call COBOL

Michael_Wojcik — Mon, 04 Sep 2017 12:41:35 GMT

"man dlopen" would answer your question "What is dlopen?".

The programs running under the script aren't finding libdl.so, which is a standard system shared object.

The script begins by unsetting LD_LIBRARY_PATH, which looks like a bad idea to me. I'd try it with that line removed.

Re: The use of Python ctypes to call COBOL

Josemg — Fri, 01 Sep 2017 16:01:49 GMT

I have many errors, for example cobint() need

#include <cobmain.h> and #include cobtypes.h

I added both to script code....

I create folders lib and lang

after that I got:

What is dlopen ??

Can I set this for ED in SLE 11 SP2 ?

I had to install gcc4.1 glibc-devel cpp41.1 ...and nw this...

/home/equifax/python/fuentes/TEST03> . ./doit.sh

uname: symbol lookup error: /opt/microfocus/EnterpriseDeveloper/lib/libcobrts64.so: undefined symbol: dlopen

COBDIR set to /opt/microfocus/EnterpriseDeveloper

cat: symbol lookup error: /opt/microfocus/EnterpriseDeveloper/lib/libcobrts64.so: undefined symbol: dlopen

ERROR: ld.so: object '/opt/microfocus/EnterpriseDeveloper/lib/libcobcrtn64.so' from LD_PRELOAD cannot be preloaded: ignored.

ERROR: ld.so: object '/opt/microfocus/EnterpriseDeveloper/lib/libcobrts64.so' from LD_PRELOAD cannot be preloaded: ignored.

ERROR: ld.so: object '/opt/microfocus/EnterpriseDeveloper/lib/libcobmisc64.so' from LD_PRELOAD cannot be preloaded: ignored.

ERROR: ld.so: object '/opt/microfocus/EnterpriseDeveloper/lib/libcobscreen64.so' from LD_PRELOAD cannot be preloaded: ignored.

ERROR: ld.so: object '/opt/microfocus/EnterpriseDeveloper/lib/libcobtrace64.so' from LD_PRELOAD cannot be preloaded: ignored.

/opt/microfocus/EnterpriseDeveloper/bin/cob64: symbol lookup error: /opt/microfocus/EnterpriseDeveloper/lib/libcobrts64.so: undefined symbol: dlopen

cat: symbol lookup error: /opt/microfocus/EnterpriseDeveloper/lib/libcobrts64.so: undefined symbol: dlopen

pccdesa@DSuseBilling01:/home/equifax/python/fuentes/TEST03> ld.so /opt/microfocus/EnterpriseDeveloper/lib/libcobcrtn64.so

/opt/microfocus/EnterpriseDeveloper/lib/libcobcrtn64.so: symbol lookup error: /opt/microfocus/EnterpriseDeveloper/lib/libcobrts64.so: undefined symbol: dlopen

Re: Visual COBOL RM/Panels Conversion - Windows

Juan Urraburu — Mon, 19 Jun 2017 14:15:00 GMT

Where can I find runpan2.dll?

How to configure Shared Memory Pages and Shared Memory Cushion for a Server (region)

Dan Wright — Mon, 01 May 2017 04:05:44 GMT

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 to be certain the Server has enough shared memory. When a Server is running under load and the shared memory settings are exceeded, the following error might appear 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, go into Server > Properties > Control > ES Monitor & Control (a. k. a. 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 -- 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 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. Start 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. For example 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.

Unable to debug GNT in Windows 10

Fano_MF — Fri, 17 Mar 2017 20:24:14 GMT

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.

When I launch a Dialog System application from a desktop shortcut the console window briefly appears and disappears before my application starts.

Mark_B — Fri, 17 Mar 2017 18:20:44 GMT

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 :

Dialog System Error 18 occurs when running deployed application

Mark_B — Thu, 16 Mar 2017 21:52:11 GMT

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

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

How to use the ADISCTRL file in a different folder?

Fano_MF — Thu, 16 Mar 2017 17:25:59 GMT

Problem:

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

Resolution:

The main reason for having the ADISCTRL file in a different folder is when multiple applications are using this same file. It then becomes easier to manage one single file instead of managing the same copy in each one of the application folders.

There is one location in Visual COBOL or COBOL Server where the file can be picked up automatically, and that location is %COBDIR%\etc\

If the ADISCTRL file must be in a location other than the application folder and %COBDIR\etc, 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

Note: The COBDIR environment variable (i.e. %COBDIR%) can only be used to point to the location of the COBOL system folder in Visual COBOL or COBOL Server.

Use REBUILD to convert to IDXFORMAT(8)

Mark_B — Fri, 03 Feb 2017 18:37:44 GMT

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)

By default Visual COBOL V2.3 creates indexed sequential files as IDXFORMAT(8) (large format),

in addition FILEMAXSIZE(8) is also set by default.

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

Note: When working with Linux/UNIX:

mkdir new

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

For further information regarding IDXFORMAT and FILEMAXSIZE, please refer to the product documentation.

For information with respect to File size limits for Server Express and Net Express please refer to this article.

Re: Working with Textboxes in Visual COBOL

doncole52 — Thu, 02 Feb 2017 21:41:52 GMT

Looks Great, but where's the zip?

How do I access the Micro Focus Data Tools from within the Visual Studio IDE?

Mark_B — Wed, 01 Feb 2017 16:38:19 GMT

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:

Installation fails with Error 0x80048bc7

Fano_MF — Wed, 18 Jan 2017 13:56:09 GMT

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.

Using Code Coverage with Visual COBOL

Mark_B — Fri, 16 Dec 2016 17:46:09 GMT

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.

Java Consuming COBOL Web Service example

Chris Glazier — Thu, 15 Dec 2016 13:37:57 GMT

This file contains an example of Java consuming a COBOL Web Service.

Using CSI with Visual COBOL

Mark_B — Mon, 05 Dec 2016 18:25:49 GMT

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.

Using files defined as EXTERNAL with Visual COBOL

Mark_B — Thu, 03 Nov 2016 18:45:05 GMT

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

The FaultFinder tool appears to be missing from Visual COBOL

Dan Wright — Tue, 01 Nov 2016 14:19:12 GMT

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

Error running cesadmintool.sh: "Java not present on PATH(or wrong version)"

Dan Wright — Tue, 01 Nov 2016 14:18:33 GMT

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

Compilation error: Operand time-of-day is not declared

Dan Wright — Tue, 01 Nov 2016 14:16:40 GMT

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

An indexed file OPEN OUTPUT creates only the .dat file, not the .idx file on disk

Dan Wright — Tue, 01 Nov 2016 14:16:02 GMT

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.

Network deployment of Visual COBOL 2.3 native applications

Fano_MF — Mon, 24 Oct 2016 13:24:04 GMT

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:

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.

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 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:
COBDIR=\\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

Network deployment of Visual COBOL 2.2.1 & 2.2.2 native applications

Fano_MF — Mon, 24 Oct 2016 13:22:53 GMT

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.

Network deployment of Visual COBOL 2.2 native applications

Fano_MF — Mon, 24 Oct 2016 13:22:19 GMT

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

Re: String Handling in Managed COBOL

Ferda_Tanyeri — Sat, 15 Oct 2016 13:18:02 GMT

I was looking all over the web for the syntax:

set n to size of myString.

Thanks a lot.

Re: Working with Textboxes in Visual COBOL

Ferda_Tanyeri — Sat, 15 Oct 2016 11:17:42 GMT

Extremely useful information. Thanks a lot.

Multi-dimensional Tables: Subscript out of Range

NickCook — Tue, 11 Oct 2016 14:47:47 GMT

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 > 😎

OR (y < 1 OR > 😎

THEN

PERFORM SUBSCRIPT_RANGE_ERROR

GO TO EXIT_PARA

END_IF.

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

Fano_MF — Wed, 05 Oct 2016 13:32:24 GMT

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.

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

Peter_Kalfsbeek — Wed, 05 Oct 2016 12:17:30 GMT

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

return code of proxy is 2000 instead of 0

Peter_Kalfsbeek — Wed, 05 Oct 2016 10:02:11 GMT

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.

Re: How to extract the License Server installation from Visual Cobol 2.2

opasman — Thu, 04 Aug 2016 15:54:52 GMT

Chris,

I used IOBIT uninstaller to uninstall ED and VC, unfortunately, it did not work. It did however delete cs2010_22.exe.so I suppose the above fix will not work. I am sorry I am making this so difficult for you. Is there any way to use the registry to to delete ED and VC?not sure this is doable but I thought I would ask.

Thanks,

John

Re: How to extract the License Server installation from Visual Cobol 2.2

opasman — Thu, 04 Aug 2016 14:56:20 GMT

Chris,

I tried iobit uninstaller and unfortunately, it did not work. It did get rid of cs2010_22.exe, though. So the above solution will not work! I am sorry I am making this so difficult. Is there any way to get rid of VC and ED via the registry? The only MF items I have on my machine are the ones we're trying to get rid of and if there are more I don't use them. The only other thing is the VC 2.3 installer.

Thanks,

John

Unable to determine the status of the product license: MFCES_ERROR_SECURITY_UNCONFIRMED

KimH — Wed, 15 Jun 2016 10:08:19 GMT

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.

Setting COBCPY outside of Visual COBOL project

Mark_B — Thu, 02 Jun 2016 18:01:10 GMT

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 location and 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.

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

Re: Coming Soon... Local Variables in Managed COBOL

Austin1 — Tue, 17 May 2016 20:15:53 GMT

Just used some [paragraph-level]-scoped declared local variables today and proved to myself that the scope is the containing paragraph, as I had the same name declared within the same method but in another paragraph. Although I decided to change the name (for the developer's sake).

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

KimH — Tue, 03 May 2016 13:45:59 GMT

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.

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

KimH — Mon, 18 Apr 2016 13:24:35 GMT

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 configure CTF to capture events for RunUnits in COBOL

KimH — Mon, 18 Apr 2016 13:24:27 GMT

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

Unable to Install the MFLicenseServer on SUSE 12 SP1

ppimental — Wed, 13 Apr 2016 13:01:42 GMT

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.

Debugging Using Core Dumps

Mark_B — Fri, 08 Apr 2016 16:19:48 GMT

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

Profiling a Visual COBOL managed code application.

KimH — Thu, 07 Apr 2016 09:48:06 GMT

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 3^rd 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.

How to install Rumba after Enterprise Developer has been installed?

KimH — Thu, 07 Apr 2016 09:44:44 GMT

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,

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

Note that you may require a separate Rumba license for this option.

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

KimH — Thu, 07 Apr 2016 09:39:39 GMT

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