Method and system for providing a state oriented and event driven environment

Abstract

The present invention discloses a method and system for providing a Finite State Machine (FSM) which is implemented within a telecommunications application program with the ability to transition from one state to another. The control of the transition being implemented by an Input/Output (I/O) Event Manager subsystem of a preemptive multi-tasking operating system. Additionally, the present invention discloses a method and system for providing a FSM which is implemented within a telecommunications application program with event driven control of physical devices having input and output capabilities. The event driven control being implemented by the I/O Event Manager subsystem.

Claims

What is claimed is:

1. A method of implementing transitions from one state to another within a finite state machine being implemented by an application program executing on an operating system comprising an Input/Output (I/O) Event Manager subsystem, the finite state machine having at least one process within the operating system, the method comprising the steps of:

implementing each individual state of the finite state machine in a main state processing function within the application program;

creating a state vector table within the application program, the state vector table forming a single dimensioned array having a plurality of elements each one of which contains a physical address for a corresponding state of the finite state machine;

requesting from the I/O Event Manager subsystem an assignment of a state control block to the finite state machine, the state control block identifying a single one of the at least one process;

requesting from the I/O Event Manager subsystem a transition from a first state to a second state of the finite state machine; and

directing the identified process from the first state to the second state of the finite state machine with the I/O Event Manager subsystem.

2. The method of claim 1 wherein the step of creating a state vector table includes the step of:

creating a state vector table within the application program, the state vector table forming a single dimensioned array having a plurality of elements each one of which contains a physical address for a state having a sequence within the finite state machine which has a one-to-one correspondence with the sequence of the element within the state vector table.

3. The method of claim 2 wherein the step of requesting from the I/O Event Manager subsystem an assignment of a state control block to the finite state machine includes the step of:

storing a pointer to the identified process within the state control block.

4. The method of claim 3 further including the step of:

storing a pointer to the state vector table within the assigned state control block.

5. The method of claim 4 wherein the step of directing includes the steps of:

accessing the state control block to locate the identified process and the state vector table;

retrieving a stack within the operating system which is associated with the identified process;

retrieving the physical address for the second state from the state vector table; and

pushing the retrieved physical address onto the retrieved stack, thereby performing the requested transition by directing the identified process from the first state to the second state of the finite state machine.

6. The method of claim 5 wherein the operating system is a multi-tasking operating system.

7. The method of claim 5 wherein the operating system is a preemptive multi-tasking operating system.

8. The method of claim 5 wherein the operating system is executing within a telecommunications switch.

9. The method of claim 6 wherein the multi-tasking operating system is executing within a telecommunications switch.

10. A method of providing an application program with event driven control over the inputs and outputs of a hardware device, the application program executing on an operating system comprising an Input/Output Event Manager subsystem and having at least one process associated with the application program, the I/O Event Manager Subsystem using a device driver to communicate with the hardware device and supporting a plurality of types of event waiting, the method comprising the steps of:

receiving within the I/O Event Manager subsystem an Input/Output (I/O) request from the application program, the I/O request including a specification for one of the plurality of types of event waiting and an event of one of the inputs or outputs of the hardware device;

assigning an event control block to the I/O request with the I/O Event Manager subsystem;

storing the specified type of event waiting, the specified event, and an identification of a single one of the at least one process in the assigned event control block;

transmitting the event control block to the device driver;

receiving the event control block in the I/O Event Manager subsystem from the device driver after the specified event has occurred; and

manipulating the identified process with the I/O Event Manager subsystem to implement the specified type of event waiting thereby providing event driven control over the inputs and outputs of the hardware device.

11. The method of claim 10 wherein the specified type of event waiting is passive.

12. The method of claim 11 wherein the step of transmitting includes the step of:

suspending the identified process.

13. The method of claim 12 wherein the step of manipulating includes the step of:

reactivating the suspended process.

14. The method of claim 10 wherein the specified type of event waiting is redirection.

15. The method of claim 14 wherein the step of manipulating includes the step of:

redirecting the identified process to another location within the application program.

16. The method of claim 10 wherein the specified type of event waiting is active.

17. The method of claim 16 wherein the step of manipulating includes the step of:

