Simultaneous control of radio frequency modem in a multi-tasking system using a single session manager program with separate command queue for each application program

Abstract

A data communication method provides management and control functions to allow access to a shared radio frequency communication device by multiple concurrently executing software applications. A predetermined set of commands common to all of the software applications enable a consistent, high-level software interface to the communication device. A single computer program controls the communication device and permits simultaneous independent interface to each of the software applications.

Claims

What is claimed is:

1. In a data processing system comprising a processor, a memory for storing a plurality of software applications, and a shared radio-frequency modem, a method for managing said radio frequency modem comprising:

a. providing a predetermined interface in the form of a command set common to all of said applications, said commands being used to control communication between said applications and said predetermined interface;

b. providing a single computer program that controls the radio-frequency modem and permits simultaneous, independent interface to each of said applications by way of said commands by;

i. issuing a first command from a first one of said applications;

ii. issuing a second command from a second one of said applications;

iii. storing said first and second commands at first and second queues respectively; and

iv. based on the step of storing, writing said first and second commands to said shared radio-frequency modem.

2. In a data processing system comprising a processor, a shared radio-frequency modem, and a memory for storing a plurality of applications and for storing a computer program to control the radio-frequency modem and permit simultaneous, independent interface by said modem to each of said applications by way of said commands, said computer program comprising:

a predetermined set of commands common to all of said applications, said commands being used to control communication between said applications and said computer program;

an application manager for executing said commands;

a queue manager responsive to said application manager, said queue manager comprising a plurality of queues;

a message manager coupled to said queue manager;

a device manager coupled between said message manager and a communications port, said device manager comprising a transmit buffer;

a method for enabling said plurality of applications to send data simultaneously over said radio-frequency modem comprising the steps of:

a. issuing a send command from a first one of said applications to said application manager;

b. issuing a send command from a second one of said applications to said application manager;

c. receiving said send commands, each accompanied by a message or command, at said application manager and writing said respective message or command to first and second queues in said queue manager;

d. polling said queues for pending messages or commands;

e. writing said message or command stored in said first queue into said transmit buffer of said device manager;

f. reading said buffer and writing said stored message or command to said shared radio-frequency modem via said communications port;

g. writing said message or command stored in said second queue into said transmit buffer of said device manager; and

h. reading said buffer and writing said stored message or command to said shared radio-frequency modem via said communications port.

3. In a data processing system comprising a processor, a shared radio-frequency modem, and a memory for storing a plurality of applications and for storing a computer program to control the radio-frequency modem and permit simultaneous, independent interface by said modem to each of said applications by way of said commands, said computer program comprising:

a predetermined set of commands common to all of said applications, said commands being used to control communication between said applications and said computer program;

an application manager for executing said commands;

a queue manager responsive to said application manager, said queue manager comprising a plurality of queues;

a message manager coupled to said queue manager;

a device manager coupled between said message manager and a communications port, said device manager comprising a receive buffer;

a method for enabling said plurality of applications to receive data simultaneously over said radio-frequency modem comprising the steps of:

a. receiving first incoming data at said radio-frequency modem;

b. writing said first data into said device manager's receive buffer;

c. reading said first data from said receive buffer;

d. writing said first data into a first one of said queues in said queue manager;

e. receiving second incoming data at said radio-frequency modem;

f. writing said second data into said device manager's receive buffer;

g. reading said second data from said receive buffer;

h. writing said second data into a second one of said queues in said queue manager;

i. holding said first data in said first queue until a receive command is issued from a first one of said one applications;

j. notifying the user that data for said first application has arrived;

k. issuing a receive command from said first application to said application manager;

l. receiving said receive command at said application manager from said first application and routing said data to said first application;

m. holding said second data in said second queue until a receive command is issued from a second one of said one applications;

n. notifying the user that data for said second application has arrived;

o. issuing a receive command from said second application to said application manager; and

p. receiving said receive command at said application manager from said second application and routing said data to said second application.

4. The method recited in claim 3, wherein in steps j) and n) the corresponding application is notified that said data has arrived.

5. In a data processing system comprising a processor, a shared radio-frequency modem, and a memory for storing a plurality of applications and for storing a computer program to control the radio-frequency modem and permit simultaneous, independent interface by said modem to each of said applications by way of said commands, said computer program comprising:

a predetermined set of commands common to all of said applications, a plurality of said commands being incorporated into each of said applications, said commands being used to control communication between said applications and said computer program;

an application manager responsive to said plurality of commands from all of said applications, for executing said commands;

a queue manager responsive to said application manager, said queue manager comprising an emergency queue, regular queue, command queue, a plurality of in-bound message queues, and a plurality of in-bound response queues;

a message manager comprising a transmit task and a receive task, said transmit task being coupled to a first plurality of queues, said receive task being coupled to a second plurality of queues;

a device manager coupled between said message manager and a communications port, said device manager managing the transmission and receipt of data with respect to said communications port, and said device manager comprising a transmit buffer, a receive buffer, and a device state machine task;

a method for enabling said plurality of applications to send data simultaneously over said radio-frequency modem comprising the steps of:

