Browse all forums dedicated to the Rocket® COBOL product family.
Recently active
This document describes how to send the "at sign" to the Rumba emulator from a script. Problem: When sending the "@" character to the Rumba display from a script, the character does not appear on the display as expected. How can this be done? Resolution: There are times when it may be desirable to send the "@" character to the Rumba display from a script. For example, if an email address needs to be inserted into a field. One might expect to call EMSendKeys to perform this task as follows: EMSendKeys "User@mydomain.com" This script doesn’t work as expected, because the "@" sign is interpreted as an escape sequence to introduce 3270 keyboard mnemonics. To properly send the "@" character, it must be doubled as shown here: EMSendKeys "User@@mydomain.com" This will result in the expected string being sent to the display: User@mydomain.com. Old KB# 14420#Rumba
The maximum number of tabs/sessions allowed in RUMBA Notebook. Problem: What is the maximum number of RUMBA printer sessions allowed in RUMBA Notebook? Resolution: The RUMBA Notebook is a program that allows users to run a number of applications at the same time. These applications may include different components of the same version of RUMBA software and Windows applications such as Microsoft Excel and Microsoft Word. Each application or RUMBA window is run in a separate tab of the Notebook. There is no hard coded limit on the number of tabs that can be opened in the notebook session. It depends on the size of the memory of the workstation that RUMBA notebook is running on. Incident Number: 2279305 Old KB# 14430#Rumba
This article describes how to overcome the following error produced by the rebuild command: “***Error during sort operation - status 9-037”. Problem: While rebuilding data files with the ‘rebuild’ command, the following error appears: “***Error during sort operation - status 9-037”. What is it and how can it be resolved? Resolution: File status 9-037 indicates a permission problem. It means rebuild does not have permission to create a particular file. Check that the user has write permissions on the output file specified on the "rebuild" command. The rebuild command also creates temporary work files while it runs. By default it tries to create these temporary files in the current directory, so the user must have write permissions in the current directory. If the TMPDIR environment variable is set, rebuild will create its temporary files there, so the user must have write permissions there. In one historical case, an en
How to capture network packets using WireShark. Problem: In order to troubleshoot certain types of issues, it may be necessary to take a network trace. Also known as a 'sniffer trace', this captures all communication to and from the workstation, providing a low-level view of network traffic. Resolution: To take a network trace using WireShark: Install the WireShark network sniffer. WireShark can be downloaded from http://www.wireshark.org/download.html When the installation completes, start WireShark. Select Capture > Interfaces from the menu. Click the Options button for the desired interface. Configure the capture options: Capture packets in promiscuous mode. This option allows for the capture of packets with destinations other than the workstation where WireShark is running. Normally, this should be left checked. Limit each packet to. This option should be left unchecked to allow all packet data to be captured. Capture Filter. This
This article explains how to invoke a UNIX command from within COBOL using CALL “SYSTEM” and retrieve the return code of the command. Problem: Micro Focus Server Express and Visual COBOL provide a way for UNIX commands to be invoked from within COBOL. This is done by calling a routine named SYSTEM. Individual UNIX commands such as "ls" or "pwd" can be invoked, or entire shell scripts or executable programs can be invoked. How can the return code from the UNIX command be retrieved and communicated back to COBOL? Resolution: Here is an example of the COBOL syntax for invoking a UNIX command: CALL "SYSTEM" USING CMD-LINE. "SYSTEM" (uppercase) preserves the COBOL screen and state of the terminal, then calls the UNIX system() routine (lowercase), then afterwards restores the COBOL screen and terminal. For more information about "system", see the system(3) man page. It is possible to call "system" (lower
Read-only entry fields no longer change background/foreground colors with 8.1.0. They are shown only in gray. Problem: Read-only Entry Fields used to allow their foreground or background colors to be modified. The Runtime version 8.1.0 stops this behavior, and leaves the read-only field gray. Resolution: This change was made to follow Windows standards and was implemented with ECN-3699 released in 8.1.0. You can turn this behavior off so that your applications will not be affected by this change. Set the following configuration variable in cblconfi: ECN-3699 0 The value "0" turns the ECN off, value "1" activates the ECN and entry-fields remain gray. This configuration variable has been introduced in ECN-3848, available in the future release of ACUCOBOL-GT 9.0. Incident Number: 2131301 Old KB# 14428
This article explains why the ViewNow X server does not honor the –geometry parameter when starting X clients. Problem: When X clients are started with the –geometry parameter, ViewNow X server doesn’t honor the position information given. Why is this? Resolution: In ViewNow X, the –geometry flag is overridden by settings in the server which are intended to prevent windows from inadvertently obscuring each other. These settings can be changed to prevent this behavior by performing the following steps: Launch the ViewNow X control panel. From the Start menu, go to Start > Programs > ViewNow > X Windows > Control Panel. Alternatively, launch \\Program Files\\NetManage\\APPS\\X\\CPanel.exe from the command line. From the Options menu, select “Window…” On the Window Management dialog, uncheck the “Cascade Windows” option. Click OK to dismiss the dialog. Re-launch the ViewNow XServer. Subsequent invocations of X clients with the –geometry parameter present will now appe
This article explains why a 211 error occurs when trying to run a program that was ported from another server. Problem: When I was trying to run a program that was ported from another server, a 211 error occurs. Specifically, the message received was a load error 211 pc=0, call=1, seg=20 211 program not executable by runtime system. Why is this happening? Resolution: The reason this error is occurring is because the program is 64 bit and was ported over from another system to one whose Server Express product and/or hardware is 32 bit only. This problem can occur on AIX systems with Server Express prior to version 4.0SP2. The 32 and 64 bit versions for AIX were separate products until version 4.0SP2 was released. If a program is compiled with the 64 bit product on an AIX system and run with COBDIR, PATH, and LIBPATH set for the 32 bit product, error 211 will occur. The same is true for 64 bit code ported to any AIX 4.3.3 system. That version of AIX is 32 bit only. A few
This article provides instructions for removing Server Express from a machine, while leaving an installation of Server for COBOL in place. Problem: Background information: Micro Focus COBOL for UNIX is distributed as two individual products. For clarity, this article will refer to them as the "development" product and the "runtime" product.The development product is officially named "Server Express". It includes the entire product offering: the compiler and development tools (including Animator), and also the runtime system and its supporting libraries and files.The runtime product is officially named “Server for COBOL" (or in older versions, "Application Server for Server Express"). This is a sub-set of the development product. It includes only the runtime system and supporting libraries and files; it does not include the COBOL compiler or Animator. The runtime product is meant to be installed on a machine on which there is no need to c
This article describes how to get information about the Operating System when an ACUCOBOL-GT runtime is executed on a Linux server Problem: How to get information about the Operating System when an ACUCUBOL-GT runtime is executed on a Linux server. Resolution: Usually, you can use ACCEPT from SYSTEM-INFO on Windows environments, but this returns only "Unix" when the server is non-Windows. To get more information from a Linux server, use code like this: identification division.program-id. prog.author.remarks. environment division.input-output section.file-control. select myfile assign to "-p uname -a" organization line sequential file status fs. data division.file section.fd myfile.01 rec pic x(50). working-storage section.01 key-pressed pic 9(4) is special-names crt status.01 fs pic xx.procedure division.main-logic. open input myfile read myfile next at end continue end-read display rec accept omitted
This article explains how to find the line of code that matches the PC to an RTS error. Problem: When running a program, the following RTS error occurs and we would like to know how to find out the source line from pc=2007. Execution error : file 'mr01.int' error code: 166, pc=2007, call=218, seg=0 166 Recursive COBOL CALL is illegal Resolution: To find the line of code at address 2007, compile your program with -C REF and -C LIST"". Object COBOL Development Suite (OCDS) will put the addresses against the source lines, whereas Server Express will put a table of lines and addresses at the end of the listing. Note: This facility is not avaliable in some early versions of Server Express. Here's another example: Execution error : file '/home2/support/juj/tmp/mydem.int' error code: 153, pc=3D, call=1, seg=0 153 Subscript out of range tsron:/home2/support/juj/tmp > cob -C'ref list""' mydem.cbl t
This article describes what to do if command-line arguments are supplied to a program with parentheses "()" instead of "=". Problem: When executing the following command: cobrun program file=myfile output=outputfile when the arguments are retrieved in the COBOL application, the “=” character is removed and the argument is bracketed with “()” parentheses, like this: file(myfile) output(outputfile) Resolution: The replacement of the “=” characer by parentheses occurs because of the parsing of the command by the cobrun command. If the application is built as a standalone executable, this parsing of the command-line arguments does not occur, and the values retrieved by the COBOL program are exactly as entered on the command line. To retrieve arguments without the parentheses, use the command: Cobrun program file==myfile output==outputfile. A program to test command-line handling is attached to t
This article explains why a “Fail to open file: ncg.ops” error occurs in a Net Express project at link time, and what to do when this happens. Problem: A “Fail to open file: ncg.ops” error occurs when rebuilding a Net Express project. The Output window shows that the error occurs when Net Express invokes the CBLLINK command to link the program. Resolution: This problem occurs when the environment variable COBDIR is overridden in the project. Net Express uses COBDIR to find its own run-time files, so users have to be cautious when setting this environment variable in Net Express. Environment variables can be set in Net Express from the Project Properties under the IDE environment. The best practice is always to append a value to the existing value of COBDIR that can be represented by %COBDIR%. If users wish to append X:\\DIR to COBDIR, they should set COBDIR with the value: %COBDIR%;X:\\DIR Incident Number: 2278384
It's often a requirement to use arguments entered on the command line during the execution of a COBOL application; here’s a technique for capturing a varying number of arguments. Problem: How to capture a varying number of command-line arguments while executing a COBOL application. Resolution: ARGUMENT-NUMBER and ARGUMENT-VALUE are functions that can be defined in the SPECIAL-NAMES paragraph of a COBOL program. These functions can be used to retrieve the numbers and values of command-line arguments entered when the program is executed. The attached sample program demonstrates the use of these functions. These functions work in combination with the ACCEPT and DISPLAY COBOL verbs: DISPLAY UPON ARGUMENT-NUMBER establishes which argument should be manipulated, and ACCEPT FROM ARGUMENT-VALUE returns the contents of the command-line argument identified in ARGUMENT-NUMBER. ACCEPT VARIABLE FROM ARGUMENT-NUMBER returns the number of command-line a
This article explains the error "ProgName fails with RTS 173". Problem: A program can be executed from anywhere if its location is added in the environment variable COBDIR (if it is in .INT or.GNT and executed with the RUN command) or PATH (if it is in .EXE). However, the animator cannot find it if it is to be animated from the command line as shown below: MFNETX /DEBUG:ProgName.Ext. Where ProgName is the name of the program and Ext is the extension (INT, GNT, or EXE). The above command fails with RTS 173, which means that the program cannot be located, unless the program is in the current directory. Note: Animating a program always requires its program source and its .idy files to be available. Resolution: The command line parameter ProgName should either be the full path of the program or a program name relative to the working directory. The following precision has been added to the documentation of Net Express 5.1 with WrapPack 2, which applies
Created On: 14 July 2011 Problem: Executing programs in EXE outside of the Net Express IDE fail with a Semaphore Failure. The problem, however, does not occur if the program is linked with the static run-time or dynamically bound shared run-time. Here is the exact error message: ASLM: Semaphore failureASLM: Errno 1000 Resolution: This error occurs when the application is using or picking up an older version of the run-time. For example, this error occurs if an application that was built with Net Express version 5.1 is executed with a Net Express version 4.0 run-time. There is no reason to run an application with an older version of the run-time, and unexpected errors may then occur when old run-time files are found in the PATH environment variable. Incident #2267278 Old KB# 14356
This article shows you how to run multiple products on the same machine. Problem: Many users are now running or would like to run multiple versions of Micro Focus COBOL products on the same machine. It doesn't matter whether you want to test a patch or test a new version before putting it into production: it is easy to run multiple versions of Server Express and older versions of Micro Focus Object COBOL Developer Suite on the same machine without any problems. Resolution: Let's take the example of running Server Express v5.1 and Server Express v4.0 SP2 on the same machine. First, they must be installed in separate directories. The directory structure would look something like: Next, you must ensure that the environment variables COBDIR and LD_LIBRARY_PATH — LIBPATH for AIX and SHLIB_PATH for HP/UX — are set correctly. Then set the PATH environment variable so that the first entry is pointing to $COBDIR/bin. This will guarantee that the correct drivers are used with the
This article describes what you can do if an error occurs when attempting to run a program with the Server Express run-time. Problem: An executable file cannot be run using Server Express; a load failure caused by a missing shared library is reported. Resolution: The dependency on library liboops.2.0.so indicates that this executable was built using Object COBOL Developer Suite. Recompiling/rebuilding the executable file under Server Express will resolve the error. Old KB# 14330
This article resolves an ASLM error due to underlying permissions. Problem: This error occurs when trying to run a COBOL program. ASLM COBDIR not set or inadequate permissions An "ls -ld" on the directory while the file system is mounted shows the appropriate permissions and owner/group identities. Resolution: The error occurs due to the underlying permissions on the volume mount point being more restrictive than on the actual directories. To fix a current problem with the underlying mount point, the only viable option is to follow these steps: Stop the processes that are running on the mounted file system and any file systems that are mounted on it. Un-mount the file system (this will require un-mounting file systems, if any, mounted in its path). Use the "ls -ld" command to inspect the mount point directory. Change the owner/group/permissions of the mount point directory. Mount the file system back onto the directory.
This article explains what to do if an environment variable is set incorrectly. Problem: We are attempting to use Micro Focus COBOL and receiving the following error: fatal: libcobrts64.so.2: open failed: No such file or directory Resolution: If you have set LD_LIBRARY_PATH and have exported it then there is a chance you have set the LD_LIBRRY_PATH_64 environment variable. This environment variable takes priority over the LD_LIBRARY_PATH environment variable. To resolve this, either: Unset LD_LIBRARY_PATH_64 Use LD_LIBRARY_PATH_64 as you would LD_LIBRARY_PATH. That is, set LD_LIBRARY_PATH_64=$COBDIR/lib:<oracle-environment-variables>:...... Old KB# 14311
This article includes a COBOL program that will convert a UNIX date to an epoch date and then back to human-readable. Problem: How can a calendar date be converted to an epoch date and then back to human readable? Resolution: The attached COBOL program is an example of how to convert a UNIX calendar date to an epoch date and how to convert an Epoch date to a calendar date, using the operating system’s date command. epoch.cblEpoch, UNIX Time, Posix Tim, Unix TimestampDate: Name: Description of change: Date: Name: Description of change: Attachments epoch.cbl Old KB# 14335
This article explains an ASLM 1013 semaphore failure when attempting to run a COBOL program or when using Application Server without world writable permissions for /var/aslmfsem. Problem: Without world writable permissions for /var/aslmfsem, the following error gets displayed when running an application: ASLM: Semaphore failure. Rerun as root ASLM: Errno 1013 What is the file for, and is there a way to remove the world writable permissions and still have an application run? The same ASLM 1013 semaphore failure also happens when attempting to run a COBOL program. Resolution: The message is normally caused by the missing semaphore file in /var/aslmfsem or the permissions on the file are incorrect. The aslmfsem file has a zero length so it can be created by using the following command: touch /var/aslmfsem The file permission should be rw_rw_rw_ (or R/W) for all and should be owned by root. If the file is present with the correct permissions the check the permiss
This article describes how to use OLE automation to interact with Excel from COBOL. Problem: Exporting data from COBOL and loading into Excel is possible by simply writing to a line sequential file with comma separated values and then performing a CALL “SYSTEM”. However, a more elegant and powerful solution is to use the OLE automation interface. Resolution: Please see the attached ACUCOBOL-GT v8.1 example included in the excel-ole.zip file. In essence you can do the following: 77 excel-app handle of application. 77 excel-doc handle of workbook. 77 excel-sheets handle of sheets. 77 excel-worksheet handle of worksheet. 77 excel-range handle of range. ****************************************************************** PROCEDURE DIVISION. Main Section. * Create the OLE interface create @Application of @Excel handle in excel-app.
This article describes how to avoid the CANCEL ALL statement from canceling DLL’s and Shared Library Objects, but still cancel COBOL programs. Problem: It is necessary to cancel everything at this point except DLLs and Shared Object Libraries. For this purpose the CANCEL ALL statement is being used in the code of the program, but it is canceling everything. Resolution: The solution is to use the configuration variable CANCEL_ALL_DLLS. The default value for this variable is “1” (on, true, yes). By setting it to “0” (off, false, no) CANCEL ALL will not cancel DLLs or Shared Object Libraries. To cancel a DLL or Shared Object Library a CANCEL statement followed by the name of the library will be needed. Old KB# 14352
If an .adb file is corrupt the user will receive a Segmentation Fault error when running a program in debug mode. Problem: When trying to run an ACUCOBOL-GT application in debug mode the user may receive a “Segmentation Fault” error. Resolution: The debugger saves state information in a ".adb" file which is used when the debugger is executed in another run. This information includes window placement and breakpoint settings. The segmentation fault may be caused by a corrupt .adb file. Delete the .adb debug file (username.adb). The "--no-save-debug" option provides a way to eliminate this behavior as well by not creating a .adb file. Incident Number: 2265685 Old KB# 14295
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.