Rocket® COBOL

Problem: A situation can exist where it is not possible to create an executable using "cob -x".   The error occurs even when testing one of the simple demonstration programs that are furnished with the product, for example: mkdir  /tmp/test cp  $COBDIR/demo/debug/pi.cbl  /tmp/test cd  /tmp/test cob -x  pi.cbl      The system linker "ld" reports not being able to find a library named "cobstat" or "-lcobstat".   The exact wording of the error message depends on the bit mode (whether 32 or 64), but always mentions "cobstat".   This problem is specific to HP/UX and does not occur on other UNIX variants. Resolution: This problem is caused by the environment variable LDOPTS being set as follows: LDOPTS="-a shared" This causes the system linker to search only for shared libraries (.sl),

Problem: Setting a external runtime switches that can be used within COBOL applications. Resolution: The COBOL program would be coded as follows:        IDENTIFICATION DIVISION.        ENVIRONMENT DIVISION.        CONFIGURATION SECTION.        SPECIAL-NAMES.            switch-0 ON is test-switch-0            switch-1 ON is test-switch-1            switch-2 ON is test-switch-2.        DATA DIVISION.        WORKING-STORAGE SECTION.        PROCEDURE DIVISION.        100-process.      &nbs

Problem: When software is delivered in binary form only, how can the COBOL version used to build the software be identified. Resolution: This is possible although identifying the point-release of a product would be very time consuming and only possible by Micro Focus technicians. Binaries built using Object COBOL can be differentiated from those built under Server Express  by looking at the library dependencies. Use "ldd $binary_name" Binaries built under Object COBOL  will have a dependency on libcobol, binaries built under Server Express will have a dependency on  libcobrts. On AIX 4 use "dump -Hv $binary_name" 'ldd' lists dynamic dependencies of executable files or shared libraries. So, using ldd on 'demo' when it's been compiled with Server Express returns the following: Note that the 'grep' command is used to filter the output.   ldd demo | grep l

Problem: Using CRT Status to detect the page-up or page-down key in a COBOL program. Resolution: The page-up and page-down keys are not ADIS keys.  They are in fact user function keys.  If they are not recognized by your COBOL program then you have two options on defining them. First, you can define the page-up and page-down key using keybcf.  Under option 3-Alter User Function Keys you must modify function keys 53 (page-up) and 54 (page-down) by pressing the key for appropriate action. Save the file (cobkeymp). There is a table of the various key numbers in the Server Express documentation. The other option is to modify your terminfo setting. Old KB# 7255

Problem: To determine the format of a Micro Focus executable file, use the Server Express cobfile command.  The cobfile command is available in Server Express 2.0 and later. Resolution: This command checks for intermediate code files (.int files), generated code files (.gnt files) Animator information files (.idy files), and library files (.lbr files) produced on Server Express (32-bit and 64-bit) and OCDS Version 4.1 and later.  It also checks for screen output recording files (.scn files, where n is a hexadeximal digit between 1 and F) and keystroke files (.key files). The cobfile command takes the following format: cobfile file [file] ... where file is the filename of a Micro Focus executable file. For example: cobfile myprog.int displays one of the following: myprog.int: Micro Focus 32-bit intermediate code file myprog.int: Micro Focus 64-bit intermediate code file If the cobfile command does not recognise a a file

Problem: After migrating an application from VAX to Solaris UNIX and Server Express, one may notice that the last byte in some data items in his output files appeared differently than it did when the program was run on the VAX. Resolution: For numeric data items of usage DISPLAY, the sign is encoded in the last byte (unless the SIGN TRAILING SEPARATE clause is specified for the item).  There are two popular conventions for encoding the sign in the last byte:  the ASCII convention and the EBCDIC convention.  Micro Focus uses the ASCII conventin by default, and apparently VAX COBOL uses the EBCDIC convention. The compiler directive named SIGN can be used to change Server Express's behavior in this regard.  For compatibility with the VAX,  the following option can be specified on the "cob" command used to compile the programs:   -C SIGN=EBCDIC Old KB# 7221

Problem: Customer is migrating from OCDS to Server Express.  Compiling code results in multiple occurrences of COBCH1146W messages - these did not occur under OCDS Resolution: The message produced is just a warning - there are no runtime issues.   The compiler has always had the ability to produce this message. This message is only produced when analyzing the CSI information while creating the .idy file.  In the Server Express product, CSI is now set to on by default when ANIM specified. Old KB# 7235

