Method and apparatus for emulating the operations of an emulated system terminal driver on a host system

Claim 3

The method of claim 1 wherein the translating step includes comparing ATD device specific information using a number of different masks as a function of the type of request being processed.

Claim 4

The method of claim 2 wherein the translating step further includes the steps of grouping the device specific bits into a number of different bit categories which include common options, mappable options and unsupported options.

Claim 5

The method of claim 3 wherein said method further includes the step of adding new functionality to the NTD component for servicing unsupported options specified by the second driver device specific bits.

Claim 6

The method of claim 4 wherein said method further includes the step of enabling the new functionality initially or after the processing of an initial request as a function of which is more efficient.

Claim 7

The method of claim 5 wherein the initial request is a connect request and the new functionality is enabled after the successful completion of the connect request.

Claim 8

The method of claim 4 wherein the new functionality is included in a lower layer service provider for enabling processing of other than NTD control character sequences.

Claim 9

The method of claim 2 wherein the method further includes the steps of: validating the NTD device specific information of each request obtained resulting from the translating step in the same manner that other types of requests are validated by the NTD component; and, dispatching each validated request for execution by the NTD component operating in the equivalent second driver mode of operation.

Claim 10

The method of claim 1 wherein the method further includes the steps of determining if the request involves a special system function prior to performing the translating step and bypassing translating second driver device specific information when the request involves the special system function.

Claim 11

The method of claim 9 wherein the special system function is a print screen command.

Claim 12

The method of claim 1 wherein the method further includes the steps of: adding new functionality in the NTD component for servicing requests requiring the use of additional second driver operational modes; and, generating second driver status values based on status provided by the new functionality in a format which would have been returned by the second driver component.

Claim 13

The method of claim 11 wherein the additional second driver operational modes includes a file transfer submode of operation.

Claim 14

A first driver (NTD) component having a number of different operational modes for use in a host system having a memory and a hardware platform including a number of terminals used to enter commands for running user applications and for viewing results generated during running user applications, a host input/output services component operatively connected to different ones of the number of terminals for executing host system instructions of user applications wherein at least one user application designed to use a second terminal driver (ATD) component, the second driver component having a family of operational modes defined by device specific information included in an input/output request block (IORB) associated with each request issued by a user application, the NTD component being operatively coupled to the input/output services component, the host system further including operating system facilities for providing services for host programs and for initially configuring each of number of terminals which is to utilize the family of second driver operational modes and the NTD component, the NTD component comprising: an input section in response to a monitor call received from a user application for determining which driver software is servicing one of the number of terminals being used to run the user application, generating a response indicating that the second driver component is servicing the terminal when the terminal has been previously configured by a user to use the family of second driver operational modes; a preprocessor operatively coupled to the input section for receiving each request issued by the user application being run by the configured terminal, the preprocessor including a mechanism for translating second driver device specific information in the request IORB into NTD device specific information defining equivalent ones of the different operational modes to be used for executing the request by the NTD component operating in an second driver mode of operation which determines if the request is executable by the NTD component; and, a post processor operatively coupled to the input/output services component for receiving status information resulting from each executed request, the post processor mapping the status information into the same format as status which would have been returned by the second driver component enabling the application to run unmodified in the host system.

Claim 15

A first driver (NTD) component having a number of different operational modes for use in a host system having a memory and a hardware platform including a number of terminals used to enter commands for running user applications and for viewing results generated during running user applications, a host input/output services component operatively connected to different ones of the number of terminals for executing host system instructions of user applications wherein at least one user application designed to use a second terminal driver (ATD) component, the second driver component having a family of operational modes defined by device specific information included in an input/output request block (IORB) associated with each request issued by a user application, the NTD component being operatively coupled to the input/output services component, the host system further including operating system facilities for providing services for host programs and for initially configuring each of number of terminals which is to utilize the family of second driver operational modes and the NTD component, the NTD component comprising: an input section in response to a monitor call received from a user application for determining which driver software is servicing one of the number of terminals being used to run the user application, generating a response indicating that the second driver component is servicing the terminal when the terminal has been previously configured by a user to use the family of second driver operational modes; a preprocessor operatively coupled to the input section for receiving each request issued by the user application being run by the configured terminal, the preprocessor including a mechanism for translating second driver device specific information in the request IORB into NTD device specific information defining equivalent ones of the different operational modes to be used for executing the request by the NTD component operating in an second driver mode of operation which determines if the request is executable by the NTD component; and, a post processor operatively coupled to the input/output services component for receiving status information resulting from each executed request, the post processor mapping the status information into the same format as status which would have been returned by the second driver component enabling the application to run unmodified in the host system.

Claim 16

The first driver component of claim 13 wherein the mechanism of the preprocessor includes a number of different masks for comparing and translating second driver device specific information in the request IORB into NTD device specific information.

Claim 17

The first driver component of claim 14 wherein said mechanism groups the device specific bits into a number of different categories, the different categories including common options, mappable options and unsupported options wherein common option bits are those second driver device specific bits which specify the same or equivalent functions and have the same bit positions as NTD device specific bits, mappable option bits are those second driver device specific bits which specify the same or equivalent functions but have different bit positions than the NTD device specific bits and unsupported option bits are those second driver device specific bits which have no equivalency to the NTD device specific bits.

Claim 18

The first driver component of claim 13 wherein the number of different operational modes of the NTD component includes a message mode and the family of operational modes of the second driver component includes a TTY mode and an X-ON/X-OFF (AXD) mode having a number of submodes, the NTD component operates in message mode for processing requests previously processed by the second driver component in a TTY mode and certain ones of the submodes of AXD mode.

Claim 19

The first driver component of claim 16 wherein the NTD component includes added functionality for supporting other types of application requests requiring different driver software.

Claim 20

The first driver component of claim 17 wherein the other types of application requests were previously processed by a number of submodes of the AXD mode of the second driver component.

Claim 21

The first driver component of claim 13 wherein the preprocessor further includes a second mechanism for validating translated NTD device specific information of each request that is normally used for validating requests and a dispatching component for dispatching each validated request for execution by the NTD component operating in the equivalent second driver mode of operation.