redirecting the identified process to a location where the I/O request was made.

18. The method of claim 10 wherein a plurality of event control blocks are dynamically created during the initialization of the I/O Event Manager subsystem.

19. The method of claim 10 wherein the operating system is a multi-tasking operating system.

20. The method of claim 11 wherein the operating system is a preemptive multi-tasking operating system.

21. The method of claim 19 wherein the multi-tasking operating system is executing within a telecommunications switch.

22. A method of creating a device driver for providing event driven control over the inputs and outputs of a hardware device for an Input/Output (I/O) Event Manager subsystem of an operating system, the method comprising the steps of:

creating a plurality of input assembly functions each one of which controls one of the inputs of the hardware device;

creating a plurality of output assembly functions each one of which controls one of the outputs of the hardware device;

storing the input and output assembly functions in a first file;

creating an input state machine which monitors and retrieves data from the inputs of the hardware device by executing the input assembly functions;

creating an output state machine which monitors and transmits data to the outputs of the hardware device by executing the output assembly functions;

storing the input and output state machines in a second file;

creating a plurality of system interface functions each one of which controls both the input and output state machines;

storing the plurality of system interface functions in a third file;

inserting the physical location of each one of the system interface functions into a device vector table;

providing the I/O Event Manager access to the device vector table; and

providing the device driver access to the I/O Event Manager.

23. An apparatus for implementing transitions from one state to another within a finite state machine being implemented by an application program executing on an operating system comprising an Input/Output (I/O) Event Manager subsystem, the finite state machine having at least one process within the operating system, the apparatus comprising:

means for implementing each individual state of the finite state machine in a main state processing function within the application program;

means for creating a state vector table within the application program, the state vector table forming a single dimensioned array having a plurality of elements each one of which contains a physical address for a corresponding state of the finite state machine;

means for requesting from the I/O Event Manager subsystem an assignment of a state control block to the finite state machine, the state control block identifying a single one of the at least one process;

means for requesting from the I/O Event Manager subsystem a transition from a first state to a second state of the finite state machine; and

means for directing the identified process from the first state to the second state of the finite state machine with the I/O Event Manager subsystem.

24. The apparatus of claim 23 wherein the means for creating a state vector table includes:

means for creating a state vector table within the application program, the state vector table forming a single dimensioned array having a plurality of elements each one of which contains a physical address for a state having a sequence within the finite state machine which has a one-to-one correspondence with the sequence of the element within the state vector table.

25. The apparatus of claim 24 wherein the means for requesting from the I/O Event Manager subsystem an assignment of a state control block to the finite state machine includes:

means for storing a pointer to the identified process within the state control block.

26. The apparatus of claim 25 further including:

means for storing a pointer to the state vector table within the assigned state control block.

27. The apparatus of claim 26 wherein the means for directing includes:

means for accessing the state control block to locate the identified process and the state vector table;

means for retrieving a stack within the operating system which is associated with the identified process;

means for retrieving the physical address for the second state from the state vector table; and

means for pushing the retrieved physical address onto the retrieved stack, thereby performing the requested transition by directing the identified process from the first state to the second state of the finite state machine.

28. The apparatus of claim 27 wherein the operating system is a multi-tasking operating system.

29. The apparatus of claim 27 wherein the operating system is a preemptive multi-tasking operating system.

30. The apparatus of claim 27 wherein the operating system is executing within a telecommunications switch.

31. The apparatus of claim 29 wherein the multi-tasking operating system is executing within a telecommunications switch.

32. An apparatus of providing an application program with event driven control over the inputs and outputs of a hardware device, the application program executing on an operating system comprising an Input/Output Event Manager subsystem and having at least one process associated with the application program, the I/O Event Manager Subsystem using a device driver to communicate with the hardware device and supporting a plurality of types of event waiting, the apparatus comprising:

means for receiving within the I/O Event Manager subsystem an Input/Output (I/O) request from the application program, the I/O request including a specification for one of the plurality of types of event waiting and an event of one of the inputs or outputs of the hardware device;

means for assigning an event control block to the I/O request with the I/O Event Manager subsystem;

means for storing the specified type of event waiting, the specified event, and an identification of a single one of the at least one process in the assigned event control block;