Problem: Sometimes the user many want to use animator and faultfinder without the animator generating information files.  Is this possible?  If so, how? Resolution: If the compiler directive NOANIM is implemented the compiler will not create the animator information file (.idy) If Tte compiler directive NOANIM is used , the flag -g is useless Old KB# 7281

Problem: cobscan64 runs the Scan64 utility. The Scan64 utility enables you to check programs for pointer violations. You use Scan64 to help you migrate applications from 32-bit to 64-bit COBOL systems. If you have developed COBOL programs using the Server Express 32-bit development environment that you want to migrate to the Server Express 64-bit development enviroment, you should run Scan64 before compiling and running them with the 64-bit system development environment. Resolution: Note: Scan64 cannot detect invalidly-sized data items provided to prototyped CALL statements that require pointers. You can only use Scan64 on applications that have been compiled to intermediate code. The format of the command is: cobscan64 [-v] [-m] [-ttfile [-ltlist]] filename where the parameters are:   -v         Internal addressing information is displayed. This can be useful to our support  &nbsp

Problem: Problems converting a fixed length line sequential file to variable length idxformat4. The input file is LSEQ 662, fixed length.  The output file is mf4 format variable length 662-4089. Using the command: rebuild infile, outfile -o:LSEQ,IND -t:mf4 -k:1-48 -r:v662-4089 getting the error message 'REBUILD aborted - Invalid key specification - key not contained in record'. The -r option specifies the record format.  However, the input file is fixed 662 and the output file is variable. How do I specify the input and output record formats in the same command? Resolution: Sequential files do not have header information  so the organization and record length must be specified. There is only one keyword for record length (-r) and it is not possible to specify a different record length on the input and output files. To get around this, run the conversion in two steps: Try running the conversion from lseq to

Problem: Using Informix File handler for Informix files instead of the Micro Focus file handler. Basically, the number of open files increases to a stage where some processes hangs and when it reaches the open file limit, it crashes.  Common files are not closing, while all the other files are closed, which causes the number of open files to increase. eg: 1. Program 1 opens files A, B, C and D 2. Then Program 1 calls Program 2 which open files X, Y, A and B. 3. Program 2 finishes it process, close files X, Y,  A and B and exit program. 4. Program 1 continues it's process, at this moment Files A and B are opened twice in the system. 5. When this happens several times, the number of files opened by a process exceed the limit and the program crashes with Informix error 24. Resolution: Try the following tunable: multi_close_limit Syntax:                set

Problem: Investigating 173 error on calls to COBOL callable shared objects (CSO) and third party products Resolution: The first thing to look at is to check that the third party product is 32-bit if you are using the 32-bit version of the COBOL product or 64-bit if you are using the 64-bit version of the COBOL product. If your application uses more than one third party product, cut it down to a version that only includes the third party product that is giving you problems.  Once that is working you can start adding other products to your application. Check the third party documentation for libraries that have to be linked to your application. Sometimes your third party product provides 2 versions, one threaded and one non-threaded. Choose carefully the one that matches your application. If you are migrating from .int/.gnt code to callable shared objects, please notice that callable shared objects are executables to the OS and unlike .int or .gn

Problem: Customer used to have the COBCAP environment variable,  Now, however, the variable no longer exists. What can be used instead? Resolution: COBCAP was an old means of mapping external file names which was retained for backward compatibility. It was superseded (and its use was deprecated) about 10 years ago, and it was finally dropped from Server Express in 2001. COBCAP was replaced by the ASSIGN "EXTERNAL" directive (or the EXTERNAL reserved word in the ASSIGN clause of a SELECT statement), along with an environment variable or a configuration file to create the exact mapping of logical name onto physical name. For full details and examples of filename mapping and assignment, please refer to the Server Express File Handling Manual. Old KB# 7236