a. issuing a send command from a first one of said applications to said application manager;

b. issuing a send command from a second one of said applications to said application manager;

c. receiving said send commands and corresponding data to be sent at said application manager from said applications and performing one of the following substeps for each of said send commands;

i. writing said data to said emergency queue, if data to be sent is a high priority message, or;

ii. writing said data to said regular queue, if data to be sent is a normal priority message, or;

iii. writing said data to said command queue, if data to be sent is a command to control said shared radio-frequency modem;

d. polling said emergency, regular, and command queues in said transmit task of said message manager for pending messages or commands by performing the following substeps in sequence:

i. checking said emergency queue for said high priority messages and sending said high priority messages to said device state machine task of said device manager;

ii. checking said regular queue for said normal priority messages and sending said normal priority messages to said device state machine task of said device manager;

iii. checking said command queue for said commands and sending said commands to said device state machine task of said device manager;

e. writing said messages or commands stored in said device state machine task into said transmit buffer of said device manager;

f. reading said buffer and writing said stored messages or commands to said shared radio-frequency modem via said communications port.

6. The method recited in claim 5, wherein in step (f) said buffer is read in a FIFO fashion.

7. In a data processing system comprising a processor, a shared radio-frequency modem, and a memory for storing a plurality of applications and for storing a computer program to control the radio-frequency modem and permit simultaneous, independent interface by said modem to each of said applications by way of said commands, said computer program comprising:

a predetermined set of commands common to all of said applications, a plurality of said commands being incorporated into each of said applications, said commands being used to control communication between said applications and said computer program;

an application manager responsive to said plurality of commands from all of said applications, for executing said commands;

a queue manager responsive to said application manager, said queue manager comprising an emergency queue, regular queue, command queue, a plurality of in-bound message queues, and a plurality of in-bound response queues;

a message manager comprising a transmit task and a receive task, said transmit task being coupled to a first plurality of queues, said receive task being coupled to a second plurality of queues;

a device manager coupled between said message manager and to a communications port, said device manager managing the transmission and receipt of data with respect to said communications port, and said device manager comprising a transmit buffer, a receive buffer, and a device state machine task;

a method for enabling said plurality of applications to receive data simultaneously over said radio-frequency modem comprising the steps of:

a. receiving first incoming data at said radio-frequency modem;

b. writing said first data into said device manager's receive buffer;

c. reading said first data from said receive buffer;

d. sending said first data into said message manager's receive task, and performing one of the following substeps:

i. placing said first data into a first one of said queue manager's in-bound message queues, if said data is a new incoming message;

ii. placing said first data into a first one of said queue manager's in-bound response queues, if said data is a response to a previously sent message of said one application;

e. holding said first data in said first in-bound message queue or said first in-bound response queue until a receive command is issued from said one application;

f. notifying the user that a message or response for said one application has arrived;

g. issuing a receive command from said one application to said application manager;

h. receiving said receive command at said application manager from said one application and routing said data to said one application.

8. The method recited in claim 7, wherein said data is written into said device manager's receive buffer in FIFO fashion.

9. The method recited in claim 7 and further comprising the steps of:

i. receiving second incoming data at said radio-frequency modem substantially concurrently with the receipt of said first incoming data; and

j. executing steps (b) through (h) substantially concurrently regarding said first and second incoming data.

10. The method recited in claim 7, wherein in step (f) said one application is notified that said data has arrived.

11. The method recited in claim 7, wherein for said one application there are a plurality of communication channels of, each of said channels comprising an inbound message queue and an inbound response queue in said queue manager.

Description

RELATED INVENTIONS

The present invention is related to the following inventions:

(1) "Method Of Data Communication For Radio Frequency Modems Requiring Different Communications Protocols", having Ser. No. 07/876,644, filed concurrently herewith, and assigned to the assignee of the present invention now abandoned.

(2) "Notification Method For Conserving Current Drain In A Radio Frequency Communication System", having Ser. No. 07/876,888, filed concurrently herewith, and assigned to the assignee of the present invention now abandoned.

(3) "Method For Asynchronous Application Communication", now U.S. Pat. No. 5,327,558, filed concurrently herewith, and assigned to the assignee of the present invention.

TECHNICAL FIELD

This invention relates generally to data communication and, in particular, to a method for controlling concurrent access to a shared data communication device by a plurality of data processing applications.

BACKGROUND OF THE INVENTION

Known technology supports access to a radio frequency (RF) data communication device by only one program at a time. Traditionally this has been done by using RF data communication devices as part of an embedded system. The user's equipment would include a special-purpose transceiver equipped with an RF data communication device (e.g. modem) and integrated software. This integrated software is programmed specifically to work with a particular RF modem. The software also has no provision for sharing the communication device with other software applications executing on the user's equipment.

Many contemporary general-purpose subscriber units (e.g. portable computers) allow several programs to run at once. This is called multi-tasking. Currently, there is no means for a portable computer operating in a multi-tasking mode to conduct RF communication via a single shared RF communication device. There is a significant need for such capability in the art.