means for transmitting the event control block to the device driver;

means for receiving the event control block in the I/O Event Manager subsystem from the device driver after the specified event has occurred; and

means for manipulating the identified process with the I/O Event Manager subsystem to implement the specified type of event waiting thereby providing event driven control over the inputs and outputs of the hardware device.

33. The apparatus of claim 32 wherein the specified type of event waiting is passive.

34. The apparatus of claim 33 wherein the means for transmitting includes:

means for suspending the identified process.

35. The apparatus of claim 34 wherein the means for manipulating includes:

means for reactivating the suspended process.

36. The apparatus of claim 32 wherein the specified type of event waiting is redirection.

37. The apparatus of claim 36 wherein the means for manipulating includes:

means for redirecting the identified process to another location within the application program.

38. The apparatus of claim 32 wherein the specified type of event waiting is active.

39. The apparatus of claim 38 wherein the means for manipulating includes:

means for redirecting the identified process to a location where the I/O request was made.

40. The apparatus of claim 32 wherein a plurality of event control blocks are dynamically created during the initialization of the I/O Event Manager subsystem.

41. The apparatus of claim 32 wherein the operating system is a multi-tasking operating system.

42. The apparatus of claim 33 wherein the operating system is a preemptive multi-tasking operating system.

43. The apparatus of claim 41 wherein the multi-tasking operating system is executing within a telecommunications switch.

44. A method of implementing, within an application program, real-time event driven control over a hardware device, said application program executing within a computing system having an operating system, said method comprising the steps of:

inserting an Input/Output (I/O) Event Manager subsystem in said operating system;

loading a device driver, within said computing system, for driving said hardware device;

executing a request instruction within said application program, said request instruction specifying an event from said hardware device, said request instruction further specifying a type of event waiting including redirection event waiting;

processing said request instruction with said I/O Event Manager subsystem while said application program continues to simultaneously execute instructions other than said request instruction, said processing including the steps of:

transmitting said request instruction to said device driver;

receiving within said I/O Event Manager subsystem an indication that said event is mature; and

directing said application program to execute a first instruction based upon said mature event, said first instruction being user definable.

45. The method of claim 44 further comprising the step of:

executing, within said application program, a plurality of request instructions, each one of said plurality of request instructions specifying an event from said hardware device.

46. The method of claim 44 wherein said first instruction is located immediately after said request instruction.

47. The method of claim 44 wherein said operating system is a multi-tasking operating system.

48. The method of claim 44 wherein said operating system is a preemptive multi-tasking operating system.

49. The method of claim 44 wherein said computing system is a telecommunications switch.

50. The method of claim 44 wherein said computing system is a terminal adapter unit.

51. A method of implementing, within an application program, real-time event driven control over software, said application program and said software executing within a computing system having an operating system, said method comprising the steps of:

inserting an Input/Output (I/O) Event Manager subsystem in said operating system;

executing a request instruction, within said application program, said request instruction specifying a type of event waiting including redirection event waiting;

processing said request instruction with said I/O Event Manager subsystem while said application program continues to simultaneously execute instructions other than said request instruction, said processing including the steps of:

transmitting said request instruction to said software;

receiving, within said I/O Event Manager subsystem, an indication that said event is mature; and

directing said application program to execute a first instruction based upon said mature event, said first instruction being user definable.

52. The method of claim 51 wherein said first instruction is located immediately after said request instruction.

53. The method of claim 51 wherein said operating system is a multi-tasking operating system.

54. The method of claim 51 wherein said operating system is a preemptive multi-tasking operating system.

55. The method of claim 51 wherein said computing system is a telecommunications switch.

56. The method of claim 51 wherein said computing system is a terminal adapter unit.

57. A computing system for providing an application program with real-time event driven control over a hardware device, said computing system comprising:

means for executing an operating system having an Input/Output (I/O) Event Manager subsystem;

means for executing a device driver for driving said hardware device;

means for executing a request instruction within said application program, said request instruction specifying an event from said hardware device, said request instruction further specifying a type of event waiting including redirection event waiting;

means for processing said request instruction with said I/O Event Manager subsystem while said application program continues to simultaneously execute instructions other than said request instruction, said processing means including:

