Rocket® COBOL

Created On:  26 October 2012 Problem: Customer used the Visual COBOL Net Express import wizard to import a number of Net Express projects that existed in the same physical folder location.  Some of the projects were .INT/GNT projects and some were .DLL projects.The DLL projects build fine and the INT/GNT projects build fine if they are built prior to any .DLL project being built.  If the INT/GNT project is build after a DLL project that resides in the same folder then the following error occurs:   "Could not copy the file "obj\\x86\\Debug\\Program1" because it was not found. Microsoft.Common.Targets line 3364. Why is this happening? Resolution: This problem is caused by using the same root folder for multiple projects that are imported where some projects are .dll projects and some are .int/.gnt.Because the projects are in the same folder they share a common obj\\x86\\debug folder which is where the build places the temporary .obj files when linking.The

Created On:  26 October 2012 Problem: I am having trouble setting up my Visual COBOL Solutions and Projects so that I can make calls from programs residing in one project to programs residing in different projects. Is there a Tutorial available which will familiarize me with the steps neccessary to do this? Resolution: Attached to this article is a tutorial called Visual COBOL CALL - CCW Tutorial.pdf. There are a number of KB articles in this tutorial, one for each type of call:1.  Native to native2.  INT/GNT to INT/GNT2.  Managed to managed3.  Native to managed4.  Managed to nativeThis article covers Native code to Managed code. Problems with Calling Programs Located in Different Projects Each project specifies an output folder into which its generated output files will be stored. The default name of this folder varies depending on the project CPU settings and which build type you are using such as DEBUG or RELEASE. The default location is

Created On:  26 October 2012 Problem: I am having trouble setting up my Visual COBOL Solutions and Projects so that I can make calls from programs residing in one project to programs residing in different projects. Is there a Tutorial available which will familiarize me with the steps neccessary to do this? Resolution: Attached to this article is a tutorial called Visual COBOL CALL - PInvoke Tutorial.pdf. There are a number of KB articles in this tutorial, one for each type of call:1.  Native to native2.  INT/GNT to INT/GNT2.  Managed to managed3.  Native to managed4.  Managed to nativeThis article covers Managed code to Native code. Problems with Calling Programs Located in Different Projects Each project specifies an output folder into which its generated output files will be stored. The default name of this folder varies depending on the project CPU settings and which build type you are using such as DEBUG or RELEASE. The default location is i

Created On:  26 October 2012 Problem: I am having trouble setting up my Visual COBOL Solutions and Projects so that I can make calls from programs residing in one project to programs residing in different projects. Is there a Tutorial available which will familiarize me with the steps neccessary to do this? Resolution: Attached to this article is a tutorial called Visual COBOL CALL - Native Tutorial.pdf.There are a number of KB articles in this tutorial, one for each type of call:1.  Native to native2.  INT/GNT to INT/GNT2.  Managed to managed3.  Native to managed4.  Managed to native This article covers Native code to Native code.Problems with Calling Programs Located in Different Projects Each project specifies an output folder into which its generated output files will be stored. The default name of this folder varies depending on the project CPU settings and which build type you are using such as DEBUG or RELEASE. The default location is in a

Created On:  08 November 2012 Problem: The main program calls by the data-item a module that is created into .DLL. This main program is generated with LITLINK . The error 173 is all times displayed . Resolution: The issue is with Net Express 5.1WS5 and has been fixed in Net Express 5.1WS6. Incident #2586639 Old KB# 36592#COBOL

Created On:  08 November 2012 Problem: A customer is converting from Net Express to Visual COBOL native and they have a manifest file that they would like to include in their .EXE.   In Net Express they use an RC file included in the project that includes their own "app.exe.manifest" file. This is needed to enable common controls V6 that they need for their UI. Here is the contents of the manifest which works successfully with Net Express builds:     This manifest isn't working with Visual COBOL.   From looking at the verbose build output it can be seen that the link command is being called with the -manifest option. This causes an app.exe.manifest to be generated. Then further down there is an mt (Manifest Tool) command to insert the generated manifest file into the app.exe file. This is likely overriding the manifest they compiled in using the .rc file.   How can they override this process to include their own manifest file into the

