Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

An Efficient, Thread-Safe Method of Communicating File Status and Related Information between a COBOL Program and the Runtime Layer

IP.com Disclosure Number: IPCOM000241021D
Publication Date: 2015-Mar-20
Document File: 5 page(s) / 70K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to assist Data Locators (DL) in Common Business-Oriented Language (COBOL) using a DL table structure. The method provides an alternative to storing an actual address in the file information block (FIB) for each item to locate, thus supporting COBOL file thread safety.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 40% of the total text.

Page 01 of 5

An Efficient, Thread-Safe Method of Communicating File Status and Related Information between a COBOL Program and the Runtime Layer

Common Business-Oriented Language (COBOL) applications that perform file input/output (I/O) operations communicate information about accessed files to a runtime layer via a file information block (FIB) that is stored in writable static memory. This structure should be stored in static memory for the following reasons.

The FIB consists primarily of information that is static throughout the duration of program execution , such as information that describes the characteristic of the associated file. This information is largely known at compile-time and thus compile-time initialization of the majority of the structure is possible and can result in significant performance benefits ; however, such compile-time initialization is only possible if the structure is in static memory.

In addition, when many instances of the same program are run in parallel in a multi-threaded environment, it is desirable for a file's FIB to be in static memory so that it can be shared amongst all threads. This is because COBOL applications frequently access many files and the FIB can sometimes be large; storing multiple copies of the FIB in each thread's local memory can be prohibitively expensive in terms of memory consumption.

One type of information that is stored in the FIB is addressing information . The COBOL runtime requires this information to help it locate the memory for file-related data items that the user declared in the COBOL application and which both the COBOL application and the runtime need to access. These locator items are referred to as Data Locators (DLs) herein. An example of an item requiring a DL is a file status data item, which the runtime updates after each I/O operation and which the COBOL application can examine for error handling purposes. Many other items can be present, including data items for communicating information about record keys, file passwords, and record keypart values.

When an item located by DL is declared in local storage (i.e., stack memory), the address of the item is not determined until runtime. When an item located by a DL is declared in the COBOL "linkage section", the address of the item is determined at runtime and the address of the item might change during execution of the application .

The above scenarios pose a problem for initialization of the FIB for situations in which multiple instances of the same program are running in a single process space in different threads. If the addresses of the items are stored in the FIB at runtime , during program initialization when the addresses is known, then this is not thread-safe because the FIB is in static memory; therefore, it can only hold a single address. As a result, in a multi-threaded environment during program initialization, each thread overwrites

1


Page 02 of 5

the slot in the FIB that stores the address. The address th...