means for transmitting said request instruction to said device driver;

means for receiving within said I/O Event Manager subsystem an indication that said event is mature; and

means for directing said application program to execute a first instruction based upon said mature event, said first instruction being user definable.

58. The computing system of claim 57 further comprising:

means for executing a plurality of request instructions within said application program, each one of said plurality of request instructions specifying an event from said hardware device.

59. The computing system of claim 57 wherein said operating system is a multi-tasking operating system.

60. The computing system of claim 57 wherein said operating system is a preemptive multi-tasking operating system.

61. The computing system of claim 57 wherein said computing system is a telecommunications switch.

62. The computing system of claim 57 wherein said computing system is a terminal adapter unit.

63. A computing system for providing an application program with real-time event driven control, over software, said computing system comprising:

means for executing an operating system having an Input/Output (I/O) Event Manager subsystem;

means for executing a request instruction within said application program, said request instruction specifying a type of event waiting including redirection event waiting;

means for processing said request instruction with said I/O Event Manager subsystem while said application program continues to simultaneously execute instructions other than said request instruction, said processing means including:

means for transmitting said request instruction to said software;

means for receiving, within said I/O Event Manager subsystem, an indication that said event is mature; and

means for directing said application program to execute a first instruction based upon said mature event, said first instruction being user definable.

64. The computing system of claim 63 wherein said first instruction is located immediately after said request instruction.

65. The computing system of claim 63 wherein said operating system is a multi-tasking operating system.

66. The computing system of claim 63 wherein said operating system is a preemptive multi-tasking operating system.

67. The computing system of claim 63 wherein said computing system is a telecommunications switch.

68. The computing system of claim 63 wherein said computing system is a terminal adapter unit.

Description

BACKGROUND

A portion of the disclosure of this patent document contains material to which a claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but reserves all other rights whatsoever.

1. Field of the Present Invention

The present invention relates generally to a preemptive multi-tasking operating system, and more particularly, to a subsystem of the operating system which supports state oriented and event driven control of hardware devices having input/output (I/O) capabilities.

2. History of Related Art

The telecommunication industry is in a period of rapid expansion which has resulted from increases in consumer demand for telecommunication services. The rapid expansion has required the telecommunication industry to become more efficient and cost effective in the implementation of telecommunication services.

A telecommunication service is typically represented by a state diagram illustrating the various states and events that collectively implement the service. These state diagrams, also known as finite state machines (FSMs), can be implemented in a conventional computer programming language. When a FSM representing a telecommunication service is implemented, or written, in a conventional programming language, it is referred to as PFSMs. Presently, it is difficult to implement PFSMs in conventional programming languages because they lack specific methods and systems tailored for PFSMs. Furthermore, the telecommunication industry has not established a standard for implementing PFSMs using conventional programming languages. Because of the absence of a standard and the lack of specific methods and systems for implementing PFSMs using a conventional programming language, FSM implementations are often complex and redundant. As a result, the workload of designers responsible for updating and maintaining PFSMs increases because they must learn about all the methods and systems required to design each PFSM individually before they can be implemented together as a system.

Typically, PFSMs are designed to communicate with physical devices (hardware) in order to implement a particular telecommunication service. Currently, the telecommunication industry has not established a standard for implementing the communication protocol within a PFSM. The absence of such a standard results in further inconsistencies and complexity in trying to implement communication to the PFSM and the hardware. Because PFSMs uniquely depend on the hardware with which they communicate, the designer must rewrite the program for each PFSM operating on a different physical device. This again increases the designer's workload resulting in greater expense because of time loss.

It would be a distinct advantage to have methods and systems which implement the PFSMs independent of the hardware in a consistent fashion. The method and system would provide a PFSM with the ability to perform transitions from state-to-state, process I/O events for physical devices in real-time, and communicate with the physical devices at the operating system level. Additionally, the methods and systems would support existing implementations of PFSMs so that upgrades thereto would also utilize the new systems and methods. The present invention provides such systems and methods.

SUMMARY

An object of the present invention is to provide a consistent method and system for the implementation of PFSMs in conventional programming languages.

Another object of the present invention is to provide a consistent method and system for communication practical between a PFSM and a physical device.