Created On:  12 November 2012 Problem: The Visual COBOL file handler can be configured via a configuration file.    The full details of the configuration file can be found in the Visual COBOL documentation.The purpose of this article is to discuss the behaviour of the file handler when the FOLDER tag configuration is used.The FOLDER tag has the format, for example, of:[FOLDER:C:\\\\files\\\\data]IDXFORMAT=21The documentation states that this instructs the file handler to read all files in c:\\files\\data as RM/COBOL indexed data files. Resolution: However it should be noted that this doesn't only apply to the c:\\files\\data folder but also to all sub folders too, for example c:\\files\\data\\sub1, c:\\files\\data\\sub2, c:\\files\\data\\sub1\\subZ etc.NB:  There is a known problem with the FOLDER tag option in Visual COBOL 2.1 for Unix, in that it doesn't parse the folder path correctly.   This is addressed in Visual COBOL 2.1 Hot Fi

Created On:  05 November 2012 Problem: A customer was looking for a simple method of using a key to encrypt/decrypt string fields in COBOL so that they could be used to encrypt data in a file.  Is there an example of doing this? Resolution: This is intended only to obscure a string from a casual prying eye. It is NOT intended to be a replacement for true encryption like 3DES and RSA encryption. Please do NOT assume this routine is in any way secure or uncrackable. Essentially, The code uses a variable length key to obscure the original string by iterating through the string you want obscured and adding the ASCII value of the character at each position of the original string with the ASCII value of a rotating “key character” in the key provided to generate a new ASCII value. This new ASCII value is then converted to a character and added to the newly encrypted string. The obscured string is further obscured by the fact that the original string is reversed prior to bein

Created On:  26 October 2012 Problem: I am having trouble setting up my Visual COBOL Solutions and Projects so that I can make calls from programs residing in one project to programs residing in different projects. Is there a Tutorial available which will familiarize me with the steps neccessary to do this? Resolution: Attached to this article is a tutorial called Visual COBOL CALL - INT-GNT Tutorial.pdf. There are a number of KB articles in this tutorial, one for each type of call:1.  Native to native2.  INT/GNT to INT/GNT2.  Managed to managed3.  Native to managed4.  Managed to nativeThis article covers INT/GNT code to INT/GNT code. Problems with Calling Programs Located in Different Projects Each project specifies an output folder into which its generated output files will be stored. The default name of this folder varies depending on the project CPU settings and which build type you are using such as DEBUG or RELEASE. The default lo

Created On:  26 October 2012 Problem: I am having trouble setting up my Visual COBOL Solutions and Projects so that I can make calls from programs residing in one project to programs residing in different projects. Is there a Tutorial available which will familiarize me with the steps neccessary to do this? Resolution: Attached to this article is a tutorial called Visual COBOL CALL - Managed Tutorial.pdf. There are a number of KB articles in this tutorial, one for each type of call:1.  Native to native2.  INT/GNT to INT/GNT2.  Managed to managed3.  Native to managed4.  Managed to nativeThis article covers Managed code to Managed code. Problems with Calling Programs Located in Different Projects Each project specifies an output folder into which its generated output files will be stored. The default name of this folder varies depending on the project CPU settings and which build type you are using such as DEBUG or RELEASE. The default location is

Created On:  30 October 2012 Problem: Entered: cobsje -v -J /usr/java130 Received error message: Exception in thread "main" java.lang.UnsupportedClassVersionError: WhatJavaVersion (Unsupported major.minor version 48.0) Resolution: You need a Java Runtime Environment (JRE) on any machine that is going to execute Java applications. If you are going to develop mixed Java and COBOL applications, you also need a Java Development Kit (JDK).  To add the Java support to the COBOL environment, you must run the cobsje script The cobsje script does several things including:1) Runs $JAVA_HOME/bin/java WhatJava to obtain the Java version 2) Checks that the version of Java is supported Your COBOL development system currently supports several Java versions. To find the version that is supported, read $COBDIR/docs/env.txt The UnsupportedClassVersionError will list what version of java it needs (note the example requires version 48) Major Class Versions of Java JDK--------------

Created On:  12 November 2012 Problem: Attempting to use the cursor option with the accept statement causes an error for example: accept memo-oms no beep cursor ws-memo-cursor 28207 update no beep cursor ws-memo-cursor 11-E Reserved word missing or incorrectly used Resolution: At present there are no plans to implement this functionality for either ACU or RM. The solution is not to use this syntax. Old KB# 36602#"compilererror"#ACCEPT#COBOL

Created On:  23 October 2012 Problem: Customer installed the Visual COBOL 2.1 product over an existing install of Visual COBOL 2.0.Now applications that used ACU or RM File handler previously do not run correctly as the ACUFH.DLL and other related files appear to be missing from the Visual COBOL\\bin folder.How can this be resolved? Resolution: The problem occurs because of an internal versioning number problem with the Vision file support.  The Visual COBOL 2.0 product has a version number for these files which is greater than the version number in the VC 2.1 product so they are being left out of the install.To correct this, open up Control Panel-->Programs and select Visual COBOL and choose Repair.You can also uninstall the product and then reinstall using the Visual COBOL 2.1 installer only. Old KB# 36485