For example, a user running several software applications simultaneously could receive stock quotes, while sharing spreadsheet data with another user, and sending two-way messages with yet a different user. Under these conditions, the RF data communication device becomes a shared resource, and communication activities initiated by one program impact those initiated by another program.

Software application developers do not usually build specialized knowledge of unrelated programs into their own software application. The interaction between unrelated, communicating programs often causes communication malfunctions, effectively rendering the communication device inoperative. Therefore, there is a significant need in the area of radio frequency data communication to provide a shared program to perform communication device-related functions on behalf of multiple concurrently executing software applications.

SUMMARY OF THE INVENTION

The present invention has utility in managing radio RF data communication via a shared RF data communication device being accessed by multiple software programs simultaneously.

In the present invention there is provided a method of data communication in which a shared radio frequency communication device is managed in a way to allow for simultaneous access by multiple concurrently executing software applications. This is a significant advantage over the current technology of supporting only single, exclusive access to such a communication device. Such embedded systems are limited to a specialized software application and require knowledge of communication protocols in order to be developed.

Thus it is an advantage of the present invention to provide a method by which multiple concurrently executing software applications may share and utilize a single communication device.

It is also an advantage of the present invention to provide a consistent high-level software interface to the shared communication device.

Yet another advantage of the present invention is to provide real-time and communication management functions, thereby allowing software application development by general programmers rather than by communication specialists.

According to one aspect of the invention, a data communication method is provided for controlling access to a shared radio frequency communication device by a number of software applications simultaneously. In a data processing system comprising a processor, a memory for storing a plurality of software applications, and a shared radio-frequency modem, a method for managing the shared radio-frequency modem comprising: (a) providing one predetermined interface in the form of a command set common to all of the software applications; and (b) providing a single computer program that controls the radio-frequency modem and permits simultaneous, independent interface to each of the software applications by way of the predetermined set of commands.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is pointed out with particularity in the appended claims. However, other features of the invention will become more apparent and the invention will be best understood by referring to the following detailed description in conjunction with the accompanying drawings in which:

FIG. 1 shows a block diagram depicting a pair of transceivers communicating via radio frequency with a communications infrastructure in accordance with one aspect of the invention.

FIG. 2 shows a block diagram of a data processing portion of a communications device in accordance with a preferred embodiment of the invention.

FIG. 3 shows a functional block diagram of a method for controlling concurrent access to a shared data communication device in accordance with a preferred embodiment of the invention.

FIGS. 4 and 5 together show a more detailed functional block diagram of a method for controlling concurrent access to a shared data communication device in accordance with a preferred embodiment of the invention.

FIG. 6 shows a procedure call-tree for the routine HANDLE SESSION MANAGEMENT in accordance with a preferred embodiment of the invention.

FIG. 7 shows a procedure call-tree for the routine PERFORM THE SESSION MANAGER START UP in accordance with a preferred embodiment of the invention.

FIG. 8 shows a procedure call-tree for the routine GET SECOND LOAD STATUS in accordance with a preferred embodiment of the invention.

FIG. 9 shows a procedure call-tree for the routine GET HARDWARE INFORMATION in accordance with a preferred embodiment of the invention.

FIG. 10 shows a procedure call-tree for the routine GET MEMORY INFORMATION in accordance with a preferred embodiment of the invention.

FIG. 11 shows a procedure call-tree for the routine GET DISPLAY ADAPTER INFORMATION in accordance with a preferred embodiment of the invention.

FIG. 12 shows a procedure call-tree for the routine GET COMM PORT INFORMATION in accordance with a preferred embodiment of the invention.

FIG. 13 shows a procedure call-tree for the routine INITIALIZE SESSION MANAGER DATA in accordance with a preferred embodiment of the invention.

FIG. 14 shows a procedure call-tree for the routine ALLOCATE OUTBOUND MESSAGE QUEUES in accordance with a preferred embodiment of the invention.

FIG. 15 shows a procedure call-tree for the routine SETUP, CLEAN UP, AND PREPARE SESSION.sub.-- MGR TO TERMINATE AND STAY RESIDENT in accordance with a preferred embodiment of the invention.

FIG. 16 shows a procedure call-tree for the routine HANDLE APPLICATION SERVICE REQUESTS in accordance with a preferred embodiment of the invention.

FIG. 17 shows a procedure call-tree for the routine HANDLE MAILBOX API SERVICE REQUESTS in accordance with a preferred embodiment of the invention.

FIG. 18 shows a procedure call-tree for the routine HANDLE NOTIFICATION SERVICE REQUESTS in accordance with a preferred embodiment of the invention.

FIG. 19 shows a procedure call-tree for the routine HANDLE SESSION MANAGER SHUTDOWN REQUESTS in accordance with a preferred embodiment of the invention.

FIG. 20 shows a block diagram depicting a pair of transceivers communicating via direct radio frequency signals in accordance with another embodiment of the invention.

FIG. 21 shows a block diagram depicting a pair of transceivers communicating via telephone line in accordance with another embodiment of the invention.

