Browse Prior Art Database

Error-Tolerant Dynamic Allocation of Command Processing Work Space

IP.com Disclosure Number: IPCOM000042854D
Original Publication Date: 1984-Jun-01
Included in the Prior Art Database: 2005-Feb-04
Document File: 3 page(s) / 33K

Publishing Venue

IBM

Related People

Lindem, AC: AUTHOR

Abstract

In a multi-programming environment, interpretive command processors frequently require CPWS (command processing work space) for each process executing or syntax-checking commands. In object-oriented architectures, CPWS is represented internally as a set of one or more space objects. The CPWS is used to store transitory forms of the command and parameter values which will be passed to the CPP (command processing program). If recursive programs are supported, separate CPWS is required for each program invocation in each process. To avoid the overhead involved with creating CPWS during program invocation, CPWS is allocated from a global pool of CPWS's. During program termination, the CPWS is returned to the global pool rather than destroyed. Provisions are made for pool creation, dynamic pool expansion, and error tolerance.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Error-Tolerant Dynamic Allocation of Command Processing Work Space

In a multi-programming environment, interpretive command processors frequently require CPWS (command processing work space) for each process executing or syntax-checking commands. In object-oriented architectures, CPWS is represented internally as a set of one or more space objects. The CPWS is used to store transitory forms of the command and parameter values which will be passed to the CPP (command processing program). If recursive programs are supported, separate CPWS is required for each program invocation in each process. To avoid the overhead involved with creating CPWS during program invocation, CPWS is allocated from a global pool of CPWS's. During program termination, the CPWS is returned to the global pool rather than destroyed. Provisions are made for pool creation, dynamic pool expansion, and error tolerance. At IPL (initial program load) time a global pool of CPWS's is created. The initial size of the pool is a system-tuning parameter set by the system administrator. The pool is represented internally by a LIFO (last-in, first-out) queue. Messages on the queue contain addressability to CPWS. At program- invocation time, addressability to CPWS will be obtained by dequeuing a message from the global queue. Program-dependent fields will be initialized. At program-termination time, the CPWS will be returned to the pool by enqueuing a message containing addressability to the CPWS. If the pool is empty when a dequeue operation is attempted, CPWS is created locally for use by the current program invocation. The CPWS is tagged so it will not be returned to the global queue. An event is signaled to an event-driven system service process indicating the need to create an additional allocation of CPWS's. The advantage to this scheme is that the program is allowed to go on executing while the system service process creates an additional allocation of CPWS's. The number of CPWS's created is dependent on a system tuning parameter set by the system administrator. As soon as the system service process gets control, the event is canceled. It is reestablished again after the additional allocation of CPWS's has been added to the global queue. This is done to keep from handling events signaled by processes which encounter the empty queue between the time the event is signaled and the queue is replenished with CPWS's. The CPWS created locally is not enqueued onto the global queue during program termination. The impetus for creating the CPWS locally and not enqueuing them onto the global queue is to prevent the program's process from being charged with storage that it will not be able to reclaim. In object-oriented architectures, each user typically has a storage limit. Each time an object is created or destroyed, the amount of storage allocated to the user is adjus...