Abstract: A computer-implemented method includes creating a first file control block in a primary runtime environment with a first addressing mode and a second file control block in a secondary runtime environment with a second addressing mode, where both the first file control block and the second file control block describe a status of a first file of a caller program in the primary runtime environment. The parameters of the first file of the caller program in the primary runtime environment are passed to a target callee program in the secondary runtime environment. An anchor is added in the first file control block as a link to the second file control block. The first file control block are the second file control block synchronized with updates to the first file in the primary runtime environment and the passed parameters of the first file in the secondary runtime environment.

Abstract: Global variables are shared between programs associated with different addressing modes. A first program of an application records an allocated address to a global variable in a global variable sharing area (GVSA). The first program is associated with a first addressing mode. The first program specifies the global variable to be shared across different addressing modes. An address of the GVSA is passed to a second program of the application that is loaded after the first program has been loaded. The second program is associated with a second addressing mode different from the first addressing mode. The second program also specifies the global variable in the second program to be shared across different addressing modes. The second program retrieves the allocated address to the global variable from the GVSA based on the address of the GVSA. The second program accesses the global variable based on the retrieved allocated address.

Abstract: A call to an external interface to execute a target callee program associated with a first addressing mode in a secondary runtime environment (RTE) is received from a caller program associated with a second addressing mode running in a primary RTE. An address of a share area (SA) storing existing dynamic link object information in the primary RTE in storage is passed to the secondary RTE. The SA is accessible by both the caller program and the target callee program. In response to a request to load a dynamic link object by an initiating program during execution of the target callee program in the secondary RTE, an entry address of the dynamic link object is retrieved in the SA. The dynamic link object is loaded based on the retrieved entry address of the dynamic link object.

Abstract: Aspects of the invention include creating a first file control block in a primary runtime environment with a first addressing mode and a second file control block in a second runtime environment with a second addressing mode, where both the first file control block and the second file control block describe a status of a first file of a caller program in the primary runtime environment. The parameters of the first file of the caller program in the primary runtime environment are passed to a target callee program in the secondary runtime environment. An anchor is added in the first file control block as a link to the second file control block. The first file control block are the second file control block synchronized with updates to the first file in the primary runtime environment and the passed parameters of the first file in the secondary runtime environment.

Abstract: Techniques for signal handling between programs associated with different addressing modes in a computer system are described herein. An aspect includes, based on a signal occurring during execution of a first program in a first runtime environment, wherein the first program and the first runtime environment are associated with a first addressing mode, invoking a first signal exit routine associated with the first addressing mode. Another aspect includes allocating a signal information area (SIA) by the first signal exit routine. Another aspect includes calling a second signal exit routine associated with a second addressing mode that is different from the first addressing mode with an address of the SIA. Another aspect includes allocating a mirror SIA by the second signal exit routine. Another aspect includes handling the signal, and resuming execution based on the handling of the signal.

Abstract: A computer-implemented method for termination of programs associated with different addressing modes includes receiving a call to an external interface to execute a target callee program from a caller program executing in a primary runtime environment. The external interface allocates an interoperability term area (ITA) in a primary runtime environment. The ITA is accessible by the primary runtime environment and a secondary runtime environment. The external interface executes the target callee program in the secondary runtime environment. The target callee program sets a termination reason parameter in the ITA. In response to the target callee program setting the termination reason parameter, a termination action in the primary runtime environment is performed. Various other methods, systems, and computer-readable media are also disclosed.

Abstract: A computer-implemented method for termination of programs associated with different addressing modes includes receiving a call to an external interface to execute a target callee program from a caller program executing in a primary runtime environment. The external interface allocates an interoperability term area (ITA) in a primary runtime environment. The ITA is accessible by the primary runtime environment and a secondary runtime environment. The external interface executes the target callee program in the secondary runtime environment. The target callee program sets a termination reason parameter in the ITA. In response to the target callee program setting the termination reason parameter, a termination action in the primary runtime environment is performed. Various other methods, systems, and computer-readable media are also disclosed.

Abstract: Techniques for signal handling between programs associated with different addressing modes in a computer system are described herein. An aspect includes, based on a signal occurring during execution of a first program in a first runtime environment, wherein the first program and the first runtime environment are associated with a first addressing mode, invoking a first signal exit routine associated with the first addressing mode. Another aspect includes allocating a signal information area (SIA) by the first signal exit routine. Another aspect includes calling a second signal exit routine associated with a second addressing mode that is different from the first addressing mode with an address of the SIA. Another aspect includes allocating a mirror SIA by the second signal exit routine. Another aspect includes handling the signal, and resuming execution based on the handling of the signal.

Abstract: During a first execution of software, historical data is logged that indicates which locale objects were used. During a second execution of the software, the historical data is read, and locale objects or subsections of locale objects are dynamically built from locale source files based on the historical data in the log that indicates which locale objects were used during the first execution. Any other locale objects or subsections that are needed that are not built initially during the second execution are dynamically built from locale source files when requested at run-time. Dynamically building locale objects or subsections based on which locale objects were used in one or more previous executions saves time that would otherwise be required to build the locale objects when they are needed at run-time. The result is significant savings in system-wide resources while still allowing for access to a large number of possible locales.

