Browse Prior Art Database

Nonresident Module Loader/Controller Program

IP.com Disclosure Number: IPCOM000074989D
Original Publication Date: 1971-Jul-01
Included in the Prior Art Database: 2005-Feb-24
Document File: 3 page(s) / 17K

Publishing Venue

IBM

Related People

Reasor, RE: AUTHOR

Abstract

The Nonresident Module Loader/Controller program ,is used to load and delete nonresident modules into and from core storage. The program was developed in response to the problem: how can a large number of distinct requests, entered randomly and asynchronously, and requiring a fast response time, be processed in a multitasking environment while maintaining a low core design point? The problem can arise in a Conversational Remote Job Entry (CRJE) type of program, where commands are entered randomly from remote terminals and require rapid responses to maintain a conversational atmosphere.

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

Page 1 of 3

Nonresident Module Loader/Controller Program

The Nonresident Module Loader/Controller program ,is used to load and delete nonresident modules into and from core storage. The program was developed in response to the problem: how can a large number of distinct requests, entered randomly and asynchronously, and requiring a fast response time, be processed in a multitasking environment while maintaining a low core design point? The problem can arise in a Conversational Remote Job Entry (CRJE) type of program, where commands are entered randomly from remote terminals and require rapid responses to maintain a conversational atmosphere.

Core requirements for the command processor sections of CRJE programs are too large to allow them to remain resident. The obvious solution is to make the command processors nonresident but this creates a performance problem. The LOAD time of a command processor module consists mostly of implied wait time for the task, while the system fetches the module into core. For a single module request, the wait time is not too significant. However, with ten to thirty requests, the wait time becomes unacceptable for the entire processing task is placed into a wait state until the LOAD completes.

To bypass the wait time in the main processing task, the function of loading and deleting nonresident modules can be transferred to a separate task. Thus, while one user is waiting for a command processor to be loaded, other users are not impacted. In order to transfer the loading and deleting of modules to a separate task, the main processing task must have some internal dispatching scheme to allocate control between the various users. This internal dispatching scheme is the Loader/Controller (L/C) Task which is subservient to the main processing task. The interface between the two tasks is via a POST-WAIT, with both tasks maintaining an Event Control Block (ECB) list which contain an entry for each possible requester. Requests are satisfied by the main task POSTing the L/C with a code specifying the request and an ECB to be POSTed at the completion of the request. The L/C, when it is given control, scans its ECB list for posted requests. When a request is found, the function requested is determined by the request code; the function is executed; the completion ECB is POSTed; and a search is made for the next request in the ECB list. When no requests are pending, the L/C will WAIT on its list of ECB's.

This general Loader/Controller Task concept can be tailored to a specific application by numerous load-delete algorithms, task and requester priorities, and variations in the number of modules loaded at a given time. The following specific features are useful in a conversational remote job entry embodiment. All nonresident modules to be processed by the L/C are to be link edited as reentrant. This will reduce core fragmentation since only one subpool is used for loading. To further reduce core fragmentation, all nonresident mo...