A further object of the present invention is to support and provide new and existing PFSMs with the ability to perform transitions from state-to-state, real-time processing of events, and communication with physical devices at the operating system level.

BRIEF DESCRIPTION OF THE DRAWING

The present invention will be better understood and its numerous objects and advantages will become more apparent to those skilled in the art by reference to the following drawings, in conjunction with the accompanying specification, in which:

FIG. 1 is a block diagram of a computer system implementing a preferred embodiment of the present invention;

FIG. 2 is a block diagram which further illustrates the components of the I/O Event Manager of the computer system in FIG. 1 according to the preferred embodiment of the present invention;

FIG. 3A is a state transition diagram for an FSM running on the computer system of FIG. 1 according to the preferred embodiment of the present invention;

FIG. 3B is a block diagram which illustrates a linked list (sub.sub.-- arry) structure used for linking SCB data structures which are dynamically allocated within the I/O Event Manager of FIG. 2 in the preferred embodiment of the present invention;

FIG. 4A is a block diagram illustrating in greater detail the functions comprising the state oriented portion of the I/O Event Manager in FIG. 2 according to the preferred embodiment of the present invention;

FIG. 4B is a block diagram illustrating in greater detail the functions of the event driven portion of the I/O Event Manager in FIG. 2 according to the preferred embodiment of the present invention;

FIG. 4C is a block diagram illustrating in greater detail the functions of the event driven coordination portion of the I/O Event Manager in FIG. 2 according to the preferred embodiment of the present invention;

FIG. 5 is a flow chart of the operations which comprise the GETSCB function in the state oriented portion of FIG. 4A in the preferred embodiment of the present invention;

FIG. 6 is a flow chart of the operations which comprise the change state function (CHSTA) in the state oriented portion of FIG. 4A in the preferred embodiment of the present invention;

FIG. 7 is a flow chart of the operations which comprise the RELSCB function in the state oriented portion of FIG. 4A in the preferred embodiment of the present invention;

FIG. 8 is a flow chart of the operations which comprise the GETSTA function in the state oriented portion of FIG. 4A in the preferred embodiment of the present invention;

FIG. 9 is a block diagram which illustrates a linked list (ecb.sub.-- arry) used for linking the dynamically allocated ECB data structures within the I/O Event Manager of FIG. 2 in the preferred embodiment of the present invention;

FIG. 10 is a block diagram which illustrates a linked list (mevq.sub.-- arry) used for linking MEVQ data structures which are dynamically allocated within I/O Event Manager of FIG. 2 in the preferred embodiment of the present invention;

FIG. 11 is a flow chart of the operations which comprise the IOCTL function in the event driven portion of FIG. 4B in the preferred embodiment of the present invention;

FIG. 12 is a flow chart of the operations which comprise the IOSTS function in the event driven portion of FIG. 4B in the preferred embodiment of the present invention;

FIG. 13 is a flow chart of the operations which comprise the READ function in the event driven portion of FIG. 4B in the preferred embodiment of the present invention;

FIGS. 14A-14B are flow charts of the operations which comprise the write function in the event driven portion of FIG. 4B in the preferred embodiment of the present invention;

FIG. 15 is a flow chart of the operations which comprise the WRCHR function in the event driven portion of FIG. 4B in the preferred embodiment of the present invention;

FIG. 16 is a flow chart of the operations which comprise the RDCHR function in the event driven portion of FIG. 4B in the preferred embodiment of the present invention;

FIG. 17 is a flow chart of the operations which comprise the GETEVQ function in the event driven portion of FIG. 4B in the preferred embodiment of the present invention;

FIG. 18 is a flow chart of the operations which comprise the RELEVQ function in the event driven portion of FIG. 4B in the preferred embodiment of the present invention;

FIG. 19 is a flow chart of the operations which comprise the EVDIS function in the event driven portion of FIG. 4B in the preferred embodiment of the present invention;

FIG. 20 is a flow chart of the operations which comprise the EVENB function in the event driven portion of FIG. 4B in the preferred embodiment of the present invention;

FIGS. 21A-21E are flow chart of the operations which comprise the IOCOMMON function of the event driven coordination portion of FIG. 4C in the preferred embodiment of the present invention;

