Browse Prior Art Database

Concurrency between Workstation Windows and VM Sessions in a Graphical User Interface Environment

IP.com Disclosure Number: IPCOM000116912D
Original Publication Date: 1995-Nov-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 95K

Publishing Venue

IBM

Related People

Casey, CT: AUTHOR [+3]

Abstract

This invention allows multiple commands or applications to run as children of the Conversation Monitor System (CMS) Root process, and display data to the same screen, which allows the Commands process to free up for accepting new commands while these other applications continue executing.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 53% of the total text.

Concurrency between Workstation Windows and VM Sessions in a Graphical
User Interface Environment

      This invention allows multiple commands or applications to run
as children of the Conversation Monitor System (CMS) Root process,
and display data to the same screen, which allows the Commands
process to free up for accepting new commands while these other
applications continue executing.

      Traditionally, user commands or applications cannot set
themselves up to run under the Root process, so they do not get the
concurrency between the CMS Root and Commands processes.  These
commands or applications can only run in the Commands process or in a
descendent of it, thus tieing up that process from accepting new
commands until the initial command completes.  The Root process
approach allows host data to be displayed through workstation
graphical user interfaces, to the same screen that displays a 3270
emulator session window, and allows the user to issue host commands
from both processes and enables them to execute concurrently.

      During CMS initialization, a thread will be established in the
CMS root process.  It will create the VMROOTCHILD event, an event
monitor and the associated event trap routine that will be notified
when the CMSDESK command has been requested from the CMS command
line.  That application will then be started in a new process as a
child of the root process.

      By running applications under the root process, the commands
process is freed up and allows the CMS desktop to achieve concurrent
task execution.  Since the applications will execute in separate
processes, there will be concurrency among themselves as well as with
other commands that may execute directly in the commands process.
The new CMSDESK command, for example, will generate the event signal
to launch the application in a new process, and return to the
commands process ready to accept another command.  If a user wants to
run their application concurrent with the command line, they will be
able to add their application to the CMS desktop, using an interface
provided by the desktop, and CMS will signal the VMROOTCHILD event to
spawn the application as a child of the root process.

The steps in the Figure are:
  1.  The CMS Desktop initialization occurs during CMS root
       initialization when all threads of the root process are
       initialized.
  2.  The CMS Desktop thread will c...