Rocket® COBOL

Created On:  10 January 2012 Problem: It appears that the Acu XDBC 64bit server can be selected when doing a Windows install, but the modules do not get copied onto the machine. Resolution: AcuXDBC does get installed on the machine, but gets installed into the default location of "C:\\Program Files\\Micro Focus\\Acucbl910\\AcuGT\\bin\\". If you want the files in another location there are five steps you need to perform to be able to use 64-bit AcuXDBC from the new location. The steps require that you have administrator rights to the local machine. 1. Copy the files from "C:\\Program Files\\Micro Focus\\Acucbl910\\AcuGT\\bin\\" to .2. Set GENESIS_HOME= .3. Change the properties of XDBC Query 64-bit shortcut so the target now points to .4. Run regedit and locate the HKEY_LOCAL_MACHINE\\SOFTWARE\\ODBC\\ODBCINST.INI\\extend9 AcuXDBC (64-bit) entry. The Driver and Setup keys need to be changed to the following: Driver=\\bin\\acuxdbc.dllSetup=\\bin\\AcuXDBCSet

Created On:  17 October 2011 Problem: While running AcuXDBC you get an error message, for example: Too many columns 369 (max:256) Resolution: You can increase this limit by modifying the DSN that was created for the AcuXDBC data source. See Chapter 5.8.3 AcuXDBC Setup: Advanced Tab of the AcuXDBC User's Guide for more information: Here are some limits to be aware of that are imposed by Microsoft: Excel: Worksheet size 65,536 rows by 256 columns column width 255 characters. Access: Number of fields in a table 255 Old KB# 34945#ToomanyColumns#AcuXDBC

Created On:  17 October 2011 Problem: How do you find in Acu4GL for MSSQL the unique SQL spid (process id)? Resolution: You can view the SPID in MSSQL using Activity Monitor etc or try using the function below.ACUCOBOL-GT Appendices Version 9.0.1 Appendix I: Library Routines > I.1 General Syntax and Library List > C$GETPID This routine returns the Process ID (PID) of the current process. This PID can be compared with the PID returned by the C$LOCKPID to determine if the current process is the one holding a file lock or record locked condition. Usage CALL "C$GETPID" GIVING PROCESS-ID. Parameters PROCESS-ID PIC 9(n) This contains a numeric data item large enough to hold a PID. On most platforms, PIC 9(5) is sufficient. On 64-bit systems, PIC 9(7) is recommended. Comments When called from a non-UNIX or non-Windows runtime, C$GETPID returns a PROCESS-ID of "0". This behavior should not be used for system identification. Use ACCEPT ... FROM SYSTEM-INFO

Created On:  18 October 2011 Problem: For Visual COBOL R4 Update 2 and R5 a new version (8.4) of the SafeNet licensing software will be used.  For local servers there is nothing to worry about as we will be installing a new client (Visual COBOL) and a new server on the same machine.  However, if you have a network server you should update that first as new clients (on 8.4) cannot talk to old license servers (on 8.2). Resolution: The new version of the license server software should be available for download nearer the time from the SupportLine web site at: http://supportline.microfocus.com/websync/SLM.aspx. Old KB# 34956#COBOL

Created On:  19 October 2011 Problem: When testing the record lock behavior in a Visual COBOL application that is accessing RM/COBOL indexed files, I find that the behavior is different than that of RM/COBOL.  In RM/COBOL when I try to access a record that is currently locked by another program, the read will wait until the lock is released before returning to the program.In Visual COBOL accessing a locked record returns immediately with a locked record file status.  How can I change this behavior? Resolution: You can change this behavior so that it works like the default RM/COBOL behavior by using the RM directive in addition to the CALLFH("ACUFH") directive to compile the program.  Then if a locked record is attempted to be read in a second program it will automatically wait until the record is released by the program holding the lock.You can also use the RETRYLOCK directive instead of the RM directive

Created On:  21 October 2011 Problem: After the installation of runtime 9.1.0, no bitmap or jpeg image is displayed inside the application.  W$BITMAP returns an invalid handle. Resolution: This is caused by the lack of the correct library inside extend setup 9.1.0 for Windows 32-bit.  Either copy the missing library ajpg32.dll from an existent 9.0.1 installation, or extract the attached zip file into the newly installed 9.1.0 BIN directory. Incidents #2542782, #2542215 Attachments ajpg32-901-32bit.zip Old KB# 34988