FIG. 22 is a flow chart of the operations which comprise the EXE.sub.-- RETURN function in the event driven coordination portion of FIG. 4C in the preferred embodiment of the present invention;

FIG. 23 is a flow chart of the operations which comprise the SET.sub.-- RTV function in the event driven coordination portion of FIG. 4C in the preferred embodiment of the present invention;

FIGS. 24A-24C are a flow chart of the operations which comprise EV.sub.-- DVN function in the Operating System Protocol Portion of FIG. 2 in the preferred embodiment of the present invention;

FIGS. 25A-25B are a flow chart of the operations which comprise the IODONE function in the event driver portion of FIG. 2 in the preferred embodiment of the present invention;

FIGS. 26A-26B are a flow chart of the operations which comprise the SYS.sub.-- IF function of the event driver portion of FIG. 2 in the preferred embodiment of the present invention;

FIGS. 27A-27C are a flow chart of the operations which comprise the IOCTL function for the device driver of FIGS. 1 and 2 in the preferred embodiment of the present invention;

FIG. 28 is a flow chart of the operations which comprise the IOSTS function in the device driver of FIG. 1 in the preferred embodiment of the present invention;

FIG. 29 is a flow chart of the operations which comprise the READ function in the device driver of FIG. 1 in the preferred embodiment of the present invention;

FIG. 30 is a flow chart of the operations which comprise the WRITE function in the device driver of FIG. 1 in the preferred embodiment of the present invention; and

FIG. 31 is a block diagram of an exemplary embodiment of the present invention as it exists within a telecommunications switch.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of a computer system 100 which employs a preferred embodiment of the present invention. The computer system 100 comprises an application program 102 having FSM 104, a pre-emptive multi-tasking Operating System (OS) 106 having an Input/Output Event Manager Subsystem (I/O Event Manager) 108, and a Device Driver 110. The FSMs 104 communicate with physical devices such as, for example, Physical Device 114 via the I/O Event Manager 108 and the device driver 110. The I/O Event Manager 108 provides the FSM 104 with support for state transitions and event driven control over communications with the physical device 114 via logic paths 103 and 105. The device driver 110 is employed by the I/O Event Manager 108 to coordinate the event driven control via bi-directional logic path 246. The OS 106 can be, for example, a MICROS.RTM. operating system which is produced by Ericsson Business Communications in Cypress, Calif. One function of the OS 106 is to maintain registers, data and a return address (environment) for each process (task) created therein. The OS 106 maintains the environment of each process by storing the environment on a selected stack. The OS 106 also keeps track of the state of a process and its environment by utilizing a data structure such as, for example, the Task Control Block (hereinafter "TCB") data structure employed by the MICROS operating system.

FIG. 2 is a block diagram which further illustrates the components of the I/O Event Manager 108 of FIG. 1 in the preferred embodiment of the present invention. The I/O event manager 108 comprises the following three interfaces: an application interface 205, an internal interface 210, and a device driver interface 220. An example of how the I/O Event Manager 108 of the preferred embodiment of the present invention may be implemented in the computer programming language C++, hereinafter referred to as "C++", is illustrated in Appendix 1. The application interface 205 comprises a state oriented portion 225 and an event driven portion 230, each of which are described in separate sections below.

Application Interface/State Oriented Portion

Still referring to FIG. 2, the state oriented portion 225 communicates with the internal interface 210 via a logic path 227, and provides the FSMs 104 (FIG. 1) with the ability to perform a transition from one state to another (state transition) at the operating system level. Performing state transitions at the operating system level promotes consistency in the implementation of FSMs 104. In order for the FSMs 104 to utilize the state oriented portion 225, it must implement each one of its associated states within a main state processing function. A main state processing function is analogous to the functions defined for a class in C++ and similar to the procedures and functions declared in conventional programming languages. The main state processing function can be comprised of numerous nested functions or procedures. However, the scope for the implementation of an individual state must be limited to the main state processing function and its related nested functions or procedures. In other words, there must be only one main state processing function for each individual state of a FSM.