FIG. 22 shows a block diagram depicting a pair of transceivers communicating via direct wire line in accordance with another embodiment of the invention.

FIG. 23 shows a block diagram depicting a pair of transceivers communicating via infra-red communication links in accordance with another embodiment of the invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

FIG. 1 shows a block diagram depicting a pair of transceivers 1 and 2 communicating via radio frequency (RF) with a communications infrastructure 3 in accordance with a preferred embodiment of the invention. Device 1 sends and receives RF signals 4 to and from communications infrastructure 3 via modem 6. Communications infrastructure 3 sends and receives RF signals 5 to and from device 2 via modem 7. In this way data is transferred between devices 1 and 2.

FIG. 2 shows a block diagram of a data processing portion of a communications device in accordance with a preferred embodiment of the invention. The data processing portion is used to carry out the method and comprises central processing unit (CPU) 10, random access memory (RAM) 8, read only memory (ROM) 9, data entry means 11, display 12, and input/output (I/O) terminal 13. Data entry means 11 and display 12 may be any appropriate type to enable a system user to enter data and commands into the system and to receive information from the system. Likewise, CPU 10, RAM 8, and ROM 9 are of suitable design depending upon the system requirements. Data and control information is output to and input from suitable communications equipment (not shown), such as a wire-line modem or RF modem via I/O terminal 13.

FIG. 3 shows a functional block diagram of a method for controlling concurrent access to a shared data communication device in accordance with a preferred embodiment of the invention. Different software applications, 20 and 22, are linked to libraries, 24 and 26, of communication routines. The libraries, 24 and 26, allow programs written in a specific programming language to access a communication device through a predetermined set of function calls, as will be explained in greater detail below.

The library comprises a set of functions which are called from within an application. In a preferred embodiment the set of library functions comprises functions such as open.sub.-- session, close.sub.-- session, get.sub.-- message, send.sub.-- message, get.sub.-- number.sub.-- messages, get.sub.-- notification.sub.-- config, set.sub.-- notification.sub.-- configuration, and get.sub.-- number.sub.-- messages. It will be apparent that other library functions may be substituted or added if desired.

The interface between the multiple software applications, 20 and 22, and the libraries, 24 and 26, constitutes the Application Programmer's Interface (API), which defines a set of conventions for collaboration between a software application (e.g., 20) and the Session Manager 28. These conventions take the form of descriptions of communication subroutines and their parameters for a specific programming language, such as `C`.