Created On:  16 October 2012 Problem: One of our programs drops thru an Exit Program to the next paragraph. We are testing a new Cobol program and it is not honoring the Exit Program verb. Sample code follows:        Identification Division.       Program-Id.  LORINCE.       Data Division.       Working-Storage Section.       1   A       Pic 9.       Procedure Division.       P1.           Move 0 to A           Display ' A = ' A           If A < 3            Perform Varying A From 1 by 1 Until A > 3  &

Created On:  11 August 2012 Problem: How do I change the timeout for a COBOL Web Service client? Resolution: There are two timeout options, one for establishing the connection and another for other operations. The defaults can be overridden by setting the following environment variables: MFC_TIMEOUT MFC_CONNECT_TIMEOUT or editing mf-client.dat:[defaults] connect-timeout=15 timeout=30 These timeouts are set in seconds, but with a 5-second grain, so in effect they are rounded up to the next multiple of 5 seconds. Timeouts are set as follows: If the application calls MccSetTimeout / MccSetConnectTimeout on a context, that context will use the specified timeout values. Otherwise, if MFC_TIMEOUT / MFC_CONNECT_TIMEOUT is set in the environment, its value will be used. Otherwise, if a "[defaults]" section exists in mf-client.dat and it contains an entry for "timeout" / "connect-timeout", that value will be used. Otherwise, the built-in defaults of 15s for connect timeout and 30s

Created On:  11 October 2012 Problem: Customer has Visual COBOL solution that was building fine.  A change was made to one of the compiler directives in the project properties COBOL tab.Now when attempting to rebuild the solution they get the following error:Unhandled Exception: Could not load file or assembly"BadImageFormatException"attempt was made to load a program with an incorrect format.Why is this happening now? Resolution: This error usually happens if the Platform target type gets changed from Any CPU or x86 to x64 or vice versa. There is a problem when editing a property page in that if you are not in a particular field and you scroll the mouse it may change the value of the Platform target field.Check to ensure that the Platform target field is set to the correct type in all of your projects. Old KB# 36435

Created On:  25 October 2012 Problem: Using AcuConnect Thin Client 9.1.2, whenever the load of the traffic increases, acuthin crashes with the following message:"Communication socket closed unexpectedly".The issue occurs even running acurcl and acuthin on the same machine.  It is not present with previous 9.1.x versions. Resolution: When large amounts of data were transferred from the thin client to the application host, or vice versa, the socket could fill, causing an error in the function used to send data. This could cause the socket to close unexpectedly, forcing a disconnect.This is now been fixed in version 9.1.2.1, soon available for download.  Check the Product Updates page of SupportLine Web Site. Incidents #2596321, 2596329 Old KB# 36504#COBOL

Created On:  22 October 2012 Problem: By default, Xcentrisity BIS uses the lowercase form of the COBOL names from the --Method-Parameters data group in WORKING-STORAGE in order to generate the external SOAP web service method and parameter names.  However, it is possible to change the default, external, method and parameter without changing the COBOL WORKING-STORAGE names. Resolution: In order to define alternate names for web service's methods and parameters you will need to use an XSLT stylesheet, along with an XML conversion dictionary, that convert the original names to the new ones that you wish to implement.  The spelling dictionary is a simple XML document that can be edited by hand.  It contains entries that define the "cobName", internal COBOL data name, and the "publicName", the external SOAP element ,or method, name. Attached to this Knowledge Base Article is a zip archive containing modified XBIS SOAP stylesheets that enable the use of a dictiona

Created On:  17 October 2012 Problem: It is possible to call Cobol sub programs but in Eclipse but am not aware of how this can be done. In Visual Studio you can set the output folder for the .exe and/or Dlls from any project to the same folder so e.g. ProgramA will find ProgramB.  But under Eclipse this can´t be done, the output folder needs to be under the Project the source is created in. Resolution: Please do the following to resolve this issue:•         In your calling project (ie the one built to an exe which calls the others), right click and bring up the project properties. •         Open the ‘Micro Focus COBOL’ section•         Click on the ‘’Build Path’ item to see the build settings•         Select the tab called ‘Projects’•         Now click the ‘Add...’ b