FIG. 3A is a state transition diagram for one of the FSMs 104 of FIG. 1 in the preferred embodiment of the present invention. The FSM comprises state 1 302, state 2 304, state 3 306, state 4 310, and state 5 308. The transition from one state to another within the FSM is precipitated by either event 1 312, event 2 314, event 3 316, event 4 318, event 5 320, or event 6 322. Each state of the FSMs 104 is implemented in a main state processing routine. For example, each state of the FSMs 104 can be implemented in C++ as illustrated below in Table I.

                  TABLE I
    ______________________________________
    void sta.fn1( )
    /*The computer code which implements state 1 302 would
    reside here. */
    }
      .
      .
      .
    void sta. fn5( )
    {
    /*The computer code which implements state 5 308 would
    reside here. */
    }
    ______________________________________
     .COPYRGT. 1993 Telefonaktiebolaget L M Ericsson

                  TABLE II
    ______________________________________
    SFV SVT› ! = {sta.sub.-- fn1, sta.sub.-- fn2, sta.sub.-- fn3, sta.sub.--
    fn4, sta.sub.-- fn5}
    ______________________________________
     .COPYRGT. 1993 Telefonaktiebolaget L M Ericsson

                  TABLE III
    ______________________________________
    typedef struct
    QUE.sub.-- MBS
              link;         /* SCB linked list structure*/
    WORD      scb.sub.-- id;
                            /* SCB ID */
    WORD      scb.sub.-- sts;
                            /* status */
    WORD      sta;          /* current state */
    WORD      pre.sub.-- sta;
                            /* previous state */
    WORD      total.sub.-- sta;
                            /* total number of states */
    WORD      pid;          /* process ID */
    WORD      *loc.sub.-- tos;
                            /* local top of stack */
    WORD      *us.sub.-- reg.sub.-- ptr;
                            /* user register block */
    WORD      *svt.sub.-- ptr;
                            /* state vector table */
    }SCB
    ______________________________________
     .COPYRGT. 1993 Telefonaktiebolaget L M Ericsson

                  TABLE IV
    ______________________________________
             typedef struct
             {
               word total.sub.-- sta;
               int  deft.sub.-- prm;
               word *loc.sub.-- tos;
               SFV  *svt.sub.-- adr;
             } STA.sub.-- TBL
    ______________________________________
     .COPYRGT. 1993 Telefonaktiebolaget L M Ericsson

                  TABLE V
    ______________________________________
    typedef struct
    QUE.sub.-- MB
             link;     /* ECB linked list structure */
    WORD     ecb.sub.-- id
                       /* ECB ID */
    WORD     mevq.sub.-- id;
                       /* associated matured event queue */
    WORD     cmd.sub.-- fmt;
                       /* command or read, write format */
    WORD     rc;       /* response code or action if event
                        matured */
    WORD     pid;      /* user task (process ID) */
    WORD     dev.sub.-- id;
                       /* device ID */
    WORD     event;    /* event code*/
    WORD     ev.sub.-- sts;
                       /* status of the requested event */
    union
    {
     void    *dt.sub.-- ptr;
                       /* I/O data pointer */
     WORD    dt.sub.-- word;
                       /* I/O data word, 16 bit */
     BYTE    dt.sub.-- byte;
                       /* I/O data byte, 8 bit */
    } ppu;             /* I/O parameter data type union */
    US.sub.-- REG
             *us reg.sub.-- ptr;
                       /* user registers pointer */
    IOU      *iou.sub.-- ptr;
                       /* IOU pointer */
    } ECB;
    ______________________________________
     .COPYRGT. 1993 Telefonaktiebolaget L M Ericsson

                  TABLE VI
    ______________________________________
    typedef struct
    QUE.sub.-- MBS
                link;     /* link list structure */
    WORD        pid;      /* User task ID that owned this
                           queue */
    WORD        mevq.sub.-- id;
                          /* matured event queue id */
    WORD        q.sub.-- sts;
                          /* Queue status */
    EV.sub.-- LIST
                mq;       /* Queue */
    } MEVQ
    ______________________________________
     .COPYRGT. 1993 Telefonaktiebolaget L M Ericsson

                  TABLE VII
    ______________________________________
    typedef union
    CTL.sub.-- STRU
                 ctl;   /* parameter struct. for IOCTL */
    STS.sub.-- STRU
                 sts;   /* parameter struct. for iosts */
    RW.sub.-- STRU
                 rw;    /* parameter struct. for read.write
    */
    } IOU
    ______________________________________
     .COPYRGT. 1993 Telefonaktiebolaget L M Ericsson

                  TABLE VIII
    ______________________________________
    typedef struct
    Word       cmd;       /* control command */
    Byte       d.sub.-- type;
                          /* device type */
    Byte       d.sub.-- mode;
                          /* device mode */
    void       *table     /* user's parameter table addr
    */
    Byte       tbl.sub.-- idx
                          /* index to parameter table */
    Byte       para.sub.-- val;
                          /* byte value of the indicated
    entry */
    }CTL.sub.-- STRU
    ______________________________________
     .COPYRGT. 1993 Telefonaktiebolaget L M Ericsson

                  TABLE IX
    ______________________________________
    typedef struct
    WORD       cmd;      /* status command */
    WORD       ev;       /* event code */
    WORD       rc;       /* response code or action if */
                         /* event matured */
    WORD       mevq.sub.-- id;
                         /* matured event queue ID, */
    void       *fn.sub.-- addr;
                         /* function address for REDIR */
    } STS.sub.-- STRU
    ______________________________________
     .COPYRGT. 1993 Telefonaktiebolaget L M Ericsson

                  TABLE X
    ______________________________________
    typedef struct
    WORD       format;   /* Data input/output format */
    WORD       ev;       /* event code */
    WORD       rc        /* response code or actin if */
                         /* event matured */
    WORD       mevq_id;  /* matured event queue ID, */
    void       *dt_ptr;  /* associated pointer for I/O
                          data */
    BYTE       bc;       /* byte counter for STRING/
                          LINE */
    BYTE       wr_dlm;   /* delimiter used for write
                          to */
                         /* indicate end of string */
    void       *fn_addr; /* function address for REDIR */
    } rw_STRU
    ______________________________________
     .COPYRGT. 1993 Telefonaktiebolaget L M Ericsson

                  TABLE XI
    ______________________________________
    Typedef struct
    WORD      dev.sub.-- id;  /* device ID */
    union {
              WORD d.sub.-- cls;
              struct
              {
                 BYTE dev.sub.-- type;
                 BYTE dev.sub.-- mode;
              } dc;
    } dev.sub.-- class;       /* device
                              classification */
    WORD      operating.sub.-- status;
                              /*      */
    EV.sub.-- LIST
              in.sub.-- event.sub.-- waiting.sub.-- q;
                              /* queue */
    BUF.sub.-- QUE
              in.sub.-- buffer.sub.-- q;
                              /* use by in waiting
                              events */
    EV.sub.-- LIST
              out.sub.-- event.sub.-- waiting.sub.-- q;
                              /* queue */
    BUF.sub.-- QUE
              out.sub.-- buffer.sub.-- q;
                              /* use by out waiting
                              events */
    EV.sub.-- LST
              control.sub.-- status.sub.-- ev.sub.-- q;
                              /* queue for status
                              event */
                              /* waiting only */
    ADDRESS   cfg.sub.-- tbl.sub.-- ptr;
                              /* pointer to specific */
                              /* configuration table */
    ADDRESS   sts.sub.-- tbl.sub.-- tr;
                              /* pointer to specific */
                              /* status table */
    } DCT                 /* device control
                          table */
    ______________________________________
     .COPYRGT. 1993 Telefonaktiebolaget L M Ericsson

                  TABLE XII
    ______________________________________
    Typedef struct
    VOID       (init *)( );
                          /* initialization vector */
    VOID       (ioctl *)( );
                          /* io control vector */
    VOID       (read *)( );
                          /* read vector*/
    VOID       (write *)( );
                          /* write vector */
    VOID       (iosts *)( );
                          /* iostatus.sub.-- xxx vector */
    DCT        (*dct.sub.-- pt;;
                          /* device control table pointer */
    int        tbl.sub.-- id;
                          /* an indication of valid table. */
    } DVT;            /* device vector table
    ______________________________________
     .COPYRGT. 1993 Telefonaktiebolaget L M Ericsson