Problem: After copying executables from a server which was running Object Cobol Developers Suite to a new server with Server Express the application got this library error 0509-150   Dependent module libcobol.2.0.a(shr.o) could not be loaded.         0509-022 Cannot load module libcobol.2.0.a(shr.o).         0509-026 System error: A file or directory in the path name does not exist. Resolution: There are a number of libraries which were used under OCDS which are missing completely from the Server Express product. Some of the missing libraries are: $(COBDIR)/coblib/libcobol.a $(COBDIR)/coblib/libscreen.a $(COBDIR)/coblib/libosx.a $(COBDIR)/coblib/libasmcrtn.a $(COBDIR)/coblib/libsupp.a $(COBDIR)/coblib/libcobstat.a One of the differences between OCDS and Server Express is that Server Express has a completely different product shape. The names of the libr

Problem: When Animating a program, a 191 error ('Terminal type not defined') error occurs when making a call to something like ADIS, even though the terminal type has been defined (by setting TERMINFO) Resolution: This error only occurs if a customer is using a different terminfo directory or has deleted some files from the Micro Focus provided one. When a process is being debugged by Animator, if the application then has to display a screen, there are of course two screens running; these are referred to as the 'Animator' and 'debuggee' screens. If they share the same terminal, then the TERM setting of the debuggee process is set to "mfdebug".  The application will, therefore, search for an 'mfdebug' terminfo; if the m/ folder and/or the files below it cannot be found in the terminfo structure, this error will occur. Solution: if you are using a different terminfo, copy the m/ directory and its contents into it

Problem: Customer has both the development product and Application Server on the same machine, installed in two separate locations (cobol and cobolas)  They have five development licenses and two hundred Application Server licenses installed, but process is running out of available licenses and failing with an A147 system abend. Resolution: Application Server licenses are recorded against a specific installation path.  The mfaslmf userlog showed that the application was trying to use the five development licenses rather than the Application Server licenses.  This was ascertained by examining the error messages in the userlog: No license AS /usr/lib/cobol This showed that the environment was pointing to the development product (cobol), rather than the Application Server installation (cobolas). Firstly check that COBDIR, PATH and LD_LIBRARY_PATH/LIBPATH/SHLIB_PATH are pointing to the correct product location. Check any .profi

Problem: Server Express error message: dependent module libcobol.2.0.a can not be loaded - problem occurs after migrating from Object COBOL Developer V4.1 to Server Express. Resolution: Here is an more complete explanation of the errors: 0509-150 Dependent module libcobol.2.0.a(shr.o) could not be loaded. 0509-022 Cannot load module libcobol.2.0.a(shr.o). 0509-026 System error: A file or directory in the path name does not exist. There are a number of libraries which were used under Object COBOL which are missing completely from the Server Express product. Some of the missing libraries are: $(COBDIR)/coblib/libcobol.a $(COBDIR)/coblib/libscreen.a $(COBDIR)/coblib/libosx.a $(COBDIR)/coblib/libasmcrtn.a $(COBDIR)/coblib/libsupp.a $(COBDIR)/coblib/libcobstat.a One of the differences between Object COBOL and Server Express is that Server Express has a completely different product shape. The names of the libraries shipped with the product have c

Problem: It would be useful if there were a way for Micro Focus COBOL to retrieve the user-id from the UNIX operating system --  the same user-id that the UNIX "id" command would show. Resolution: Micro Focus COBOL can call C routines directly, if the C routines have been linked with the COBOL run-time system.  A programmer would use the CALL statement, and put the name of the C routine in quotes. The UNIX system library "libc.a" (or "libc.so") has already been linked with the run-time system, so COBOL can directly call any of the UNIX system calls contained in "libc".  On most platforms, the intro(2) man page shows a complete list of these calls. getuid(2) is a system call contained in "libc", so COBOL can call it directly.  Consider the following program:         01 uid-ws pic 9(8) comp-5.      &nb

Problem: In Server Express, when a record is read with lock and then within the same process another attempt is made to read the record the extended file status code 9/068 will be returned. This would typically happen where a program reads a record with lock, then calls another porgram and attempts to read the same record. In Object COBOL this lock is ignored and a file status of  '00' is returned but in Server Express 9/068 is returned. This only happens if the access takes place within the one process. Normal record locking applies to both products for for records lockded in another process. Resolution: It may be that you want Server Express to behave the same as Object COBOL Developer Suite, particularly in the case of legacy applications where the activation of the record lock is not expected. To disable the record lock and have a file status of '00' returned on the read of a record that has previously been read with lock within th

