License files are by default created in /tmp directory, how to change this?

September 26, 2018, 7:44 am

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

≪ Previous: Visual COBOL for Eclipse 3.0 on Windows Server 2016

Current Revision posted to Visual COBOL Knowledge Base by Peter.Kalfsbeek on 9/26/2018 9:44:30 AM

Problem:

When someone clears up the /tmp directory 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. You can relocate this file by setting socketdir (e.g. socketdir=/var/microfocuslicensing/socket) in ces.ini (needs version 10000.2.02090 or later and you’ll need to create the folder with 666 permissions ). NOTE: The file is abstract on Linux systems so you shouldn’t have an 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. Having the file go missing is less important especially if you are aware this may cause issues with starting/stopping mfcesd.

↧

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

September 26, 2018, 7:59 am

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

≪ Previous: License files are by default created in /tmp directory, how to change this?

Current Revision posted to Visual COBOL Knowledge Base by Peter.Kalfsbeek on 9/26/2018 9:59:53 AM

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

Resolution:

This is a wrong message displayed by the installed 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.

↧

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

October 4, 2018, 5:45 pm

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

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

Revision 1 posted to Visual COBOL Knowledge Base by blairm on 10/4/2018 7:45:39 PM

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

0 GA
0 Patch Update 1
0 Patch Update 2
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 Patch Update 5 or more is being upgraded to.

Workaround:

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

Tags: visual cobol, rpm, install

↧

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

October 5, 2018, 7:09 pm

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

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

Revision 2 posted to Visual COBOL Knowledge Base by blairm on 10/5/2018 9:09:47 PM

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 you can 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 fonts in xterm.

Tags: visual cobol, Eclipse, Debugging, ViewNow

↧

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

October 9, 2018, 12:40 pm

≫ Next: Securing access to the Enterprise Server Web Administration ConsoleX

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

Current Revision posted to Visual COBOL Knowledge Base by Fano_MF on 10/9/2018 2:40:01 PM

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 Servernameis the name or IP address of the server and MicroFocusSrvis the network share name on the COBOL Server 4.0 installation folder.

↧

Securing access to the Enterprise Server Web Administration ConsoleX

October 9, 2018, 5:00 pm

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

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

Revision 2 posted to Visual COBOL Knowledge Base by blairm on 10/9/2018 7:00:38 PM

Problem

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

Solution

Follow these steps to secure 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 immediate 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, and this is recommended. 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.

↧

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

November 16, 2018, 10:58 am

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

≪ Previous: Securing access to the Enterprise Server Web Administration ConsoleX

Current Revision posted to Visual COBOL Knowledge Base by PhillR on 11/16/2018 12:58:15 PM

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.

↧

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

November 16, 2018, 11:00 am

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

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

Current Revision posted to Visual COBOL Knowledge Base by PhillR on 11/16/2018 1:00:51 PM

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.

↧

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

October 9, 2018, 12:02 am

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

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

Revision 7 posted to Visual COBOL Knowledge Base by Kim.Hoskin on 10/9/2018 7:02:27 AM

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 ()"

↧

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

November 13, 2018, 2:22 am

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

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

Revision 7 posted to Visual COBOL Knowledge Base by Kim.Hoskin on 11/13/2018 10:22:33 AM

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.

↧

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

November 13, 2018, 2:25 am

≫ Next: Network deployment of Visual COBOL 2.3 native applications

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

Revision 5 posted to Visual COBOL Knowledge Base by Kim.Hoskin on 11/13/2018 10:25:33 AM

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 if you are 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 you can consider upgrading Eclipse from version 4.6.0 to version 4.6.3 where handling of monitors with high DPI is improved.

↧

Network deployment of Visual COBOL 2.3 native applications

January 17, 2019, 1:38 pm

≫ Next: Patch Update uninstall reboots system

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

Current Revision posted to Visual COBOL Knowledge Base by Fano_MF on 1/17/2019 9:38:00 PM

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

↧

Patch Update uninstall reboots system

January 21, 2019, 6:34 am

≫ Next: Which port does the Micro Focus License Server use?

≪ Previous: Network deployment of Visual COBOL 2.3 native applications

Revision 1 posted to Visual COBOL Knowledge Base by raquelc on 1/21/2019 2:34:43 PM

Reported:

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

Solution:

Up to Visual Cobol / Cobol Server 4.0, it is unavoidable the system reboot after the silent uninstallation of a Patch Update. This issue will be addressed from version 5.0.

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

Tags: COBOL server, visual cobol, silent

↧

Which port does the Micro Focus License Server use?

January 30, 2019, 3:05 pm

≪ Previous: Patch Update uninstall reboots system

Current Revision posted to Visual COBOL Knowledge Base by AlexCr on 1/30/2019 11:05:41 PM

Created On: 22 March 2012

Problem:

Which port does the Micro Focus License Server use when a client requests a license using the License Administration on their PC?

A customer needs to open up the port on their firewall as currently they have access blocked when requesting a new key.

Resolution:

The default port is 5093.

Old KB# 35676

↧