Abstract: During a first execution of software, historical data is logged that indicates which locale objects were used. During a second execution of the software, the historical data is read, and locale objects or subsections of locale objects are dynamically built from locale source files based on the historical data in the log that indicates which locale objects were used during the first execution. Any other locale objects or subsections that are needed that are not built initially during the second execution are dynamically built from locale source files when requested at run-time. Dynamically building locale objects or subsections based on which locale objects were used in one or more previous executions saves time that would otherwise be required to build the locale objects when they are needed at run-time. The result is significant savings in system-wide resources while still allowing for access to a large number of possible locales.

Abstract: Subsections of locale objects are dynamically built from locale source files when requested at run-time without building all subsections of the locale object. When a subsection of a locale object is dynamically built, the subsection is stored in global memory so it may be read by multiple applications. Dynamically building subsections of locale objects when requested allows software to operate with a relatively small number of locale objects.

Abstract: Subsections of locale objects are dynamically built from locale source files when requested at run-time without building all subsections of the locale object. When a subsection of a locale object is dynamically built, the subsection is stored in global memory so it may be read by multiple applications. Dynamically building subsections of locale objects when requested allows software to operate with a relatively small number of locale objects.

Abstract: During a first execution of software, historical data is logged that indicates which locale objects were used. During a second execution of the software, the historical data is read, and locale objects or subsections of locale objects are dynamically built from locale source files based on the historical data in the log that indicates which locale objects were used during the first execution. Any other locale objects or subsections that are needed that are not built initially during the second execution are dynamically built from locale source files when requested at run-time. Dynamically building locale objects or subsections based on which locale objects were used in one or more previous executions saves time that would otherwise be required to build the locale objects when they are needed at run-time. The result is significant savings in system-wide resources while still allowing for access to a large number of possible locales.

Abstract: During a first execution of software, historical data is logged that indicates which locale objects were used. During a second execution of the software, the historical data is read, and locale objects or subsections of locale objects are dynamically built from locale source files based on the historical data in the log that indicates which locale objects were used during the first execution. Any other locale objects or subsections that are needed that are not built initially during the second execution are dynamically built from locale source files when requested at run-time. Dynamically building locale objects or subsections based on which locale objects were used in one or more previous executions saves time that would otherwise be required to build the locale objects when they are needed at run-time. The result is significant savings in system-wide resources while still allowing for access to a large number of possible locales.

Abstract: Locale objects are dynamically built from locale source files when requested at run-time. When a locale object is dynamically built, it is stored in global memory so it may be read by multiple applications. Dynamically building locale objects when requested allows software to operate with a relatively small number of locale objects instead of with hundreds or thousands of locale objects, as is known in the art. The result is significant savings in system-wide resources while still allowing for access to a large number of possible locales.

Abstract: Locale objects are dynamically built from locale source files when requested at run-time. When a locale object is dynamically built, it is stored in global memory so it may be read by multiple applications. Dynamically building locale objects when requested allows software to operate with a relatively small number of locale objects instead of with hundreds or thousands of locale objects, as is known in the art. The result is significant savings in system-wide resources while still allowing for access to a large number of possible locales.

Abstract: During a first execution of software, historical data is logged that indicates which locale objects were used. During a second execution of the software, the historical data is read, and locale objects or subsections of locale objects are dynamically built from locale source files based on the historical data in the log that indicates which locale objects were used during the first execution. Any other locale objects or subsections that are needed that are not built initially during the second execution are dynamically built from locale source files when requested at run-time. Dynamically building locale objects or subsections based on which locale objects were used in one or more previous executions saves time that would otherwise be required to build the locale objects when they are needed at run-time. The result is significant savings in system-wide resources while still allowing for access to a large number of possible locales.

Abstract: During a first execution of software, historical data is logged that indicates which locale objects were used. During a second execution of the software, the historical data is read, and locale objects or subsections of locale objects are dynamically built from locale source files based on the historical data in the log that indicates which locale objects were used during the first execution. Any other locale objects or subsections that are needed that are not built initially during the second execution are dynamically built from locale source files when requested at run-time. Dynamically building locale objects or subsections based on which locale objects were used in one or more previous executions saves time that would otherwise be required to build the locale objects when they are needed at run-time. The result is significant savings in system-wide resources while still allowing for access to a large number of possible locales.

Abstract: According to embodiments of the invention, methods, computer readable storage medium, and a computer system for controlling access to variables protected by an alias are disclosed. The method may include monitoring, during a debug session, each attempt by a debugger to apply an operator to one or more variables protected by an alias. The method may also include determining whether to allow an application of an operator to a variable protected by an alias, wherein the determination is based at least in part on one or more rules.

Abstract: According to embodiments of the invention, methods, computer readable storage medium, and a computer system for controlling access to variables protected by an alias are disclosed. The method may include monitoring, during a debug session, each attempt by a debugger to apply an operator to one or more variables protected by an alias. The method may also include determining whether to allow an application of an operator to a variable protected by an alias, wherein the determination is based at least in part on one or more rules.