Created On:  07 October 2011 Problem: Calling the RM/COBOL subroutine, C$Century, in Visual COBOL (R4) does not return a value to the USING argument. Resolution: The following compiler directive has to be set in order to enable the C$Century call to return a value:RM "GIVING" Incident #2540577 Old KB# 34860#VisualCOBOL#RMCOBOL#Enterprise#COBOL

Created On:  11 October 2011 Problem: How do you access windows printers from UNIX? Resolution: When we print on UNIX, we send the data to a device on UNIX and it is UNIX that does the printing. We send the printing to lp and it prints it.To make this work you need to set up the UNIX machine and the Windows machine, and once you are able to print from the command line on UNIX, you will be able to print from our runtime. The problem is a system issue and nothing to do with the runtime.Here is a link that talks about the configuration you need to setup:   http://support.microsoft.com/kb/324078 Old KB# 34898#AcuCobolPrinters

Created On:  11 October 2011 Problem: I am having problems clarifying the results from the Profiler. Resolution: The ACUCOBOL-GT profiler is a sampling profiler, which means that it wakes up at regular intervals, and attempts to figure out what is executing at that moment. As such, the numbers reported are very rough estimates. And we have found that paragraphs with only CALL statements are not particularily good for such sampling.ECN 3441 offers more information about profiling, in particular a configuration variable that may allow more accurate profiling in some situations. SUBJECT: Profiling COBOL on WindowsChange Number: ECN-3441Status: CompleteType of Change: EnhancementPriority: MediumIncidents: NoneDate: 2006-04-05Product: ACUCOBOL-GTModule: runtimeNew Version: 8.0.0Machines Affected: WindowsKnown Versions Affected: All with profilingDESCRIPTION of problem or enhancement:The method we used to set a periodic timer on Windows (in order to profile COBOL progra

Created On:  11 Ocrober 2011 Problem: We installed Net Express 5.1 on a Windows 7 computer.  When clicking a screenset file with extension .gs in the IDE the following error occurs:Load error: file 'dspaint' error code:173, pc=0, call=1, seg=0 173 Called program file not found in drive/directoryA similar error occurs when trying to run a Dialog System application in the IDE on the call to DSGRUN. Resolution: This is a known issue with Net Express 5.1 and Windows 7.On Windows 7 the quotes that are placed around the PATH settings in the Net Express or Server for COBOL 5.1 registry settings is causing the PATH to be invalid so the search for DSGRUN and DSPAINT fails.The workaround is to remove the quotes from the PATH settings using regedit.There are two locations that need to be modified.The key names will depend on if this is Windows 7 32-bit or 64-bit.--------------------------------------------The fix for this is to make a few registry changes to handle t

Created On:  10 October 2011 Problem: From v9.0 onwards there is no requirement to link the Runtime System in Acu4GL for Oracle. Resolution: It will pick up the file automatically (making life MUCH easier). You need to check to see if the files required by Acu4GL/Oracle are present. You can do this with the command: "ldd coba4ora64.so" for example or "ldd coba4ora32.so" in the 32 bit environment.Example machine, check the following: /lib directory > export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH /lib directory> ls *ora* coba4ora64.so Makefile.ora /lib directory> ldd coba4ora64.so libfsi264.so => ./libfsi264.so (0x00002b410d66e000) libaxml64.so => ./libaxml64.so (0x00002b410d788000) libacvt64.so => ./libacvt64.so (0x00002b410d8c9000) libaregex64.so => ./libaregex64.so (0x00002b410d9dd000) libvision64.so => ./libvision64.so (0x00002b410dadf000) libacme64.so => ./libacme64.so (0x00002b410dc22000) libcobacme64.so => ./libcobacme64.so (0x00002b4

Created On:  07 October 2011 Problem: When running the runtime product Server for COBOL or Server Enterprise Edition the Micro Focus License Manager does not appear to want to start again.  When attempting to restart the Micro Focus License Manager service via the Control Panel, the following message is returned:"The Micro Focus License Manager on local computer started and then stopped. Some services stop automatically if they are not in use by other services or programs" Resolution: The message is coming from mflmwin (Micro Focus License Manager). For some strange reason the machine gets into a state where the License Manager will not start. Due to the anti-hack code in the License Manager the only solution is to restart the machine in order to clear the processes and shared memory. Incident #2540805 Old KB# 34862#Enterprise#COBOL

Created On:  06 October 2011 Problem: How do I tell what exact version or update level of Visual COBOL is installed? Resolution: You can look in two locations under Windows.  Open Visual Studio 2010 and Sekect Help > About Microsoft Visual Studio.1.3.00046 indicates base release of Visual COBOL R4.1.3.00047 indicates R4 Update 1 release of Visual COBOL.You can also look in Control Panel > Programs.  Click on View Installed Updates link to see what Update level your product is at: Old KB# 34850

Created On:  04 October 2011 Problem: When you attempt to uninstall a product in “Programs and Features” a new “Windows Installer” window appears and gives the following error: "Error opening installation log file. Verify that the specified location exists and is writable.”This is related to Windows 7 Professional. Resolution: This can occur if Windows Installer Logging is enabled, but the Windows Installer engine cannot properly write the uninstallation log file. This condition can occur if the Windows Installer's application heap becomes freed and thus loses the information on where to store the log file. When this occurs, Windows Installer attempts to write to the location 'C:\\Windows\\System32' and addresses it as a file. Proper behavior would be to write to the following location and file name: 'C:\\Users\\\\AppData\\Local\\Temp\\MSIxxxxxx.log'. To work around this issue, stop and restart the Explorer.exe process using Task

Created On:  21 September 2011 Problem: When using Visual COBOL R4 to create a Windows Presentation Foundation (WPF) project, the COBOL tab on the project properties shows as blank. Resolution: It appears that this problem is a known issue in R4 that has been fixed in subsequent releases. For R4 the workaround is as follows: Create a WPF application and then change the output type on the Application tab of the project properties page from Windows Application to Console Application and back again. After saving and reloading the project the COBOL tab should be accessible. Old KB# 34763

Created On:  29 September 2011 Problem: In the product documentation under Database Access the STMTCACHE directive is defined as follows:STMTCACHESets the cache size for prepared statements used by OpenESQL. The default is 20. Depending upon your application and data source, performance improvements or data errors can result if this value is set higher than that.  What exactly does this mean?  What does the value of this setting actually refer to? Resolution: The setting of STMTCACHE refers to the number of prepared statements that the runtime will keep alive. The cache is managed on a least recently used basis. A statement can be recycled if it is not an open cursor. At one time we had problems with Oracle running out of resources so we introduced STMTCACHE to restrict the amount of server resources a client app could tie up. OpenESQL always uses prepare execute rather than direct execution so that any statement executed multiple times will execute faster on the

Created On:  04 October 2011 Problem: Executing the Runtime after installing an amendment license causes the following error message to be displayed: Use count exceeded (Loc 520) - Use count mismatch on local machine Resolution: This error can occur if you install an amendment license that adds use count while users are actively executing the Runtime.   The resolution is to either have all users terminate their Runtime sessions, or, reboot the server machine.The amended usage count will take effect after all users have terminated their Runtimes, or, the server machine restarts. Incident #2511568 Old KB# 34812

Created On:  23 September 2011 Problem: During installation of Net Express 5.1 on a Windows Server 2003 machine, a window appeared and displayed the following message:"Error 2878. On the dialog PreReqs the control PreReqList has a possible value: Either Microsoft Windows XP Service Pack 1 or Later, Microsoft Windows 2000 Service Pack 4 or later, Microsoft Windows NT 4.0 Service Pack 6 or later, Microsoft Windows 2003...."The Net Express Installation is aborted after the OK button was clicked. Resolution: The following are the steps to get over the Microsoft Windows pre-requisite check in installation of Net Express 5.11. Open a command line prompt2  Change directory to the Net Express installation3. Run the NX installation file with the following parameters: INSTALLATION file name, e.g. nxp3251000157.exe  /V"CHECKPREREQLIST=" Incident #2529757 Old KB# 34768

Created On:  19 September 2011 Problem: When migrating programs precompiled with Oracle's Pro*COBOL preprocessor to OpenESQL there is an error reported on the following statement when it is in the working-storage section of the program.     EXEC SQL VAR TESTVAR IS VARCHAR2 END-EXECThe error reported by OpenESQL is:     "ES0114 Statement only allowed in the PROCEDURE DIVISION." If the statement is moved to the procedure division then OpenESQL does not display the error message.  Why is this happening? Resolution: The problem is that this is an Oracle Pro*COBOL extension and it is not supported in OpenESQL either in the working-storage section or in the procedure division.  The reason you see the error is because OpenESQL tries to be very flexible in what it allows since it is designed to work with just about any data source and it only recognizes as much SQL syntax as it has to. The preprocessor determines

Created On:  09 September 2011 Problem: When adding ActiveX Components to a .NET Windows Form in Visual COBOL, it builds correctly but when attempting to run the application an error like the following is displayed:Why is this? Resolution: The problem manifests itself in two ways.Most ActiveX controls are 32-bit so if your project is set to x64 or anyCPU and you are running on a 64-bit OS then this will fail.If you set the project type to x86 or are using anyCPU on a 32-bit system then it should work as long as you also set the Copy Local property to True on the references that are added to your project by the IDE. Incident #2536071 Old KB# 34732

Created On:  19 August 2011 Problem: When compiling a program after an upgrade the error "Bad magic number for shared library" is obtained. Everything seems to be in order. For instance, the system is 64-bit, the cobmode setting is 64-bit, and the library being referenced is 64-bit. The database is an Oracle database and it is also 64-bit. Resolution: In this case check the procob executable (it may be on a client system) to see which format (32-bit or 64-bit) it is. To find this on a UNIX or Linux system, execute:    file procobThe file format will be returned telling you if the procob executable is 64-bit (explicitly stated) or 32-bit (won't explicitly state 64-bit). If you are using 64-bit and the procob executable is not 64-bit, obtain the 64-bit procob executable (Oracle may have to be contacted for that). Incident #2523812 Old KB# 34342

Created On:  19 August 2011 Problem: During compilation of a COBOL program which utilizes embedded SQL to access an ODBC-enabled data source, the following error message is received:* 801-S**    External Compiler Module message**    CE0001 odbcecm or dependant module not found Resolution: This is an indication that you do not have a product release which supports the loaded ODBC drivers. For instance, you might have 64-bit ODBC drivers but the installed Micro Focus product and release only supports 32-bit ODBC drivers.It is also possible that your environment is not set up correctly to take advantage of the ODBC drivers (for instance the library paths are not set correctly). The ODBC library directory should be listed in the LD_LIBRARY_PATH.  Verify that the correct libraries are being picked up (and not being pre-empted by other libraries). 64-bit ODBC support on UNIX was added beginning with Server Express 5.1 WS

Created On:  30 August 2011 Problem: When executing cob –V the following error is returned: $ Specified in column 7 of otherwise blank linePRN=RXCAY/AAI:9p.Z5.51.07 PTI=WrapPack 6 PTI=ES BASIS line number sequencing erroretpglwg:/opt/microfocus/sx51sp6/bin # Resolution: The environment variables COBDIR, LD_LIBRARY_PATH/LIBPATH and PATH are set correctly. Even though you have this issue, compiling a COBOL program using correct parameters for the cob command does work correctly. This issue was correct by deleting the contents of $COBDIR and reinstall the product. Incident #2527432 Old KB# 34360#cobcobver

Created On:  30 August 2011 Problem: When executing cob –V the following error is returned: cob32: Can't open message file '/opt/microfocus/sx51wp6/lang/default/cob.lng' Resolution: This error is normally due to the environment variables not set correctly. Make sure you have COBDIR, LD_LIBRARY_PATH/LIBPATH and PATH environment variables are set properly. If the environment variable are set correctly, then remove the contents of $COBDIR and reinstall the product. Incident #2527432 Old KB# 34359#cobcob.lngcob32cob64

Created On:  20 September 2011 Problem: We are getting the error "\\Micro was unexpected at this time" when using version 9.0.1 AcuXDBC batch files on 64-bit Windows. Resolution: The AcuXDBC installation includes eight batch files to assist in administering:acuxdbcs.bataddfile.batainit.batasql.bataxset.batdemo.batgenxconf.batodbcsql.batInvoking them on a Windows 64-bit machine results in the error:"\\Micro was unexpected at this time"The same .bat files all work as expected on 32-bit Windows.Explanation/Resolution:The batch files did not account for the fact that 64-bit Windows have parentheses in the path.  Those parentheses cause problems for the DOS batch processor.Attached to this article is a zip file containing modified batch files that work on 64-bit machines.  Simply download and extract to the bin directory of your 9.0.1 installation.  By default that is C:\\Program Files (x86)\\Micro Focus\\Acucbl901\\AcuGT\\bin.The same applies