International Business Machines Corporation

Stephen E Record

Steven S Shultz

Ann M Shepherd

Brian K Wade

Joel Alan Farrell

Robert O Dryfoos

Glenn W Sears, Jr

Christine T Casey

Susan Anderson Pavlakis

Methods, systems, and computer program products for file version control management are provided. Methods include receiving a loadset of at least one data file and activating the loadset. For each data file in the loadset, the data file is written to a target system and identified by a base name and a generation number. A symbolic link with an activation number is created in a version control file index (VCFX) to the data file written to the target system. An application view to the symbolic link is provided as the base name of the data file, and the application view to the symbolic link is limited based on an activation number of the application corresponding to the activation number of the symbolic link.

Methods, systems, and computer program products for file version control management

A multitasking operating system permits application programs (and their developers) to influence a schedule of execution of program threads derived from the application programs. Each of the program threads is assigned a priority level and a dispatch class in which the thread resides. Based on these parameters, the operating system schedules the threads for execution in the following manner. The operating system queues the highest priority thread which is available for execution from each dispatch class onto a run list for execution by a processor. The highest priority thread on the run list is executed first. An application program thread can change the dispatch class in which another program thread resides. An executing program thread can also voluntarily yield to a specified program thread in the same dispatch class or permit the highest priority available thread in the same dispatch class to be queued on the run list with itself being available and in contention for the run list.

Controlled scheduling of program threads in a multitasking operating

A computer operating system manages events defined by an application program or another part of the operating system. Each event definition includes one or more attributes of the event which controls some operating system responses to an occurrence of the event. After an occurrence of a defined event, an application program or another part of the operating system signals an event manager. The event manager reads the corresponding event definition to determine a mode of operating the signaller of the event or a process associated with the event signaller. The operating modes include a synchronous mode whereby the event signaller or the associated process should suspend processing until the event is handled, and an asynchronous mode whereby the event signaller or associated processor can continue processing while the event is being handled. After reading the event definition, the event manager advises the event signaller whether to proceed synchronously or asynchonously. After the event is handled, a suspended event signaller is restarted. The event definition can be updated dynamically.

Asynchronous or synchronous operation of event signaller by event

A computer operating system manages events of interest to a plurality of event handlers within respective programs. The event handlers are arranged in a sequence for the purpose of receiving sequential notification of an occurrence of the event. When the event occurs, the first event handler in the sequence is notified, and it then handles the event. Then, the first event handler determines if the second event handler in the sequence should be notified of the event. If so, the second event handler in the sequence receives the event notification, handles the event, and then determines if the third event handler in the sequence should be notified. In this manner, the event notification can be propagated from event handler to event handler in the sequence, but any event handler in the sequence which receives the notification can block subsequent propagation of the event notification. This technique saves processing time in situations where some or all of the event handlers in the sequence (after the first event handler) may not benefit from the event notification; in such a case, the event notification is not propagated to them.

Notification of event handlers in broadcast or propagation mode by event

A computer operating system manages events. An application program or another part of the operating system defines an event monitor to monitor one or more types of events on its behalf. When each of the monitored events occurs, the event monitor is signalled and stores the event signal. Under certain conditions, the event monitor can notify an event handler, and the event handler can access the stored event signals. The event monitor can be defined and established dynamically, i.e. throughout operation of the computer without stopping or relinking the computer system. In the absence of an event monitor which is interested in an event, signals of the event are nevertheless stored. When an interested event monitor is subsequently established, the previously stored event signals are transferred to the interested event monitor. Thus, the event handler has the benefit of previous event signals. The event can be a trace event, and the event handler associated with each event monitor can receive and handle the trace events in real time.

Dynamically established event monitors in event management services of a

A multitasking operating system permits application programs (and their developers) to influence a schedule of execution of program threads which constitute the application programs by specifying parameters for the program threads. The parameters indicate each thread's priority level and dispatch class in which the thread resides. The application programs specify the thread's parameters based on the following principles of the operating system. The operating system queues the highest priority thread available for execution from each dispatch class onto a run list for execution by a processor. The highest priority thread on the run list is executed first. While this thread is dispatchable and being executed, no other thread from the same dispatch class can preempt it unless this executing thread voluntarily relinquishes control of the processor, even if the other thread has a higher priority. (This other thread would have been created or made available after the currently executing thread was selected for the run list.) However, the currently executing thread can be involuntarily preempted at any time by another higher priority, available thread from a different dispatch class. A thread can also voluntarily relinquish control of its processor at other appropriate points in the execution, for example, when data structures are valid, to share the processor with other lower priority threads from the same or different dispatch classes.

Preemptive and non-preemptive scheduling and execution of program

A computer operating system manages different types of events. An application program or another part of the operating system defines an event monitor to monitor one or more types of events. The definition also specifies a combination of occurrences of the one or more types of events required to satisfy the event monitor. When each of the monitored events occurs, the event monitor is signalled and stores the event signal. When the event monitor has stored signals which satisfy the event monitor, the event monitor can notify an event handler (pursuant to a standing or subsequent inquiry by the event handler). Then, the event handler can access the stored event signals.

Customized and versatile event monitor within event management services

An application program interface for handling full-screen input/output (I/O) operations of a display device in an information handling system, such as a computer system running one or more application programs in conjunction with an operating system. The application program interface first determines characteristics of the display device in response to a request from an application program prior to performing a full-screen I/O operation, and provides these characteristics to the application program so that the application program can provide a buffer, and if an output is to be performed, construct a valid data stream for the display device. Then the application program interface builds a parameter list in response to a request from an application program to actually perform the full-screen I/O operation. Next, in response to the parameter list, the application program interface generates instructions to process the full-screen I/O operation and coordinate this request with other requests made by other application programs. The application program interface then passes the generated instructions to a control program of the information handling system to perform the desired full-screen I/O operation, and handles any status information resulting from the I/O operation. In this manner, the application program interface provides a means for allowing an application programmer to write an application program without being concerned with low level detail of a full-screen I/O operation, as well as providing a means for coordinating full-screen I/O use of a display device by several application programs in an information handling system, and a means for allowing an application program to be architecture independent with respect to full-screen I/O operation.

Growing community of inventors

Ridgefield, CT, United States of America

Stephen E Record