The library embodies knowledge both of the programming language in which the corresponding application 20 or 22 is coded, and knowledge of the interface between itself and the Session Manager 28. In the event that both applications are coded in a single programming language (e.g. the `C` programming language), libraries 24 and 26 are identical in both general and specific detail; under these conditions libraries 24 and 26 may be equivalently replaced by a single, shared library (in another embodiment of the invention, not shown in FIG. 3). In the event that each application is coded in a unique programming language (e.g. box 20 is a `C` application and box 22 is a `C++` application using an incompatible compiler) library 24 and library 26 differ from one another in detail but serve equivalent purposes (i.e. embody equivalent API's) for each programming language.

The API describes how software applications 20 and 22 communicate using the invention. The library 24 and 26 is a software component, which is linked to a software application that needs to communicate; it converts interface conventions (the API) from a specific programming language into messages that can be passed to the Session Manager 28 using a prescribed operating system, such as MS-DOS (commercially available from Microsoft Corp., Redmond, Wash.), and a prescribed inter-process communication technique, such as software interrupts.

The Session Manager 28 manages all interaction with a shared data communication device 30 and provides the functionality necessary to share the device among several software applications 20 and 22. The Session Manager accepts a message from the library 24 and 26 and responds by scheduling and performing a communication function described in the message. A response is then passed back to the software application 20 and 22.

The Session Manager 28 comprises the Message Manager 43, the API Manager 44, the Configuration Manager 45, the Queue Manager 47, the Notification Manager 40, and the Device Manager 48. These modules work together to provide the queuing, scheduling, and control to enable the Shared Data Communication Device 30 to be shared between software applications 20 and 22, as will be explained in further detail below.

FIGS. 4 and 5 together show a more detailed functional block diagram of a method for controlling concurrent access to a shared data communication device in accordance with a preferred embodiment of the invention.

Referring first to FIG. 4, application 20 interfaces to library 24 via a predetermined set of commands. Library 24 passes data and control information to Session Manager 28 by way of API Manager 44.

API Manager 44 comprises the API Interrupt Service Routine (ISR) 116 which receives in-bound messages and in-bound responses from Queue Manager 47. The API ISR 116 also sends messages with the priorities "emergency" or "regular" and passes modem control commands (such as Hayes.RTM. Standard AT commands) to the Queue Manager 47. The API ISR 116 also sets Notification Attributes 123 in the Notification Manager 40.

The Configuration Manager 45 comprises the Initialization Task 121 and Configuration Data store 122. The Initialization Task 121 reads session attribute data from the Configuration File 120, registers with the Operating System 119 as a Terminate and Stay Resident (TSR) program and writes session attribute data (e.g. baud rate) to Configuration Data store 122. The Initialization Task 121 also initializes the shared communication device via the Device Manager 48 and sets the default attributes in the Notification Attributes data store 123 in the Notification Manager 40.

The Notification Manager 40 comprises the Notification Attributes data store 123, the Notification Task 124, and the Notification Messages data store 125. The Notification Task 124 is periodically scheduled to run by the Scheduler 102, in order to facilitate the control switch between this task and others running on the data processor. The Notification Task 124 reads data from the Notification Attributes data store 123 and reads notification messages from the Notification Messages data store 125. The Notification Task 124 can display a notification message to the User 126. The User 126 can acknowledge the receipt of the notification message by sending a response (e.g. pressing a key on the keyboard) to the Notification Task 124.

The Queue Manager 47 comprises queues 109-110 for in-bound messages, queues 111-112 for in-bound responses to previously sent messages, a data store 115 for out-bound emergency priority messages, a data store 114 for out-bound regular priority messages, and a data store 113 for Hayes.RTM. Standard AT commands used to control the shared communication device. For each session a set of in-bound queues (IB Msgs. 109-110 and IB Resps. 111-112) is allocated. Each application 20, 22 can open multiple sessions, and the Session Manager 28 can support multiple applications 20, 22.

The in-bound message queues 109-110 receive messages from the Receive Task 107 of Message Manager 43 (FIG. 5). The API Manager 44 retrieves the messages in a first-in-first-out (FIFO) manner from the in-bound message queues 109-110. The in-bound message response queues 111-112 receive message responses from the Receive Task 107 of Message Manager 43. The API Manager 44 retrieves the messages in a first-in-first-out (FIFO) manner from the in-bound message response queues 111-112.

The emergency message data store 115 receives emergency messages from the API Manager 44 and stores them for retrieval by the Transmit Task 108 of the Message Manager 43. The regular message data store 114 receives regular messages from the API Manager 44 and stores them for retrieval by the Transmit Task 108 of the Message Manager 43. The AT Commands data store 113 receives Hayes.RTM. Standard AT commands from the API Manager 44 and stores them for retrieval by the Transmit Task 108 in the Message Manager 43. The AT Commands data store 113 receives device shutdown commands from the Shutdown Interrupt Service Routine (ISR) 127 and stores them for retrieval by the Transmit Task 108 in the Message Manager 43.

Regarding FIG. 5 now, the Message Manager 43 comprises a Receive Task 107 and a Transmit Task 108. The Receive Task 107 retrieves data from the Device Manager 48 and routes the data to the in-bound message queue 109-110 or the in-bound message response queue 111-112 of the Device Manager 48. The Receive Task also writes notification messages to the Notification Manager 40.

The Transmit Task 108 retrieves regular and emergency messages, and Hayes.RTM. Standard AT commands, from the Queue Manager 47 and passes them on to the Device Manager 48. The Message Manager 43 is periodically scheduled to run by a Scheduler 102 interrupt to facilitate the control switch between the Receive and Transmit Tasks.

The Device Manager 48 comprises a Communication (COM) Interrupt Service Routine (ISR) 103, a Receive Buffer 104, a Transmit Buffer 105, and a Device State Machine Task 106. The Device State Machine Task 106 is driven by the Scheduler 102 and controls the message traffic from the Message Manager 43 to/from the Transmit Buffer 105 and the Receive Buffer 104, respectively.

The Device State Machine Task 106 sends commands to the COM ISR 103. The COM ISR 103 sends/receives data bytes to/from the Communication Port 101 and issues/handles hardware interrupts to/from the Communication Port 101. Communication Port 101 is connected to the Shared Data Comm Device 30 via I/O terminal 13.

Box SESS.sub.-- MGR

The pseudo-code listing for FIG. 6, a procedure call-tree for the routine HANDLE SESSION MANAGEMENT 201, contains an implementation in pseudo-code of a preferred embodiment of the present invention. The procedure HANDLE SESSION MANAGEMENT 201 calls one or more of the sub-procedures, PERFORM THE SESSION MANAGER START UP 202, HANDLE INBOUND MESSAGES 203, HANDLE SERIAL PORT INTERRUPTS 204, HANDLE OUTBOUND MESSAGES 205, HANDLE APPLICATION SERVICE REQUESTS 206, HANDLE SESSION MANAGER SHUTDOWN REQUESTS 207, and HANDLE APPLICATION NOTIFICATION SERVICE 208, depending on what type interrupt is received.

    ______________________________________
    /* Startup and load session manager */
    PERFORM THE SESSION MANAGER START UP ›A!
    /* Terminate and Stay Resident */
    Exit
    /* when an interrupt occurs wake up and process */
    CASE OF interrupt DO
     CASE scheduler interrupt :
      IF scheduler interrupt is for "received messages"
       THEN
        HANDLE INBOUND MESSAGES ›B!
      ENDIF
      IF scheduler interrupt is for "sending messages"
       THEN
        HANDLE OUTBOUND MESSAGES ›D!
      ENDIF
      IF scheduler interrupt is for "application notification"
       THEN
        HANDLE APPLICATION NOTIFICATION SERVICE ›G!
      ENDIF ENDCASE
     CASE serial port interrupt :
      HANDLE SERIAL PORT INTERRUPTS ›C!
     CASE application interrupt :
      HANDLE APPLICATION SERVICE REQUESTS ›E!
     CASE user interrupt/hot-key combination :
      HANDLE SESSION MANAGER SHUTDOWN REQUEST ›F!
     OTHERS :
      treat error
    ENDCASE
    ______________________________________

    __________________________________________________________________________
    GET SECOND   LOAD STATUS   ›A!
    READ SESSION   MANAGER   CONFIGURATION   FILE   ›B!
    GET HARDWARE   INFORMATION   ›C!
    INITIALIZE   SESSION   MANAGER   DATA   ›E!
    SETUP,CLEAN UP AND PREPARE SESSION.sub.-- MGR TO TERMINATE AND STAY
    RESIDENT ›F!
    DISPLAY SIGNON SCREEN   ›G!
    __________________________________________________________________________

    __________________________________________________________________________
    already.sub.-- loaded = CHECK FOR   SECOND LOAD OF   THE SESSION
    MANAGER   ›A!
    IF already.sub.-- loaded
    THEN DISPLAY SECOND   LOAD MESSAGE   ›B!
           exit
    ENDIF
    __________________________________________________________________________

    ______________________________________
    IF Open session manager configuration file = OK
    THEN
    Allocate data structure for session manager configuration data
    Read global parameters
    Hot-key character
    Communication parameters(COM Port, Baud rate)
    Size of inbound queue (i.e. maximum number of stored messages)
    Read applications' configuration:
    Application's session name
    Notification attributes (pop-up, tone, interval)
    Fixed user header
    ELSE
    Display error message
    exit
    ENDIF
    ______________________________________

    ______________________________________
    GET MEMORY INFORMATION ›A!
    GET DISPLAY ADAPTER INFORMATION ›C!
    GET PC TYPE ›D!
    GET COMM PORT INFORMATION ›E!
    ______________________________________

    ______________________________________
    /* Check whether memory minimal requirements are met */
    GET MEMORY   SIZE   ›A!
    GET MEMORY   CONFIGURATION   ›B!
    IF not enough memory available
    THEN
             display error message
             exit
    ENDIF
    ______________________________________

    ______________________________________
    Get total memory size available for user applications,
    i.e. maximum memory minus the memory size occupied by
    DOS, TSR's etc.
    ______________________________________

    ______________________________________
    Get the current configuration of memory
             main memory
             expended memory
    ______________________________________

    __________________________________________________________________________
    GET DISPLAY   ADAPTER TYPE   ›A!   : may be MDA,CGA,EGA,MCGA,VGA
    GET DISPLAY ADAPTER MODE   ›B!   : TEXT,GRAPHICS (BW40,BW80,C040,C080)
    No specific/minimal requirement for the display type and mode
    Save original display setting in order to restore it once session
    manager
    is terminated
    __________________________________________________________________________

    ______________________________________
    Possible PC types that are PC,XT,AT,XT286
    IF the PC type == PC
             THEN
                Display error message
                exit
    ENDIF
    ______________________________________

    ______________________________________
    GET COMM PORT  ADDRESSES   ›A!   : COM1,COM2 etc.
    GET COMM PORT  CONFIGURATION   ›B! : Baud rate,stop
    bit,parity etc.
    IF no serial port is available
    THEN
    Display an error message
    exit
    ENDIF
    Save original serial port configuration in order to restore it once
    session manager is removed
    ______________________________________

    __________________________________________________________________________
    ALLOCATE   INBOUND   MESSAGE QUEUES   FOR ALL CONFIG   SESSIONS   ›A!
    ALLOCATE   OUTBOUND   MESSAGE QUEUES   ›C!
    INITIALIZE   SCHEDULER   EVENTS LIST   ›E!
    INITIALIZE   SOFTWARE TRAPS   LIST   ›F!
    __________________________________________________________________________

    ______________________________________
    All sessions' inbound queues are handled in one pool.
    Messages of a session are kept in a linked list.
    Two pointers point to the head and tail of the memory pool.
    A message is read from the serial port only if there is enough queue
    pool
    memory to store it(space is reserved for at least one message of
    maximum size i.e. 2K)
    For each queue the following information is kept:
    Number of messages in the queue
    Number of bytes occupied by the queue messages
    Pointer to the queue start
    Each message is composed of the actual data and an extra word pointing
    to
    the next message in the queue.
    Once the queue is full no more messages are read from the serial port,
    letting the Shared Data Communication Device 30 (FIG. 5)
    NAK messages as its queues are overflown.
    A message is issued to the user suggesting that no more room for
    messages is available in the session manager queues and unless an
    application reads some of the waiting messages, new incoming host
    messages will be NAKed.
    In the case of a graceful shutdown, all queue content is saved into
    files
    to be restored in case that the session manager is activated
    ______________________________________
    again.

    __________________________________________________________________________
    ALLOCATE   A SEND QUEUE   (REGULAR MESSAGES)   ›A!
    IF memory allocation error
    THEN
    Display error message
    exit
    ENDIF
    ALLOCATE AN   EMERGENCY QUEUE   (PRIORITY   MESSAGES)   ›B!
    IF memory allocation error
    THEN
    Display error message
    exit
    ENDIF
    __________________________________________________________________________

    ______________________________________
    Outbound messages are kept in a linked list.
    Two pointers point to the head and tail of the memory pool allocated for
    the queue
    A message is accepted and stored in this queue only if there is enough
    memory for it, otherwise the session manager will return an error
    status code to the application
    For each queue the following information is kept:
    Number of messages in the queue
    Number of bytes occupied by the queue messages
    Pointer to the queue start
    Each message is composed of the actuai data and an extra word pointing
    to
    the next message in the queue.
    When the queue is full no more messages are stored in it, letting the
    session manager NAK the application "send" requests
    A message is issued to the user indicating that something is wrong (host
    not available, Shared Data Communication Device 30 (FIG. 5) low
    battery, etc.)
    Unless some action is taken to fix the problem source no messages will
    be
    stored by the session manager to be sent to the host.
    In case of graceful shutdown all queue content is saved into a file to
    be
    restored in case the session manager is activated again.
    ______________________________________

    ______________________________________
    Same as in function ALLOCATE A SEND QUEUE (REGULAR
    MESSAGES)
    ______________________________________

    ______________________________________
    Call CodeRunneR's INSTALL.sub.-- SCH(service,stack.sub.-- size,lock.sub.--
     mask)
    in order to activate the scheduler
    ______________________________________

    ______________________________________
    Call CodeRunneR's INSTALL.sub.-- TRAP (trap.sub.-- service,stack.sub.--
    size,
    lock.sub.-- mask) in order to make software traps handling
    ______________________________________
    available

    __________________________________________________________________________
    ENABLE SERIAL PORT INT'S HANDLED BY THE SERIAL PORT MANAGER TASK
    __________________________________________________________________________
    ›A!

    ______________________________________
    Initialize the serial port setting all the related parameters (baud,
    parity,
    stop bits etc.)
    ______________________________________

    ______________________________________
    The sign on screen is displayed once the program is terminated and stays
    resident.
    The sign on screen is the product logo.
    In the sign on screen, the name of the product and the version number is
    displayed.
    ______________________________________

    ______________________________________
    /* When EXIT is used this routine Terminates and Stays Resident until
    next event resumes it */
    UPON INTERRUPT from the scheduler (periodic)
     EXECUTE
      IF no serial data is available (flag is set)
       THEN exit
      ENDIF
      start.sub.-- session = current.sub.-- session
      REPEAT
        In local command mode query a predetermined register to get
        number of waiting messages for the session
        IF no waiting messages THEN
        THEN
         set current.sub.-- session to the next session
        ELSE /* Messages are waiting so process these messages */
         Go on-line for the current session
          (which is already at handshake mode)
         Delay for X time
          (In order to let the Shared Data Communication Device 30
          (FIG. 5) send automatically stored session's
          messages to the DTE)
         WHILE (DTE receive buffer is not empty)
          DO
           Read message (Which may be response or data)
           Copy message into the session queue on the DTE
           Update queue counters, pointers etc.
         ENDWHILE
         Go off-line into local command mode
         Create a notification data structure for the current session
          Name of application to notify
          Session number which is being used by the application
          Number of waiting messages
         IF direct notification set for current session
          THEN
           Notify the foreground application directly
            (setting a flag, using an interrupt call,...)
         ENDIF
         Set a notification event for the notification routine
          (To perform the indirect notification)
         Set current.sub.-- session to the next session in the cycle
         Unblock the serial port
         exit /* Hibernate until next time being executed */
        ENDIF
       UNTIL ( current.sub.-- session EQ start.sub.-- session )
      ENDUNTIL
    ENDEXECUTE
    ______________________________________

    ______________________________________
     UPON INTERRUPT from serial port
      EXECUTE
      CASE OF serial port interrupt DO
       CASE transmit ready :
        Next byte from the transmit buffer is transmitted
       CASE received byte :
        Byte is read and stored into the next free slot in the receive
        buffer
        Set a flag to specify the arrival of serial data
      ENDCASE
    ENDEXECUTE
    ______________________________________

    ______________________________________
    COMMENT
      An event is set to resume this task once the user application
      issues a "send message" service request. The scheduled event will
      resume this task only if the CPU is free, otherwise it will occur each
      clock tick until the CPU is released
    ENDCOMMENT
    /*when EXIT is used this routine exits until the next scheduler event
     resumes it */
    UPON INTERRUPT from the scheduler
     EXECUTE
      /* First handle emergency messages queue */
      IF emergency queue is not empty
        Get message from queue
        Send the message to the shared data communication device
        Get return status specifying that the message was successfully
        sent to the shared data communication device
        Update emergency queue related variables/counters
         (# of messages, # of bytes used, head & tail pointers etc.)
        Discard message from queue
        EXIT
      ENDIF
      /* Handle non-emergency messages queue */
      IF send queue is not empty
        Get message from queue
        Send the message to the shared data communication device
        Get return status specifying that the message was successfully
         sent to the shared data communication device
        Update send queue related variables/counters
         (# of messages, # of bytes used, head & tail pointers etc.)
        Discard message from queue
        EXIT
      ENDIF
    ENDEXECUTE
    ______________________________________

    ______________________________________
    IF application request is message related
      THEN
       HANDLE MESSAGE RELATED SERVICE REQUESTS ›A!
    ENDIF
    IF application request is notification related
      THEN
       HANDLE NOTIFICATION RELATED SERVICE REQUESTS ›B!
    ENDID
    ______________________________________

    ______________________________________
    CASE OF request type DO
     CASE open   :
      OPEN SESSION ›A!
     CASE close   :
      CLOSE SESSION ›B!
     CASE delete  :
      DELETE SESSION ›C!
     CASE send   :
      SEND MESSAGE ›D!
     CASE get   :
      GET MESSAGE ›E!
     CASE status  :
      GET SESSION STATUS ›F!
    ENDCASE
    ______________________________________

    ______________________________________
    Open an application's session and mark it active
    Allocate and initiate session queues
    Return a session handle
    ______________________________________

    ______________________________________
    Use a session handle to mark the session suspended
    Keep handling session queues and inbound (received) messages
    ______________________________________

    ______________________________________
    Identify session by its handle and mark it deleted
    Empty all session queues and deallocate queue's memory
    /* All queued messages are lost */
    The user is requested to confirm session deletion
    ______________________________________

    ______________________________________
    Get a data buffer to be sent as a message
    Copy the data buffer content into a local data buffer
    Store the message in the proper session's queue according to priority
    (i.e.
    emergency, regular)
    ______________________________________

    ______________________________________
    Get a message (if one exists) from the proper session's queue (i.e. a
    message or response)
    Copy the message to the application's data buffer allocated by the
    application
    Discard message from the local queues
    ______________________________________

    ______________________________________
    Return status information regarding the session, such as number of
    stored
    messages in each queue, session active/suspended status,
    ______________________________________
    etc.

    ______________________________________
    CASE OF request type DO
     CASE set parameters :
      SET NOTIFICATION PARAMETERS ›A!
     CASE get status    :
      GET NOTIFICATION STATUS AND PARAMETERS ›B!
    ENDCASE
    ______________________________________

    ______________________________________
    Get the new values for the notification attributes such as visual
    notification, audible notification, and direct notification
    Store the values in the Session Manager configuration record
    ______________________________________

    ______________________________________
    Fetch the requested value of a notification attribute from the Session
    Manager configuration record.
    Return the requested attribute to the requesting application.
    ______________________________________

    ______________________________________
    /* Handle active session shutdown */
    IF there is/are any active session(s)
     THEN
      TERMINATE AND QUIT ALL SESSIONS ›A!
      STORE INBOUND QUEUES' MESSAGES TO DISK FILES ›B!
      STORE OUTBOUND QUEUES' MESSAGES TO DISK FILES ›C!
    ENDIF
    /* Restore the PC to its original configuration */
    RESTORE SERIAL PORT ORIGINAL CONFIGURATION ›D!
    RESTORE DISPLAY ORIGINAL CONFIGURATION ›E!
    /* Free memory occupied by the session manager */
    UNLOAD SESSION MANAGER ›G!
    ______________________________________

    ______________________________________
    COMMENT
      Notification data is prepared by the Message Manager Receive Task
      as messages are being received for a session. This data is
      placed in a predetermined memory location which is accessible to this
      function.
    ENDCOMMENT
    UPON INTERRUPT from the scheduler indicating to invoke the
    Notification Manager
     EXECUTE
      Get the current notification data structure
       (application name, session number, number of waiting messages)
      IF Direct notification is enabled for the application
       THEN
        Set direct notification flag in the application address space or
        call a dedicated call-back routine designated by the application
        to handle its notification events.
       ELSE
      ENDIF
      Look-up in Notification Attribute data store what attributes to set
      for the indirect notification (pop-up, tone, interval)
    ENDEXECUTE
    ______________________________________

• Inventors
  Burke, Christopher John; Nir, Erez; Chaffee, Janice Marie;
• Assignee
  Motorola, Inc. (Schaumburg, IL)
• Published
  Feb-3-1998
• Current US Classes:
  710/21
  710/6
  719/328
• Application #
  876662
• International Classes
  G06F 013/38
• Field of Search
  395/650 395/250 395/200.12 395/200.2 395/892 395/826 395/700 395/825 395/827 395/840 395/841 395/682 370/389 370/402
• Examiner
  Dung; Dinh C.
• Agent
  Maddox; Donna Rogers
• US Patent References:
  4363093
  4754395
  4768150
  4835685
  5012409
  5016161
  5136718
  5166930
  5325361
  5327558