Created On:  19 October 2012 Problem: During installation of Visual COBOL the following error is observed:                    Micro Focus Product - Standalone Installer                               www.microfocus.com pax: VisualCOBOL2.1/visualcobol_devhub_2.1.pax : No such file or directory Resolution: This problem is likely to be caused by a space problem on filesystem containing the current working directory or the installation destination directory which is /opt/microfocus/VisualCOBOL by default but can be overridden using the -installlocation option. Incident #2596802 Old KB# 36463

Created On:  22 October 2012 Problem: Customer is converting an application from Net Express 5.1 to Visual COBOL 2.1 but they still need to maintain their existing Net Express application.  Both Net Express and Visual COBOL products are installed on the same development computer.Each version of the application must maintain its own set of sources and copybook files in separate folders.How can the environments be setup so that the COBCPY environment variable points to the correct copybook folder for the product being used? Resolution: You can set COBCPY and other environment variables in the computer's environment to point to the default Net Express folders.You can then create a .bat file that is executed to start Visual COBOL that will set the desired environment variables prior to starting the Visual Studio IDE. Setting COBCPY in a .bat file prior to executing devenv.exe will override the value set in the control panel as long as you don't include the %COBCPY% as part

Created On:  24 October 2012 Problem: This article discusses the "database failure" error when running $COBDIR/lmf/lmfinstallYou have recovered a corrupt LMF database using the install script:  $COBDIR/lmf/lmfinstall.Your COBOL version is prior to Server Express 2.2 Service Pack 2. Restarting licensing fails with a message: “License Key database is empty”.You attempt to install licenses into the empty database and receive the message: "database failure". Resolution: The problem is that directory $COBDIR/lmf contains database files (mflmfdb, mflmfdb.idx, mflmfdbX, mflmfdbX.idx). These database files do not belong in $COBDIR/lmf and must be removed.The lmfinstall script allows the user to create an empty database in a directory of their choosing (the default is a directory called mflmf).If the user attempts to install into $COBDIR/lmf (install over itself) then it will fail but it still create the database filesThen when the user reruns the script to create a database in

Created On:  22 October 2012 Problem: InstantSQL requires that an ODBC Driver Manager be available, however, most Unix distributions do not come, by default, with one installed. Resolution: There are two different ODBC Driver Managers that are supported on Unix.  Below are instructions for setting up your UNIX environment for use with InstantSQL and the two different ODBC driver managers: iODBC Driver Manager: 1. Obtain iODBC Driver Manager from http://www.iodbc.org. Follow the instructions at the site to build and/or install the package. 2. Set your OS's library search path to include the directory containing the iODBC Driver Manager libraries(iodbc_lib_path): • IBM AIX - export LIBPATH=$LIBPATH:iodbc_lib_path• HP-UX - export SHLIB_PATH=$SHLIB_PATH:iodbc_lib_path• Intel UNIX System V Release 4, Linux, SCO OpenServer 5, SCO System V Release 5 (UnixWare 7.1.1 or later and SCO OpenServer 6), and Sun Solaris SPARC and Intel x86 - LD_LIBRARY_PATH=$LD_LIBRARY_PATH:iodb

Created On:  19 October 2012 Problem: When a Visual COBOL installation fails, is there any way to get more information on what the installer was doing? Resolution: There are a number of ways to get more information on what the installer is doing and finely control the installation process.  All of these options can be found if you use the -mfhelp flag.  Most of these options are for internal Micro Focus testing, however several, such as -extractonly, can be useful for diagnosing installation issues.Depending on where in the installation process the error has occurred you should see a log file in the current directoy.  The log file may also appear in /tmp or /opt/microfocus/logs.  Examining the log file should help diagnose the cause of the problem and should be submitted to Customer Care if reporting an installation problem.Also, it is possible to manually install the product.  Splitting the install into different steps will allow you to see exactly

Created On:  23 October 2012 Problem: Fileshare has been installed as a Windows service using the command fsservice -i.Although the Fileshare service was set to Automatic with Server for COBOL 4.0/5.0/5.1 or COBOL Server 1.0/2.0/2.1, the service is not started after reboot.Event Viewer reports the following two errors:"A timeout was reached (30000 milliseconds) while waiting for the Micro Focus Fileshare Service service to connect." "The Micro Focus Fileshare Service service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion." Resolution: This problem occurs when Fileshare is started as a service while the CCITCP2 daemon is not running.The CCITCP2 daemon has to be installed as a service and has to be started before starting the Fileshare service. Here are the steps to set up the Fileshare service properly:1. open a Command Prompt session that is run as administrator (i.e. right-click on the C