Problem: If you are migrating from an Object COBOL Developer Suite (OCDS) v4.1 release to a Server Express v2.x release, then there are some points you should have keep mind. Resolution: Source Code from OCDS should compile cleanly with Server Express. So, you should only need to move over your source files, recompile, and re-link your application. However, as you can no longer link your application as a static executable, you might need to change how your application is built.  The following describes some of the changes pertinent to those moving applications from OCDS to Server Express. Cob flags now obsolete in Server Express: There are some cob flags that are no longer supported with in the Server Express product.  These are: Cob flag Description -B mode[=lib] Select the system linker binding mode B mode[=lib] Select the system linker binding mode and pass to system linker after COBOL libraries -F Create an RTS quickly F

Problem: In Server Express divding by zero always causes an error if you do not use the ON SIZE ERROR clause; otherwise the results are unpredictable. Resolution: Recode your program so that you can trap the error with an ON SIZE ERROR clause If, after decimal point alignment, the absolute value of a result of an arithmetic operation exceeds the largest value that can be contained in the associated resultant-identifier, a size error condition exists. Division by zero always causes a size error condition. Note that the results of division by zero when no ON SIZE ERROR phrase is specified are unpredictable. The size error condition applies only to the final results, except in MULTIPLY and DIVIDE statements, in which case the size error condition applies to the intermediate results as well. Violation of the rules for the evaluation of exponentiation always terminates the arithmetic operation and always causes a size error condition.  If the ROUNDED

Problem: The behaviour of VARCHAR2 host variables have changed in Pro*COBOL v8.0 You have VARCHAR2 host variables defined as PIC X(n) and are having problems with tests/compares in your WHERE clause after upgrading your version of Oracle. Resolution: Oracle have a configuration option for Pro*COBOL to revert back to the old behaviour. In the $ORACLE_HOME/precomp/admin/pcbcfg.cfg file, add the following: PICX=VARCHAR2 From now on by default, PIC X(n) host variables will no longer have the trailing spaces truncated unless you have this  configuration option. Old KB# 7280

Problem: Customer saw references to both extsm and extsmlfs in the Knowledge Base and wanted to know what the difference was between them. Resolution: extsm is the 'default' module; extsmlfs module was first introduced with Object COBOL Developer System. With that product Micro Focus did not make large file support the default, and so we provided a second version of the external sort module which supported large files. See the extract from the Programmer's Guide to File Handling from OCDS 4.2: "10.1.3.1 Large Indexed Files By default, the file handler can handle files that are up to a maximum of 2 Gigabytes in size. However, if you need to create larger indexed files, you can use the IDXFORMAT Compiler directive to create IDXFORMAT"8" files. These files comprise a single file (as opposed to the usual .idx and .dat files). Even with IDXFORMAT"8" files, however, the COBOL run-time system currently imposes a limit on file size of 2 Gigabytes. To enable you to

Problem: AIX customer upgraded to Server Express 4.0 and got this error when running a CICS application. The actual error is caused by a STRING...DELIMITED BY <literal> statement. This does not happen when the program is compiled to .int, only .gnt and executable. Resolution: A STRING statement is optimised to use the system commands memmove, memcmp and memcpy. However these are not picked up automatically in Server Express 4.0 and 4.0 SP1. The solution is to add entries in the liblist for executable programs (which Micro Focus did in SP1) and to rebuild the runtime, adding the appropriate programs with the -I (upper case letter between 'H' and 'J'), e.g. -I memmove -I memcpy -I memcmp. Unfortunately this isn't the whole story! As CICS works by demanding that everything is compiled into it, you also need to edit the cicsmkcobol script and run it. This rebuilds CICS and the Micro Focus runtime so that they work together. Micro Focus ca

Problem: A program encounters file status 9/007 (which means "disk space exhaused") on a record sequential file open for output.  At the point of error, the file size is 512 bytes beyond 1 GB that is, 1073741312 bytes. Resolution: This file size limitation is not imposed by Micro Focus.  It is probably imposed by the UNIX system.    The default ulimit on AIX 5.2 is 2097151, as can be seen by entering the following command:    ulimit This amount 2097151 is specified in units of 512-byte blocks.  In bytes the value is 2097151 * 512 = 1073741312.   That's one block short of exactly one gig.   2^30 = 1073741824 = 1 gig           So, the default AIX ulimit is 1 GB even on 64-bit systems.   This seems low by today's standards.  This default 2097151 might even be the "hard" limit, and if so, root privi