Problem:

Micro Focus run time system error 114 - attempt to access item beyond the bounds of memory - can be one of the most difficult problems to troubleshoot.  However, there are only a few common reasons for the error and Server Express offers more debugging options than previous Micro Focus products.  Occasionally, the problem will be obscure and difficult to find, but those instances are relatively rare.  This article will discuss how to approach diagnosing RTS 114 errors within the Server Express and Application Server environment.

Resolution:

The most common reason for RTS 114 errors reported on UNIX systems came into being with the ability to create and use callable shared objects.  On hardware which has the capability, Server Express can compile your COBOL source to either 32 bit or 64 bit code.  However, the UNIX operating system cannot handle a mixture of 32 and 64 bit code in the same application.

When statically linking applications into a single, monolithic executable, the system linker ("ld" command) will catch "mix and match" errors and report them with rather cryptic messages such as "wrong elf class" or "bad magic number".  Even though the linker messages are not especially clear, the bad code never gets a chance to run.  However, the more modern method of dynamic calls to callable shared objects (functionally similar to Windows .dll objects), cannot catch the problem while linking the main application.  If the main program makes a dynamic call which will be resolved at run time, the linker does nothing to resolve the name during the linkage process.  Thus it is possible to have a 32 bit main program call a 64 bit shared object and vice versa.  The call can be made, but the only possible outcome is an immediate RTS 114 error.

Several customers have created this problem for themselves in the same way recently.  They upgrade OracleÂ, a data base product from Oracle Corporation, from version 8.x to 9.x.  Everything was set up to compile, link, and run in 32 bit mode in the previous version, but 9.x is 64 bit by default.  The first COBOL call to the new client modules fails with RTS 114 and a telephone rings at Micro Focus SupportLine shortly thereafter.

Remember that the library pathing variable, LD_LIBRARY_PATH (called "LIBPATH" on AIX and "SHLIB_PATH" on HP-UX) is used to find callable shared objects in the same way as PATH is used to locate Unix commands.  If another callable shared object of the same name is found first on the library path, an RTS 114 error may result because the interface, "USING" and "RETURNING" is not correct.  For this reason it is wise to name in-house shared objects in such a way as never to conflict with system or third-party product object names.

One of the more obscure manifestations of RTS 114 occurs on the final GOBACK or STOP RUN of the main program.  The usual cause is a mismatch between either the number of arguments USING and/or RETURNING, or the size of those arguments, i.e. mismatched PIC or OCCURS clauses, between calling program and called subroutine.  The problem is pushed onto the program's subroutine stack and is not popped off until later, so the problem is seen long after it was actually set up, sometimes at the very end of the program.  Manual inspection of the USING and RETURNING clauses of every CALL and PROCEDURE DIVISION statement may be necessary.  It may be helpful to know that the special register RETURN-CODE should not be the subject of a RETURNING clause in a CALL or PROCEDURE DIVISION.

Another potential cause is a POINTER item which is uninitialized or which points to the wrong thing.  The COBOL statement SET [pointer-item] TO ADDRESS OF [identifier] needs to be used with care, as does SET ADDRESS OF [linkage-section-item] TO [identifier].

A less frequently seen cause is a "runaway subscript" (subscript value greater than the number specified in the OCCURS clause) or reference modification (start-position:length) which goes beyond the end of the item.  With regard to the latter, the sum of start-position plus length minus one must never exceed the length of the item as specified in its PIC clause.  In the case of a runaway subscript, it may be helpful to use the BOUND directive when compiling.  If the run time error then changes from 114 to 153 (subscript out of range), the problem is diagnosed.

Now that Server Express allows animation of .gnt code, executables, and callable shared objects, it is often easier to find the cause of an RTS 114 in executable code than with previous products which would animate only .int code.  However, the animator itself needs memory space, so the problem may change or disappear due to the different memory utilization when animating.  In that case, it may be helpful to use the run time tunable "core_on_error" to create a core file when the error occurs.  It is also possible to insert DISPLAY statements into the suspect code so that one sees a sort of "progress report" as the program runs up to the error.