CA1325483C - Network terminal driver communications subsystem - Google Patents
Network terminal driver communications subsystemInfo
- Publication number
- CA1325483C CA1325483C CA000598149A CA598149A CA1325483C CA 1325483 C CA1325483 C CA 1325483C CA 000598149 A CA000598149 A CA 000598149A CA 598149 A CA598149 A CA 598149A CA 1325483 C CA1325483 C CA 1325483C
- Authority
- CA
- Canada
- Prior art keywords
- responsive
- certain
- application
- terminal
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
Abstract
ABSTRACT
A communication subsystem of a data processing system includes a number of elements including Application's Software, a Network Terminal Driver and a Lower Layer Service Provider which controls the transfer of information between terminals and their controllers and main memory.
A communication subsystem of a data processing system includes a number of elements including Application's Software, a Network Terminal Driver and a Lower Layer Service Provider which controls the transfer of information between terminals and their controllers and main memory.
Description
BAC~GROU~DlOF THE INVENTION
Field of Use . . _ This invention relates to the data processing field and more particularly to data communications software which conn~cts the data processing 3ystem to a variety of terminals requlring different communicat:ion technologies.
Description of the Prior Art Over the years the data processing ~ystems have changed from batch processing applications to interactive system applications. In a batch processing application, all of the processing i~ done at the computer site including all input into the data proce-~sing system.
As the technology impro~ed, particularly in the terminal area, operators at remote terminals would key into their terminal and the information would be transferred to the central computer over communication lines. This required communication controllars at the computer site and software to drive these communication controllers. The sof~ware developed at that time was written in a low level assembly language, was designed for use with a specific communications technology and further de~igned to provide specific modes of ~pplication qupport. The terminals were also limited by having fixed data code characteristic~.
Thi~ type of communication'~ controller hardware and software design presented a number of problem~. The software was very difficult to maintain and modify. This i8 particularly true if the software had to be extended to support a new terminal which was added to the sy~tem.
, , ..
, ` 1 325483 Today terminals are being built with new and evolving technology in the communication~ area. However, the sof tware in the central system is too rigid to adapt to these n~w ~echnologies. If these terminals require S extended ~odes of application support, it is difficult to adapt the software.
.
OBJECT I VES OF T~IE I NVENT I ON
Accordingly, it is an objective of the invention to provide an improved communication subsyste~ which is readily adaptable to support additional terminals.
It is another ob~ective of the invention i~ to provide an improved communication subsystem which is readily adaptable to adding new modes of application support.
,, . ' ~ ' ,:
'~:
- 1 3 2 5 ~ ~ 3 72434-96 SUMMARY OF THE INVENTION
In addition to the hardware, a data communication subsystem includes a number of elements. These elements include Appllcations Software, a Network Terminal Driver and a ~ower Service Provider.
The Applications Software initiates actions to cause the communication subsyskem, including the terminals, printers and the users to perform prescribed functions to accompllsh a specified job.
- 10 The Network Terminal Driver includes a number of Application Modules, a number of Provider Modules and a number of Device Profiles all operative with a number of co~mon Kernel Components.
~ The Application Modules interface with their respective ; applications software to support the specified modes of operation.
.
The Kernel includes a number of common components which interact ;
with the Application Modules, the Provider Modules and ~he Device Profiles to execute the Applica~ion Software requests.
~^ In accordance with the present invention, there is provided a communication subsystem in a data processlng system comprising: Application means for generating first requests for said system to perform prescribed functions to accomplish a specified job Network Terminal Driver means coupled to said ` application means and responsive to said first reguests for .~ generating a plurality of control buffers, said Network Terminal .;
- Driver means including first and second module means responsive to ~` information stored in said plurality of control buffers for ,. . .. ~ - . . . .
.
~ 325~3 yenerating a sequence of orders; Terminal means coupled to said Network Terminal Driver means and responsive to said sequence of orders for pèrforming said prescribed functions.
In accordance with another aspect of the invention, there is provided in a data processing system comprising: a central processlng unit (CPU); a memory unit connec~ed to the CPU
for storing system program~ and application programs to be run by the CPU and for storing data to be operated upon hy the progxams;
a plurality of terminals of one or more ~ypes at which users enter commands requesting application programs to be run by the CPU and view results of those programs; and one or more communications media of one or more types, each for interconnecting the CPU with certain oE the terminals of the plurality of terminals, a network terminal driver operatively connected between the CPU and the communications media for facilitating communications bet~een the application programs and the plurality of terminals, the network terminal driver comprising: a plurality of application modules, each associated with a~different data forma~ used by the application programs, for specifying data formats being used by each of the application programs; a plurality of provider modules, each associated with a different one of the types of communications media, for specifying the characteristics of eacb of the communications media; a plurality of device profiles, each associated with a different one of the types of terminals, for specifying the characteristics of each of the ~erminals; and means Fesponsive to said specification of data formats, communications media characteristics, and terminal characteristics for 3a ~' ; ~, , ,, : ~ . : .
,:; .
, . .
.
1 325~3 interpreting transmissions from the communications media and assembling messages to the communications media according to sald specifications of data formats, communications media characteristics, and terminal charac~eristics.
BRIEF DESCRIPTION pF THE DRA~INGS
Figure 1 shows an overall block diagram of a data `, processing system including a communication subsystem.
Figure 2 shows an overall block diagram of a Network ~erminal Driver of the communication subsystem.
,' 10 Figure 3 shows a detailed block diagram of the flow of lnformation through the Network Terminal Driver.
Figure 4A shows the interconnection between the request block and control block data structures which execute an order.
Figure 4B shows the layout of an Input Output Request Block (IORB) data structure.
1~
, 3b 1 . .. . : . : ~ .
:: -.
.
. 1 325~83 ~ Figure 4C shows the la-yout of ~ Provider Module Control : Bloc~ (P~CB) data ~tructure.
Figure ~D shows the layout of a Device Descriptor Control Block (DDCB) data structure.
sFigures SA-SE shows a flow diagram of a typical operation of the Nstwork Terminal Driver.
DESCRIPTION OF THE PREFERRED EMBODIMENT
Referring to Figure 1~ a data processing sy~tem 1 includes a Control Proce~sor ~CPU) 2, ,a main memory 6, a number of peripheral Gontrollers 20, .a number of communication controller~, typically, a Lecal Area Network (LAN) controller 8 and an MLX~16 Proce~or 10, all coupled in common to a system bus 4. A number of devices typically are coupled to MLX-16 ProcQssor 10.
lS The e device~ may include a remote terminal A 14/ a printer 16 and a work~tation A 18. A printer B 16 may be coupled to workstation A 18.
A number of devices, typically, terminal B 14 and terminal C 14, are coupled to a terminal concentrator ~C-6 12, which is, in turn, coupled to the LAN
controller 8 by a LAN medium 22. Medium 22 could typically be an IEeE ~02.3 Interface.
Main memory 6 includes a number of software units;
an Operating System (OS) 6-1, Application Software 6-2, a Network Terminal Dri~er (NTD) 6 4, and a Lower Layer Service Provider 6-6. Typical Application Software 6-2 includes office ~ystems, word processing systems, data entry facilitie~ and database management systems. The Lower Layer Service Provider 6-6 contains the ~pecific ~oftware for communicating with ~he hAN controller a and the MhX-16 Processor 10 via the system bus 4 under control of CPU 2.
, . -4 -.. .. .
' .
,,: . ' ~ . ':: -: . : .
,, , The NTD 6-4 includes the software module that permit the user operating from a terminal 14 or workstation 18 to use a selected application stored in ~pplication 6-2. The NTD includes several Application Modules (AM) 6~420, a Kernel Module 6-400, several Provider Modules 6-440 and several Device Profiles 6-460. The NTD 6-4 operates in a number of different modes depending on the type of device being supported and the way in which the applications software in Applications 6-2 utilizes the device.
An administration mode Appiication Module provides an interface to the devices which i8 used internally by the NTD 6-4 for device configuration and status inquiry, and is used by the applications software in Applications 6-2 for operations such as print screen.
A Message Mode Application Module supports a line at a time entry even thou~h the data transfers between the terminal and the host takes place on a character basis. The CPU 2 i~ interrupted at the completion of a line of data.
A field mode Application Module supports a field at a time entry, even ~hough the data transfers between the ~erminal and the host take place on a character basis. The type of data to be entered into the field is specified by the Application 6-2 and checked by NTD
6-4. The CPU 2 is interrupted at the compleSion of each field of data.
A block mode Application Module provides support for Application Software which operates with the intelligent terminal. Data transfers between the terminal and the host are in typically 256 byte blocks.
A printer m~de Application Module prv~ides support for both stand alone printers and those connected via a buflered printer adapter in a terr,inal or workstatlon.
;
.
''. ~ ' , ~, ,"~
.
: .
" ~
.
1 325~83 ~~ A polled VIP mode Application Module provides an interface to applications that are operative with the MLX-16 Processor 10 that have terminals 14 and workstation~ 16 operating in a polling mode.
-~ 5 The Application Modules 6-420 interface to the applications software in Application 6-2, one Application Module 6-420 for each mode of operation.
.` The Provider Modules 6-440 provide the necessary software for the NTD 6-4 to communica~e with the communications controllers for the various supported `. communications technologies such as; the LAN controller 8 or the MLX-16 Processor 10 via the Lower Layer Service Provider 6-6.
Figure 2 provides a more in-dep~h picture of the .. 15 internal struc~ure of the four ma~or components of the ., NTD 6, namely, the Kernel 6-400, the Application 3 Modules 6-420, the Provider Modules 6-440 and the Device Profiles 6-460.
i' The NTD 6 includes the Kernel 6-400 which ha~
common interfaces to all o~ the Provider Modules 6-440 and the Application Modulas 6-420. This allows for a new Provider Module or new Application Module to be , added to the system without modification to the Kernel 6-400. The Application ~odules 6-440 communicate with the terminal 14 or workstation 18 in the different modes, via an Admini~trative Mode 6-421, a Message Mode ', 6-422, a field mode 6-424, a block mode 6 42S, a . printer mode 6-428 or a polled VIP mode 6-430.
jl The Provider Modules 6-440 provide the required ~i 30 ~oftware interface to the Device Profiles 6-460. The .~ Provider Modules ~-440 include a LAN interface 6-442, an MLX-16 interface 6-444 and a Public Da~a Network (PDN) lnterfwe 6-446.
_ ~ _ .
,, .
.. . . .
.~ .
.''. ~
~~~ There is a Device Profilel ~o2r eac~ type of device coupled to the LAN controller 8 and the MLX-16 Processor 10 as well as any other technologies.
Typical Device Profiles are Teletype (TTY) profiles 6-46Z, VIP 7201 profiles 6-464, VIP 7300 profiles 6-466, VIP 7800 profiles 6~468, HDS 2 profiles 6-470, HDS7 profiles and X3.64 profile~ 6-472.
The devices are typically Honeywell Bull Inc.
VIP7201, VIP7300, VIP7800, HDS2, HDSS, HDS7 and X3.64 workstations. Each Device Profile may contain a table with the following information:
a) profile name b) profile description c) workstation identifier d) code set supported by the workstation e) modes support by this profile f~ system device and driver identity g) all character sequences required for NrD 6-4 to interact with the workstations.
This approach permits the adding of new devices without major changes to the software.
Thé Kernel 6-400 i made up of a number of components, including an Input Output Request 81Ock (IOR~) processor 6-402, a Monitor Call tMCL) Proce~or 6-404, a Connect Processor 6-406, a Disconnect Proce~sor 6-408, a Timeout ~anager 6-410, a Queue Manager 6-412, a Module Dispatcher 6-414, and a Process Manager 6-416.
The IOR~ Processor 6-402 handles Input Output Reque~t Blocks tIORB) 6-20 which contain information on the structure of the data being tran~ferred between main m~mory 6 and a specific terminal 14, printer 16 or ;:
; :
workstation 18~ The IOR8 P~ 402 defines and va}ida~es the characteristics and constraints upon the data being transferred.
Typical restraints are the range, the maximum number of characters being transferred during this data transfer, and th~ starting address, the main memory 6 location from which the first character is read, or to ~` which the first character is written. Also other information in the IORB 6-20 specifies special control sequences to be sent to the termina:L such as cursor . positioning, bell or display attributes. During the ,.'3 Message Mode operation, therefore, an IORB 6-20 would ',3 be passed on to a Message Mode 6 422 of Application Modules 6-420 for further processing.
A Process Manager 6-416 identifies a requestor of an activated task and the requested task, obtains th~
, necessary data structures, sets up the C language environment and dispatches program control to the NTD
6-4 component responsible for receiving the request.
All processes dispatched by the Process Manager 6-416 ~' are returned for proper termination.
' The MCL Processor 6-404 interfaces with the OS 6-1, ''3 receives calls from OS 6-1, provides main memory 6 ~ space for having NTD 6-4 execute the call and manages 1 25 the return to OS 6-1. The MCL Processor 6-404 also may change certain configuration parameters specified in ,3 the Device Pro~ile 6-460 for the terminal 14 ~r o workstations 1~.
;~ The Connect Processor 6-406 manages the common connect responsibilitie~ including establishing and monitoring the connection of NTD 6-4 to ~pplication 6-2, and initiates configuring the terminals 14 and workstation 18 and any remote devices (not shown) involved in the communication.
~, . .
,3 _ ~ _ , .
:, , : ' ' ~ : : ' '. ,,; ' `~
~ 325483 ,_~
The Disconnect Processor 6 406 manages the common disconnect responsibilities for all the modes supported by NTD 6-4. The Timeout Manager 6-410 makes use of the OS 6-1 Clock Manager to set up a timer, which generates S a timeout if a specific operation being measured is not completed within the specified time. The system recognizes the error, posts it, and continues operation.
The Queue Manager 6-412 provides control supporting routines to be used in common by all Provider Modules 4-440. This support includes managing the Provider Module Control Block (PMCB) 6-402A queues for each workstation 18 and terminals 14 and manage one related typed data Device Dri~er Control Block (DDCB) 6-420A
queue for each workstation 18 and devices 14.
A Module Dispatcher 6-414 ties together the Provider Module 6-440 and the Application Module 6-420 employed for the device. The Application Modules 6-420 need not know which Provider Module 6-440 will handle the call. The Module Dispatcher 6-414 maps the call to the Provider Module 6-442, 6-444 or 6-446 for servicing.
Figure 3 shows the operation of the NTD 6. A user at a terminal 14 or workstation 18 sélects: an application and writes to the Cathode Ray Tube (CRT~
screen at the terminal 14 or workstation 18. The Application 6-2 working with the user issues a write IORB to NTD 6.
The IORB Processor 6-402 begins to process the write IORB. The IORB Processor 6-402 makes sure the address location of the required data in main memory 6 i-~ valid and the number of characters, the range, data that will be transferred to the worXstation 18. The . ~ , ~ , , .
I .-: , 1 325~83 ; ~ IORB Processor 6 402 further checks that the options available to the terminal 14 or works~ation 18 are allowed.
Write IORBs require additional mode specific processing so the IORB is passed to the ApplicationModule 6-420. For example, if a word processing application is in effect, then the field mode 6-424 application module would perform a field mode specific procedure to validate the write operation.
10Connect and Disconnect IOR~s are handled in the same manner, but would require common processing as well as mode specific processing.
The IORB processor 6-402 passes a Connect IOR~ to the Connect Processor 6-406 to perform a common connect procedure before the Application Module 6-420 perform any mode specific connect processing.
Similarly, after the Application Module 6--402 performs any mode specific disconnect processing, the Disconnect Processor 6-408 performs a common Disconnect procedure. In either case, the Application Module 6-420, Connect Processor 6-406 or Disconnect Processor makes calls to the Provider Module Service Calls 6-440A
via the Module Dispatch~r 6-414 to generate micro order~ ~DDCBs) to continue processing the IORB and ultima~ly accompli~h the original request of the application as specified in the IORB. The DDCBs 6-420B
created for an Application Module 6-402 have a ~ode specific purpose while DDC~s 6-420A created for either the Connect or Disconnect Processor are for purposes common to all application processing modes (eg. common to field mode, message mode, etc.).
.
, . , , . , -.;
. ', .
1 325~83 The appropriate Provider Module 6-440 is selected by the Module Dispatcher 6-414 in accordance with the hardware arrangement. Terminals connected to the LAN
Controller 8 operate through the LA~ Interface 6-442.
Similarly, terminals connected to the MLX-16 Processor 10 operate through the MLX-16 Interface 6-444.
;~ The IORB Processor 6-402 attaches a Provider Module Control Block (PMCB) 6-402A to the original application IORa 6-20. There is one PMCB 6-402~ for each application IORB 6-20 that is issued to NTD 6-4. The PMCB 6-402A points to a string of Device Descriptor Control Blocks (DDCB) 6-420A and/or 6-420B. These are , the string of micxo instructions that execute the action requested by the application. When calls are made to the Provider Module Service Call~ 6-440A, DDCBs 6-420A or 6-420B are generated and attached to the PMCB
6 -4 02A .
j The PMCB 6-402A and DDCB 6-420A and/or 6-420B are ; then passed to the Queue Manager 6-412. The Queue ,l 20 Manager 6-412 takes the PMCB and DDCBs and puts it in a queue for the re~uested terminal. The Queue Manager 6-412 issues the DDCBs, one at a time, to the Workstation Control Manager 6-420D. The Workstation ~ Control Manager 6-420D performs any necessary `3 25 work~tation 18 or terminal 14 specific proce~sing ~hat . must be done to in3ure that the DDCB will reach the proper device, and passes the DDCB to the PM 6-440B.
Here again the Module Dispatcher 6-414 selects the proper PM 6-442, 6-444 or fi-446 by issuing the DDCB
6-420A or 6-420B to the Lower Layer Service Provider ~, 6-6, which, in turn, will perform the specified micro-operation on the requested terminal 14 or workstation 18.
, ~ .
~ ~ .
, ':1 1, ''"~: " ' '' ; ' ' ' ' .
. ~ .
-' : .
1 32~483 .
r~ The Queue Manager 6-412 continues to issue DDCB
6-420A or 6-42ûB until some Icind of blocking condition i~ met. ~or example, the PM 6-440b will set up write and read DDCB credits which detennine how many read and write DDC:~s the Queue Manager 6-412 can have outstanding at a time for that terminal 14 or workstation 18.
When the Provider Module 6-44Qb .is finished with the DDCB 6-420A or 6-420B, it calls the Queue Manager 6-412 post/dequeue. The Queue Manager 6-412 then copies any pertinent status into the PMCB 6-4Q2A and calls the Application Module 6-420 i neces~ary.
When all of the DDCBs 6-420A and/or 6-420B
associated with the PMCB 6-402A have been issued and posted, the Queue Manager 6-412 will call the IORB
Processor 6-402 to pos'c that IORB 6-20 and return it to the application.
Figure 4A shows the structures involved in the processing of an operation. The Application 6-2 generates an IORB 6-20. The Operating System (OS) 6-1 receives the IORB 6-20 and creates an Indirect Request Block 6-10 (IRB). The IRB's 6-10 are used by the OS
6-1 for handling various kinds of requests. The IORBs are just one level of request handled by the IRE3~s.
The IORB 6~20 and the IRB 6-10 are passed to the NTD 6-4. The IORB Processor 6-402 verifies that the IORB 6-20 is valid, and if so, the IRB 6-10 will be pointed to a Provider Pqodule Control Block (PMCB) 6-402A.
The PMCB 6-402A is used for maintaining the status of the overall operation during the execution of the micro orders in respon~3e to the IORB 6-20. The Provider l~odule 6-440 creates a number of Device Drive : ., 1 325~83 ,. ~~ Control Blocks (DDCB) on behalf of either the Application Module 6-420 Connect Processor or Disconnect Processor. The Queue Manager 6-412 issues the DDC~s one at a time.
A~ an ex~mple a DDCB 6-420A could be sent ~o the terminal 14 or workstation 18 via the Lower Layer Service Pro~ider 6-6 and MLX-16 Processor 10 to ', e.~tablish a connection between the terminal 14 and ~he workstation 18 and Application 6-2 then a DDCB 6-420B
would be sent to terminal 14 or workstation 18 via the . Lower Layer Service Provider 6-6 and MLX 16 Processor 10 to send the cursor to a particular part of the terminal 14 or workstation 18 screen. Still another DDCB 6-420B would send data to the terminal 14 or workstation 18 for display. Yet another DDCB 6-420B
would return the cursor to its original position on the screen.
Referring to figure 4B, the IORB 6-20 includes an inventory of 16 bit words having bit po~itions hexadecimal O through F. Word Offsets 0 and 1 point to the IR8 6-10 in main memory 6 and is man~ged by the OS
6-1.
Word Offset 2 includes a return statu byte to indicatej for example, if the device was unavailable, or the operation was aborted, or there was invalid information paYsed to the device by the application.
The left byte of Word Offset 3 contains the Logical . Resource Number (LRN) which identifies the device for which IORB 6-20 is intended, that is, the terminal 14 or printer 16 or workstation 18, etc. The right byte includes the function code which describes the operation the IORB 6-20 is to perform. Typical function6 are connect, disconnect, read or write. The .
.
...
, ~ .
r~ B bit in position 9 indicâtes if the buffer starts in the left hand or right hand byte of the word. The E
bit in position B indicates that the IORB 6-20 is extended for at least 10 words. The IORB 6-20 normally ends after Word Offset 9. The extension is typically used for field mode and its size is always stored in ; Word Offset 10.
Word offsets 4 and S contain the two word (32 bit) starting address in main memory 6 o~E the data buffer ;i 10 which stores the data involved in the transfer between the device and main memory 6 if this is a tr~nsfer IORB
6-20. Word Off~et 6 stores the range, that is ~he number of bytes being transferred.
Word Offset 7 is a device specific word. It lS includes bits indicating the options to include with `; the order. As an example, for the Field Mode 6-404 application, a bit specifies that data keyed for a read i IORB 6-20 is also displayed on the screen.
;~` Word Offset 8 indicates at the completion of an order, the number of bytes not tran~ferred.
Word Offset 9 stQreS the Device Status Word 1 which `A' provides additional sta~us to the status stored in Word Offset 2. An example would be to indicate if a parity error was sensed by the Lower Layer Service Provider 6-6 during a read operation.
Word Offset 10, byte 1 stores the number of words the IORB 6-20 is extended by. Byte 2 stores the number ~i of wor~s in the IORB 6-20 extensions. This word i5 only present when the E bit position in Word Offset 3 is set to logical one.
/~
., ' , , ~ .
i ,, .
.
f:
, ' ' . ' ' ' ., .
,,,, , ' ' ,~, 1 325~83 . ~ Device Specific Word 2 of Word Offset 11 provides ;: further information on how the order is to be processed. In Field Mode, for example, this Word Offset would specify the validation criteria, either a standard or a special validation set.
Word Offset 12 indicates ~ome of the physical characteristics of executing the order; for example, 3. the number of key strokes used by the operator. It also provides information for the supervisory message line at the bottom of the display screen at connect time.
Word Offset 13 serves two purposes. Initially for Field Mode reads, it contains an offset to the field position where data entry should begin. Finally when the read is completed it stores an indication of the number of remaining characters ready for immediate processing upon receiving the next read order from the application. This enableq the application to create the next read IORB with a range large enough to handle the remaining characters.
Word Offset 14 stores additional status information. For example, during Field Mode it indicates that valid data was entered into the field by the operator.
Word Offset 15 contains information for the application to determlne ~he location of the cursor at the completion of the order.
Word Offset 16 contains information that identifies the character keyed by the operator that terminated the read order. Word Offset 16 also stores an indication of whether or not an illegal entry wa~ made.
' .
;- ~ . , ~ . . . .
; 1 325~83 Word Offset 17 has multiple purposes. Initially it provides pre-order information. As an example, it could send a line feed, carriage return character before starting the order. It may also set the display attributes for the order such as low intensity, blink and inverse video. Word Offset 11 bits define the U58 of Word Offset 17. Upon termination of the read order it indicates the characteristics that the illegal entry did not satisfy. For legal entry it may contain additional read termination information.
-~ Word Offset 18 provides the first word of the descriptor for a read operation. The descripter - specifies the characteristics of the data to be entered into the field.
15Figure 4C shows the contents of the PMCB 6-402A.
The PMCB 6-402A is associated with an IORB 6-20 by the IORB Processor 6-402. It is used to hold together all the micro orders (DDCBs) associated with this IORB
6-20.
20The PMCB Control Word indicates the type of PMCB
6-402A this is. IORBs 6-20 specify read operation3 and write operations for the Application Modules 6-420.
The Control Word also provides information to the Queue Manager 6-412 such as "purge~' which indicates that this 25PMCB 6-402A should be deleted, 'modify~ which indicates that information has been added to or removed from ~he PMCB. This informs the Queue Manager 6-412 to l initialize an internal pointer.
The Queue Link to next PMCB is used to locate the 30next PMC~ 6-402A in ~he queue. A number of PMCB's may , be queued to process the application's requests The PMCB's IORB pointer stores the memory 6 location of its associated IORB.
.. . . .
s , . . . :
.:
,.-, . ': .
` 1 325483 ; ~ Error Status 1 gets copied into the left byte of Word Offset 2 of the IORB 6-20.
Return Status 1 and Return Status 2 are continually updated by the DDC8s and in turn update Word Offset 9 and Word Offset 14 of the IORB 6-20 at the conclusion ; of the order.
Residual Range is transferred to Word Offset 8 at the end of the order to indicate the number of bytes not transferred.
The D~CB Chain Queue Header points to the first DDCB in the chain to be processed.
Figure 4D shows the contents of ~he DDCB. The DDCB
Control Word identifies the type of micro order, that is, a write, a write control, a r~ad, no-operation (NOP) or an event. Also included is a bit indicating that this DDCB is marked for deletion. Another bit indicates that this DDCB has been sent to the lower level service provider 6-6 and is awaiting posting.
The Queue Link to next DDC8 links this Link DDCB to the next DDCB in the queue.
The PMCB pointer field point~ ~o its associated PMCB 6-402A.
The IORB pointer, when used, indicates that the poin~er to the Data ~uffer is that of the IORB Data Buffer as opposed to an internal NTD Data Buffer.
Th~ Pointer to Data Buffer points to the starting address of either the IORB Data Buffer in main memory 6 or an NTD internal data buffer in main memory 6. These Data Buffers are only specified for a Data Transfer DDCB.
Data Buffer Range specifies the nu~ber of bytes in the Data Buffer.
Residual Range ~pecifies the number of bytes not transferx d.
~ ~17-.
:, "
1 325~83 Error Status stores an indication of errors sensed during processing.
Return Status 1 and Return Status 2 update the respective fields in the PMCB.
Queue Control Info is used by the ~pplication Module 6-420 to tell the Queue Manager 6-412 how to treat this micro order and how the processing of this DDCB micro order will affect the processing of other DDCBs on this queue.
Application Module SpPcific Status Area stores the Application specific status of thi~ micro order and updates Offset Words 12 through 17 of the IoRa 6-20.
The interrupt vector is genera~ed by the creater of the DDCB if more processing is needed when this DDCB is posted.
The error vector is used by the Queue Manager 6-412 to point to an error processing routine specified by the creator of the DDCB in the event of an error during the processing of this DDCB.
The Clock Request Block specifies the timeout associated with this order. When the order is issued, the Operating System uses the information to set a clock and start a timer. If the timer expires beore the DDCB is posted, then an error condition is recorded.
Figures 5A through 5E describe a typical write NTD
6-4 operation. When the Application 6-2 re~uests a communication with a user, a number of IORBs 6-20 are generated. They connect NTD 6-4 to the terminal 14 or woxkstation 18 to establish a connection. This allows the user to turn the terminal 14 or workstation }8 on.
An IORB 6-20 also establishes a read operation. This requeets the operater to enter data for examination by the Application 6-2.
', :
. .
., , . : .
.
'; ' ~ '~:' ;
-~ 1 325483 ~ ~ A write IORB, sends information from the `~; Application 6-2 to the terminal 14, printer 16 or workstation 18. Figures SA, 5B, 5C, 5D and 5E explain what the NTD 6-4 does when it receives an IO~B from the . 5 Application 6-2. Whether the IORB calls for a connect, ` disconnect, read or write operative, NTD 6-4 goes through the same processing steps.
!/ For this example, once the terminal 14 or ;~ workstation 18 is connected, the connect channel program in the MLX-16 Processor 10 wi.ll interrupt the NTD driver and the NTD 6-4 will run until the entire connect IORB has been procesed.
~` Referring to figure 5AL in block 5-2 the Operating System 6-1 takes an IORB 6-20 from Application 6-2 and passes it to NTD 6-4. In block 5-4, the Process Manager 6-416 takes the IORB 6-20 and passes it ~o the IORB Processor 6-402.
. In decision block 5-6, the IORB Processor 6-402 ` checks the Function Field (bits C-F) of Word Offset 3, figure 4B of the IORB 6-20 to see if it is consistent with the current ~tate of the terminal 14 or workstation 18. For example a write would not be . allowed against a device that has not been connected.
If the test fails, then block 5-16 posts the ~ORB
6-20 with an error. If the test is successfulf then decision block 5~8 test the validity of the common IORB
options which are specified in Word Offsets 7, 10, and 11. These op~ions include that the proper Application Module of Application Modules 6-420 and that the proper .~ 30 type of device terminal 14, printer 16 or workstation 18 are connected. Here again, an unsuccessful tes~
results in block 5-16 posting the IORB 6 20 with an error.
!~
~ -19-,. .
.
. . ', ,~ .
I 325~83 ~~ If the test is successful then in block 5-9 the IORB Processor 6-402 creates a PMCB 6-402A for the IORB
6-20.
Decision block 5-11 tests if there are any co~mon S DDcBs S-420A to be created and if so block 5-13, figure 5B, calls the selected Provider Module 6-442 through 6 446 via the Module Dispatch~r 5-414 to create the DDCB 6-420A.
Decision block 5-15 tests if anymore DDCB 6-420A
are to be createdO If so then block 5 13 again performs as described supra.
After all the required common DDCB 6-420A are crea~ed ox decision block 5-11 in~icates that no common DDCB 6-420A are to be created then in block 5-10, ~he lS IORB Processor 6-402 calls the appropriate Application Module 6-422 through 6-430 via the Module Dispatcher 6-414.
Decision block 5-12 then tests if the mode specific options are valid. If so, then decision block 5-14 tests if there are any mode specific DDCBs 6-420B are to be created. If so block 5-18, fi~ure 5C, calls the proper Provider Module 6-442 through 6-446 via the Module Dispatcher 6-414 to create the necessary DDCB 4 6-420A or 6-420B. Decision block 5-20 loop~ on block 5-18 until all of the necessary DDCB 6-420A and 6-420B
are created.
Then in block 5-22 the Application Module 6-422 : through 6-430 returns control to the IORB Processor 6-402.
Decision block 5-24 checks for errors including those from decision blocks 5-12 and 5-14. If there wer~ errors then in block 5-28, the error is posted in the IORB Word Offsets 2 and 9. In block 5-26 the IORB
. .
. ~. : . . .
,::
'' . ' ' : ' ~ 1 325~83 Processor 6-402 calls the Queue Manager 6-412.
Decision block 5-30, figure 5D, first checks to see if any DDCBs need to be posted.
Decision block S-32 then checks if any DDC~s can be issued to the Lower Layer Service Provider 6-6. If DDCBs can be issued then in block 5-34, the Queue Manager 6-412 calls the Workstation Control ~anager 6-418 and sends the DDCB to the appropriate Provider Module 6-422 through 6-446 vi~a the Module Dispatcher 6-414. This operation is repeated through decision block 5-32 and block 5-34 until all of the DDCBs have issued. Then block 5-36 returns control to the Process Manager 6-416 and in block 5-38 control returns to the Operating System 6-1 and the operation is completed.
lS If in decision block 5-30, there are DDC~s to be posted then block 5-40, figure 5E, the Queue Mana~er 6-412 posts one DDCB. If the status word in the DDCB
indicates an error then the error vector is called.
The creator of DDCB ~usually the Application Module) tries to correct the error. Posting the DDCB calls for the Queue Manager 6-412 to test the interrupt vector.
I f this is not zero and the DDCBs status words do not indicate an error, then the function pointed to by the interrupt vector is called. This is usually a function in the Application Module. The status words are copied to the PMCB and is written into Word Offsets 8, 9, 12, 13, 14, 16 and 17 of the IORB.
Decision block 5-42 tests if there are more DDCBs to be posted. If so, block 5-40 posts them. When the last DDCB is posted then decision block 5-44 tests if there are any more DDCBs left on this PMCB.
;, ~ , ` If there are DDCBs r~maining on this DDC8 then in block 5-48 control passes to the caller, in this case the Queue Manager 6-412. If there are no DDCBs left in this PMC~ then in block 5-46 the PMCB status is copied back to the IORB and the IORB Processor 6-402 is called to post the IORB back into the Application 6-2. Then in block 5-48 this post process returns to the caller.
What is claimed is:
~. ' ~ ' ` ' ",
Field of Use . . _ This invention relates to the data processing field and more particularly to data communications software which conn~cts the data processing 3ystem to a variety of terminals requlring different communicat:ion technologies.
Description of the Prior Art Over the years the data processing ~ystems have changed from batch processing applications to interactive system applications. In a batch processing application, all of the processing i~ done at the computer site including all input into the data proce-~sing system.
As the technology impro~ed, particularly in the terminal area, operators at remote terminals would key into their terminal and the information would be transferred to the central computer over communication lines. This required communication controllars at the computer site and software to drive these communication controllers. The sof~ware developed at that time was written in a low level assembly language, was designed for use with a specific communications technology and further de~igned to provide specific modes of ~pplication qupport. The terminals were also limited by having fixed data code characteristic~.
Thi~ type of communication'~ controller hardware and software design presented a number of problem~. The software was very difficult to maintain and modify. This i8 particularly true if the software had to be extended to support a new terminal which was added to the sy~tem.
, , ..
, ` 1 325483 Today terminals are being built with new and evolving technology in the communication~ area. However, the sof tware in the central system is too rigid to adapt to these n~w ~echnologies. If these terminals require S extended ~odes of application support, it is difficult to adapt the software.
.
OBJECT I VES OF T~IE I NVENT I ON
Accordingly, it is an objective of the invention to provide an improved communication subsyste~ which is readily adaptable to support additional terminals.
It is another ob~ective of the invention i~ to provide an improved communication subsystem which is readily adaptable to adding new modes of application support.
,, . ' ~ ' ,:
'~:
- 1 3 2 5 ~ ~ 3 72434-96 SUMMARY OF THE INVENTION
In addition to the hardware, a data communication subsystem includes a number of elements. These elements include Appllcations Software, a Network Terminal Driver and a ~ower Service Provider.
The Applications Software initiates actions to cause the communication subsyskem, including the terminals, printers and the users to perform prescribed functions to accompllsh a specified job.
- 10 The Network Terminal Driver includes a number of Application Modules, a number of Provider Modules and a number of Device Profiles all operative with a number of co~mon Kernel Components.
~ The Application Modules interface with their respective ; applications software to support the specified modes of operation.
.
The Kernel includes a number of common components which interact ;
with the Application Modules, the Provider Modules and ~he Device Profiles to execute the Applica~ion Software requests.
~^ In accordance with the present invention, there is provided a communication subsystem in a data processlng system comprising: Application means for generating first requests for said system to perform prescribed functions to accomplish a specified job Network Terminal Driver means coupled to said ` application means and responsive to said first reguests for .~ generating a plurality of control buffers, said Network Terminal .;
- Driver means including first and second module means responsive to ~` information stored in said plurality of control buffers for ,. . .. ~ - . . . .
.
~ 325~3 yenerating a sequence of orders; Terminal means coupled to said Network Terminal Driver means and responsive to said sequence of orders for pèrforming said prescribed functions.
In accordance with another aspect of the invention, there is provided in a data processing system comprising: a central processlng unit (CPU); a memory unit connec~ed to the CPU
for storing system program~ and application programs to be run by the CPU and for storing data to be operated upon hy the progxams;
a plurality of terminals of one or more ~ypes at which users enter commands requesting application programs to be run by the CPU and view results of those programs; and one or more communications media of one or more types, each for interconnecting the CPU with certain oE the terminals of the plurality of terminals, a network terminal driver operatively connected between the CPU and the communications media for facilitating communications bet~een the application programs and the plurality of terminals, the network terminal driver comprising: a plurality of application modules, each associated with a~different data forma~ used by the application programs, for specifying data formats being used by each of the application programs; a plurality of provider modules, each associated with a different one of the types of communications media, for specifying the characteristics of eacb of the communications media; a plurality of device profiles, each associated with a different one of the types of terminals, for specifying the characteristics of each of the ~erminals; and means Fesponsive to said specification of data formats, communications media characteristics, and terminal characteristics for 3a ~' ; ~, , ,, : ~ . : .
,:; .
, . .
.
1 325~3 interpreting transmissions from the communications media and assembling messages to the communications media according to sald specifications of data formats, communications media characteristics, and terminal charac~eristics.
BRIEF DESCRIPTION pF THE DRA~INGS
Figure 1 shows an overall block diagram of a data `, processing system including a communication subsystem.
Figure 2 shows an overall block diagram of a Network ~erminal Driver of the communication subsystem.
,' 10 Figure 3 shows a detailed block diagram of the flow of lnformation through the Network Terminal Driver.
Figure 4A shows the interconnection between the request block and control block data structures which execute an order.
Figure 4B shows the layout of an Input Output Request Block (IORB) data structure.
1~
, 3b 1 . .. . : . : ~ .
:: -.
.
. 1 325~83 ~ Figure 4C shows the la-yout of ~ Provider Module Control : Bloc~ (P~CB) data ~tructure.
Figure ~D shows the layout of a Device Descriptor Control Block (DDCB) data structure.
sFigures SA-SE shows a flow diagram of a typical operation of the Nstwork Terminal Driver.
DESCRIPTION OF THE PREFERRED EMBODIMENT
Referring to Figure 1~ a data processing sy~tem 1 includes a Control Proce~sor ~CPU) 2, ,a main memory 6, a number of peripheral Gontrollers 20, .a number of communication controller~, typically, a Lecal Area Network (LAN) controller 8 and an MLX~16 Proce~or 10, all coupled in common to a system bus 4. A number of devices typically are coupled to MLX-16 ProcQssor 10.
lS The e device~ may include a remote terminal A 14/ a printer 16 and a work~tation A 18. A printer B 16 may be coupled to workstation A 18.
A number of devices, typically, terminal B 14 and terminal C 14, are coupled to a terminal concentrator ~C-6 12, which is, in turn, coupled to the LAN
controller 8 by a LAN medium 22. Medium 22 could typically be an IEeE ~02.3 Interface.
Main memory 6 includes a number of software units;
an Operating System (OS) 6-1, Application Software 6-2, a Network Terminal Dri~er (NTD) 6 4, and a Lower Layer Service Provider 6-6. Typical Application Software 6-2 includes office ~ystems, word processing systems, data entry facilitie~ and database management systems. The Lower Layer Service Provider 6-6 contains the ~pecific ~oftware for communicating with ~he hAN controller a and the MhX-16 Processor 10 via the system bus 4 under control of CPU 2.
, . -4 -.. .. .
' .
,,: . ' ~ . ':: -: . : .
,, , The NTD 6-4 includes the software module that permit the user operating from a terminal 14 or workstation 18 to use a selected application stored in ~pplication 6-2. The NTD includes several Application Modules (AM) 6~420, a Kernel Module 6-400, several Provider Modules 6-440 and several Device Profiles 6-460. The NTD 6-4 operates in a number of different modes depending on the type of device being supported and the way in which the applications software in Applications 6-2 utilizes the device.
An administration mode Appiication Module provides an interface to the devices which i8 used internally by the NTD 6-4 for device configuration and status inquiry, and is used by the applications software in Applications 6-2 for operations such as print screen.
A Message Mode Application Module supports a line at a time entry even thou~h the data transfers between the terminal and the host takes place on a character basis. The CPU 2 i~ interrupted at the completion of a line of data.
A field mode Application Module supports a field at a time entry, even ~hough the data transfers between the ~erminal and the host take place on a character basis. The type of data to be entered into the field is specified by the Application 6-2 and checked by NTD
6-4. The CPU 2 is interrupted at the compleSion of each field of data.
A block mode Application Module provides support for Application Software which operates with the intelligent terminal. Data transfers between the terminal and the host are in typically 256 byte blocks.
A printer m~de Application Module prv~ides support for both stand alone printers and those connected via a buflered printer adapter in a terr,inal or workstatlon.
;
.
''. ~ ' , ~, ,"~
.
: .
" ~
.
1 325~83 ~~ A polled VIP mode Application Module provides an interface to applications that are operative with the MLX-16 Processor 10 that have terminals 14 and workstation~ 16 operating in a polling mode.
-~ 5 The Application Modules 6-420 interface to the applications software in Application 6-2, one Application Module 6-420 for each mode of operation.
.` The Provider Modules 6-440 provide the necessary software for the NTD 6-4 to communica~e with the communications controllers for the various supported `. communications technologies such as; the LAN controller 8 or the MLX-16 Processor 10 via the Lower Layer Service Provider 6-6.
Figure 2 provides a more in-dep~h picture of the .. 15 internal struc~ure of the four ma~or components of the ., NTD 6, namely, the Kernel 6-400, the Application 3 Modules 6-420, the Provider Modules 6-440 and the Device Profiles 6-460.
i' The NTD 6 includes the Kernel 6-400 which ha~
common interfaces to all o~ the Provider Modules 6-440 and the Application Modulas 6-420. This allows for a new Provider Module or new Application Module to be , added to the system without modification to the Kernel 6-400. The Application ~odules 6-440 communicate with the terminal 14 or workstation 18 in the different modes, via an Admini~trative Mode 6-421, a Message Mode ', 6-422, a field mode 6-424, a block mode 6 42S, a . printer mode 6-428 or a polled VIP mode 6-430.
jl The Provider Modules 6-440 provide the required ~i 30 ~oftware interface to the Device Profiles 6-460. The .~ Provider Modules ~-440 include a LAN interface 6-442, an MLX-16 interface 6-444 and a Public Da~a Network (PDN) lnterfwe 6-446.
_ ~ _ .
,, .
.. . . .
.~ .
.''. ~
~~~ There is a Device Profilel ~o2r eac~ type of device coupled to the LAN controller 8 and the MLX-16 Processor 10 as well as any other technologies.
Typical Device Profiles are Teletype (TTY) profiles 6-46Z, VIP 7201 profiles 6-464, VIP 7300 profiles 6-466, VIP 7800 profiles 6~468, HDS 2 profiles 6-470, HDS7 profiles and X3.64 profile~ 6-472.
The devices are typically Honeywell Bull Inc.
VIP7201, VIP7300, VIP7800, HDS2, HDSS, HDS7 and X3.64 workstations. Each Device Profile may contain a table with the following information:
a) profile name b) profile description c) workstation identifier d) code set supported by the workstation e) modes support by this profile f~ system device and driver identity g) all character sequences required for NrD 6-4 to interact with the workstations.
This approach permits the adding of new devices without major changes to the software.
Thé Kernel 6-400 i made up of a number of components, including an Input Output Request 81Ock (IOR~) processor 6-402, a Monitor Call tMCL) Proce~or 6-404, a Connect Processor 6-406, a Disconnect Proce~sor 6-408, a Timeout ~anager 6-410, a Queue Manager 6-412, a Module Dispatcher 6-414, and a Process Manager 6-416.
The IOR~ Processor 6-402 handles Input Output Reque~t Blocks tIORB) 6-20 which contain information on the structure of the data being tran~ferred between main m~mory 6 and a specific terminal 14, printer 16 or ;:
; :
workstation 18~ The IOR8 P~ 402 defines and va}ida~es the characteristics and constraints upon the data being transferred.
Typical restraints are the range, the maximum number of characters being transferred during this data transfer, and th~ starting address, the main memory 6 location from which the first character is read, or to ~` which the first character is written. Also other information in the IORB 6-20 specifies special control sequences to be sent to the termina:L such as cursor . positioning, bell or display attributes. During the ,.'3 Message Mode operation, therefore, an IORB 6-20 would ',3 be passed on to a Message Mode 6 422 of Application Modules 6-420 for further processing.
A Process Manager 6-416 identifies a requestor of an activated task and the requested task, obtains th~
, necessary data structures, sets up the C language environment and dispatches program control to the NTD
6-4 component responsible for receiving the request.
All processes dispatched by the Process Manager 6-416 ~' are returned for proper termination.
' The MCL Processor 6-404 interfaces with the OS 6-1, ''3 receives calls from OS 6-1, provides main memory 6 ~ space for having NTD 6-4 execute the call and manages 1 25 the return to OS 6-1. The MCL Processor 6-404 also may change certain configuration parameters specified in ,3 the Device Pro~ile 6-460 for the terminal 14 ~r o workstations 1~.
;~ The Connect Processor 6-406 manages the common connect responsibilitie~ including establishing and monitoring the connection of NTD 6-4 to ~pplication 6-2, and initiates configuring the terminals 14 and workstation 18 and any remote devices (not shown) involved in the communication.
~, . .
,3 _ ~ _ , .
:, , : ' ' ~ : : ' '. ,,; ' `~
~ 325483 ,_~
The Disconnect Processor 6 406 manages the common disconnect responsibilities for all the modes supported by NTD 6-4. The Timeout Manager 6-410 makes use of the OS 6-1 Clock Manager to set up a timer, which generates S a timeout if a specific operation being measured is not completed within the specified time. The system recognizes the error, posts it, and continues operation.
The Queue Manager 6-412 provides control supporting routines to be used in common by all Provider Modules 4-440. This support includes managing the Provider Module Control Block (PMCB) 6-402A queues for each workstation 18 and terminals 14 and manage one related typed data Device Dri~er Control Block (DDCB) 6-420A
queue for each workstation 18 and devices 14.
A Module Dispatcher 6-414 ties together the Provider Module 6-440 and the Application Module 6-420 employed for the device. The Application Modules 6-420 need not know which Provider Module 6-440 will handle the call. The Module Dispatcher 6-414 maps the call to the Provider Module 6-442, 6-444 or 6-446 for servicing.
Figure 3 shows the operation of the NTD 6. A user at a terminal 14 or workstation 18 sélects: an application and writes to the Cathode Ray Tube (CRT~
screen at the terminal 14 or workstation 18. The Application 6-2 working with the user issues a write IORB to NTD 6.
The IORB Processor 6-402 begins to process the write IORB. The IORB Processor 6-402 makes sure the address location of the required data in main memory 6 i-~ valid and the number of characters, the range, data that will be transferred to the worXstation 18. The . ~ , ~ , , .
I .-: , 1 325~83 ; ~ IORB Processor 6 402 further checks that the options available to the terminal 14 or works~ation 18 are allowed.
Write IORBs require additional mode specific processing so the IORB is passed to the ApplicationModule 6-420. For example, if a word processing application is in effect, then the field mode 6-424 application module would perform a field mode specific procedure to validate the write operation.
10Connect and Disconnect IOR~s are handled in the same manner, but would require common processing as well as mode specific processing.
The IORB processor 6-402 passes a Connect IOR~ to the Connect Processor 6-406 to perform a common connect procedure before the Application Module 6-420 perform any mode specific connect processing.
Similarly, after the Application Module 6--402 performs any mode specific disconnect processing, the Disconnect Processor 6-408 performs a common Disconnect procedure. In either case, the Application Module 6-420, Connect Processor 6-406 or Disconnect Processor makes calls to the Provider Module Service Calls 6-440A
via the Module Dispatch~r 6-414 to generate micro order~ ~DDCBs) to continue processing the IORB and ultima~ly accompli~h the original request of the application as specified in the IORB. The DDCBs 6-420B
created for an Application Module 6-402 have a ~ode specific purpose while DDC~s 6-420A created for either the Connect or Disconnect Processor are for purposes common to all application processing modes (eg. common to field mode, message mode, etc.).
.
, . , , . , -.;
. ', .
1 325~83 The appropriate Provider Module 6-440 is selected by the Module Dispatcher 6-414 in accordance with the hardware arrangement. Terminals connected to the LAN
Controller 8 operate through the LA~ Interface 6-442.
Similarly, terminals connected to the MLX-16 Processor 10 operate through the MLX-16 Interface 6-444.
;~ The IORB Processor 6-402 attaches a Provider Module Control Block (PMCB) 6-402A to the original application IORa 6-20. There is one PMCB 6-402~ for each application IORB 6-20 that is issued to NTD 6-4. The PMCB 6-402A points to a string of Device Descriptor Control Blocks (DDCB) 6-420A and/or 6-420B. These are , the string of micxo instructions that execute the action requested by the application. When calls are made to the Provider Module Service Call~ 6-440A, DDCBs 6-420A or 6-420B are generated and attached to the PMCB
6 -4 02A .
j The PMCB 6-402A and DDCB 6-420A and/or 6-420B are ; then passed to the Queue Manager 6-412. The Queue ,l 20 Manager 6-412 takes the PMCB and DDCBs and puts it in a queue for the re~uested terminal. The Queue Manager 6-412 issues the DDCBs, one at a time, to the Workstation Control Manager 6-420D. The Workstation ~ Control Manager 6-420D performs any necessary `3 25 work~tation 18 or terminal 14 specific proce~sing ~hat . must be done to in3ure that the DDCB will reach the proper device, and passes the DDCB to the PM 6-440B.
Here again the Module Dispatcher 6-414 selects the proper PM 6-442, 6-444 or fi-446 by issuing the DDCB
6-420A or 6-420B to the Lower Layer Service Provider ~, 6-6, which, in turn, will perform the specified micro-operation on the requested terminal 14 or workstation 18.
, ~ .
~ ~ .
, ':1 1, ''"~: " ' '' ; ' ' ' ' .
. ~ .
-' : .
1 32~483 .
r~ The Queue Manager 6-412 continues to issue DDCB
6-420A or 6-42ûB until some Icind of blocking condition i~ met. ~or example, the PM 6-440b will set up write and read DDCB credits which detennine how many read and write DDC:~s the Queue Manager 6-412 can have outstanding at a time for that terminal 14 or workstation 18.
When the Provider Module 6-44Qb .is finished with the DDCB 6-420A or 6-420B, it calls the Queue Manager 6-412 post/dequeue. The Queue Manager 6-412 then copies any pertinent status into the PMCB 6-4Q2A and calls the Application Module 6-420 i neces~ary.
When all of the DDCBs 6-420A and/or 6-420B
associated with the PMCB 6-402A have been issued and posted, the Queue Manager 6-412 will call the IORB
Processor 6-402 to pos'c that IORB 6-20 and return it to the application.
Figure 4A shows the structures involved in the processing of an operation. The Application 6-2 generates an IORB 6-20. The Operating System (OS) 6-1 receives the IORB 6-20 and creates an Indirect Request Block 6-10 (IRB). The IRB's 6-10 are used by the OS
6-1 for handling various kinds of requests. The IORBs are just one level of request handled by the IRE3~s.
The IORB 6~20 and the IRB 6-10 are passed to the NTD 6-4. The IORB Processor 6-402 verifies that the IORB 6-20 is valid, and if so, the IRB 6-10 will be pointed to a Provider Pqodule Control Block (PMCB) 6-402A.
The PMCB 6-402A is used for maintaining the status of the overall operation during the execution of the micro orders in respon~3e to the IORB 6-20. The Provider l~odule 6-440 creates a number of Device Drive : ., 1 325~83 ,. ~~ Control Blocks (DDCB) on behalf of either the Application Module 6-420 Connect Processor or Disconnect Processor. The Queue Manager 6-412 issues the DDC~s one at a time.
A~ an ex~mple a DDCB 6-420A could be sent ~o the terminal 14 or workstation 18 via the Lower Layer Service Pro~ider 6-6 and MLX-16 Processor 10 to ', e.~tablish a connection between the terminal 14 and ~he workstation 18 and Application 6-2 then a DDCB 6-420B
would be sent to terminal 14 or workstation 18 via the . Lower Layer Service Provider 6-6 and MLX 16 Processor 10 to send the cursor to a particular part of the terminal 14 or workstation 18 screen. Still another DDCB 6-420B would send data to the terminal 14 or workstation 18 for display. Yet another DDCB 6-420B
would return the cursor to its original position on the screen.
Referring to figure 4B, the IORB 6-20 includes an inventory of 16 bit words having bit po~itions hexadecimal O through F. Word Offsets 0 and 1 point to the IR8 6-10 in main memory 6 and is man~ged by the OS
6-1.
Word Offset 2 includes a return statu byte to indicatej for example, if the device was unavailable, or the operation was aborted, or there was invalid information paYsed to the device by the application.
The left byte of Word Offset 3 contains the Logical . Resource Number (LRN) which identifies the device for which IORB 6-20 is intended, that is, the terminal 14 or printer 16 or workstation 18, etc. The right byte includes the function code which describes the operation the IORB 6-20 is to perform. Typical function6 are connect, disconnect, read or write. The .
.
...
, ~ .
r~ B bit in position 9 indicâtes if the buffer starts in the left hand or right hand byte of the word. The E
bit in position B indicates that the IORB 6-20 is extended for at least 10 words. The IORB 6-20 normally ends after Word Offset 9. The extension is typically used for field mode and its size is always stored in ; Word Offset 10.
Word offsets 4 and S contain the two word (32 bit) starting address in main memory 6 o~E the data buffer ;i 10 which stores the data involved in the transfer between the device and main memory 6 if this is a tr~nsfer IORB
6-20. Word Off~et 6 stores the range, that is ~he number of bytes being transferred.
Word Offset 7 is a device specific word. It lS includes bits indicating the options to include with `; the order. As an example, for the Field Mode 6-404 application, a bit specifies that data keyed for a read i IORB 6-20 is also displayed on the screen.
;~` Word Offset 8 indicates at the completion of an order, the number of bytes not tran~ferred.
Word Offset 9 stQreS the Device Status Word 1 which `A' provides additional sta~us to the status stored in Word Offset 2. An example would be to indicate if a parity error was sensed by the Lower Layer Service Provider 6-6 during a read operation.
Word Offset 10, byte 1 stores the number of words the IORB 6-20 is extended by. Byte 2 stores the number ~i of wor~s in the IORB 6-20 extensions. This word i5 only present when the E bit position in Word Offset 3 is set to logical one.
/~
., ' , , ~ .
i ,, .
.
f:
, ' ' . ' ' ' ., .
,,,, , ' ' ,~, 1 325~83 . ~ Device Specific Word 2 of Word Offset 11 provides ;: further information on how the order is to be processed. In Field Mode, for example, this Word Offset would specify the validation criteria, either a standard or a special validation set.
Word Offset 12 indicates ~ome of the physical characteristics of executing the order; for example, 3. the number of key strokes used by the operator. It also provides information for the supervisory message line at the bottom of the display screen at connect time.
Word Offset 13 serves two purposes. Initially for Field Mode reads, it contains an offset to the field position where data entry should begin. Finally when the read is completed it stores an indication of the number of remaining characters ready for immediate processing upon receiving the next read order from the application. This enableq the application to create the next read IORB with a range large enough to handle the remaining characters.
Word Offset 14 stores additional status information. For example, during Field Mode it indicates that valid data was entered into the field by the operator.
Word Offset 15 contains information for the application to determlne ~he location of the cursor at the completion of the order.
Word Offset 16 contains information that identifies the character keyed by the operator that terminated the read order. Word Offset 16 also stores an indication of whether or not an illegal entry wa~ made.
' .
;- ~ . , ~ . . . .
; 1 325~83 Word Offset 17 has multiple purposes. Initially it provides pre-order information. As an example, it could send a line feed, carriage return character before starting the order. It may also set the display attributes for the order such as low intensity, blink and inverse video. Word Offset 11 bits define the U58 of Word Offset 17. Upon termination of the read order it indicates the characteristics that the illegal entry did not satisfy. For legal entry it may contain additional read termination information.
-~ Word Offset 18 provides the first word of the descriptor for a read operation. The descripter - specifies the characteristics of the data to be entered into the field.
15Figure 4C shows the contents of the PMCB 6-402A.
The PMCB 6-402A is associated with an IORB 6-20 by the IORB Processor 6-402. It is used to hold together all the micro orders (DDCBs) associated with this IORB
6-20.
20The PMCB Control Word indicates the type of PMCB
6-402A this is. IORBs 6-20 specify read operation3 and write operations for the Application Modules 6-420.
The Control Word also provides information to the Queue Manager 6-412 such as "purge~' which indicates that this 25PMCB 6-402A should be deleted, 'modify~ which indicates that information has been added to or removed from ~he PMCB. This informs the Queue Manager 6-412 to l initialize an internal pointer.
The Queue Link to next PMCB is used to locate the 30next PMC~ 6-402A in ~he queue. A number of PMCB's may , be queued to process the application's requests The PMCB's IORB pointer stores the memory 6 location of its associated IORB.
.. . . .
s , . . . :
.:
,.-, . ': .
` 1 325483 ; ~ Error Status 1 gets copied into the left byte of Word Offset 2 of the IORB 6-20.
Return Status 1 and Return Status 2 are continually updated by the DDC8s and in turn update Word Offset 9 and Word Offset 14 of the IORB 6-20 at the conclusion ; of the order.
Residual Range is transferred to Word Offset 8 at the end of the order to indicate the number of bytes not transferred.
The D~CB Chain Queue Header points to the first DDCB in the chain to be processed.
Figure 4D shows the contents of ~he DDCB. The DDCB
Control Word identifies the type of micro order, that is, a write, a write control, a r~ad, no-operation (NOP) or an event. Also included is a bit indicating that this DDCB is marked for deletion. Another bit indicates that this DDCB has been sent to the lower level service provider 6-6 and is awaiting posting.
The Queue Link to next DDC8 links this Link DDCB to the next DDCB in the queue.
The PMCB pointer field point~ ~o its associated PMCB 6-402A.
The IORB pointer, when used, indicates that the poin~er to the Data ~uffer is that of the IORB Data Buffer as opposed to an internal NTD Data Buffer.
Th~ Pointer to Data Buffer points to the starting address of either the IORB Data Buffer in main memory 6 or an NTD internal data buffer in main memory 6. These Data Buffers are only specified for a Data Transfer DDCB.
Data Buffer Range specifies the nu~ber of bytes in the Data Buffer.
Residual Range ~pecifies the number of bytes not transferx d.
~ ~17-.
:, "
1 325~83 Error Status stores an indication of errors sensed during processing.
Return Status 1 and Return Status 2 update the respective fields in the PMCB.
Queue Control Info is used by the ~pplication Module 6-420 to tell the Queue Manager 6-412 how to treat this micro order and how the processing of this DDCB micro order will affect the processing of other DDCBs on this queue.
Application Module SpPcific Status Area stores the Application specific status of thi~ micro order and updates Offset Words 12 through 17 of the IoRa 6-20.
The interrupt vector is genera~ed by the creater of the DDCB if more processing is needed when this DDCB is posted.
The error vector is used by the Queue Manager 6-412 to point to an error processing routine specified by the creator of the DDCB in the event of an error during the processing of this DDCB.
The Clock Request Block specifies the timeout associated with this order. When the order is issued, the Operating System uses the information to set a clock and start a timer. If the timer expires beore the DDCB is posted, then an error condition is recorded.
Figures 5A through 5E describe a typical write NTD
6-4 operation. When the Application 6-2 re~uests a communication with a user, a number of IORBs 6-20 are generated. They connect NTD 6-4 to the terminal 14 or woxkstation 18 to establish a connection. This allows the user to turn the terminal 14 or workstation }8 on.
An IORB 6-20 also establishes a read operation. This requeets the operater to enter data for examination by the Application 6-2.
', :
. .
., , . : .
.
'; ' ~ '~:' ;
-~ 1 325483 ~ ~ A write IORB, sends information from the `~; Application 6-2 to the terminal 14, printer 16 or workstation 18. Figures SA, 5B, 5C, 5D and 5E explain what the NTD 6-4 does when it receives an IO~B from the . 5 Application 6-2. Whether the IORB calls for a connect, ` disconnect, read or write operative, NTD 6-4 goes through the same processing steps.
!/ For this example, once the terminal 14 or ;~ workstation 18 is connected, the connect channel program in the MLX-16 Processor 10 wi.ll interrupt the NTD driver and the NTD 6-4 will run until the entire connect IORB has been procesed.
~` Referring to figure 5AL in block 5-2 the Operating System 6-1 takes an IORB 6-20 from Application 6-2 and passes it to NTD 6-4. In block 5-4, the Process Manager 6-416 takes the IORB 6-20 and passes it ~o the IORB Processor 6-402.
. In decision block 5-6, the IORB Processor 6-402 ` checks the Function Field (bits C-F) of Word Offset 3, figure 4B of the IORB 6-20 to see if it is consistent with the current ~tate of the terminal 14 or workstation 18. For example a write would not be . allowed against a device that has not been connected.
If the test fails, then block 5-16 posts the ~ORB
6-20 with an error. If the test is successfulf then decision block 5~8 test the validity of the common IORB
options which are specified in Word Offsets 7, 10, and 11. These op~ions include that the proper Application Module of Application Modules 6-420 and that the proper .~ 30 type of device terminal 14, printer 16 or workstation 18 are connected. Here again, an unsuccessful tes~
results in block 5-16 posting the IORB 6 20 with an error.
!~
~ -19-,. .
.
. . ', ,~ .
I 325~83 ~~ If the test is successful then in block 5-9 the IORB Processor 6-402 creates a PMCB 6-402A for the IORB
6-20.
Decision block 5-11 tests if there are any co~mon S DDcBs S-420A to be created and if so block 5-13, figure 5B, calls the selected Provider Module 6-442 through 6 446 via the Module Dispatch~r 5-414 to create the DDCB 6-420A.
Decision block 5-15 tests if anymore DDCB 6-420A
are to be createdO If so then block 5 13 again performs as described supra.
After all the required common DDCB 6-420A are crea~ed ox decision block 5-11 in~icates that no common DDCB 6-420A are to be created then in block 5-10, ~he lS IORB Processor 6-402 calls the appropriate Application Module 6-422 through 6-430 via the Module Dispatcher 6-414.
Decision block 5-12 then tests if the mode specific options are valid. If so, then decision block 5-14 tests if there are any mode specific DDCBs 6-420B are to be created. If so block 5-18, fi~ure 5C, calls the proper Provider Module 6-442 through 6-446 via the Module Dispatcher 6-414 to create the necessary DDCB 4 6-420A or 6-420B. Decision block 5-20 loop~ on block 5-18 until all of the necessary DDCB 6-420A and 6-420B
are created.
Then in block 5-22 the Application Module 6-422 : through 6-430 returns control to the IORB Processor 6-402.
Decision block 5-24 checks for errors including those from decision blocks 5-12 and 5-14. If there wer~ errors then in block 5-28, the error is posted in the IORB Word Offsets 2 and 9. In block 5-26 the IORB
. .
. ~. : . . .
,::
'' . ' ' : ' ~ 1 325~83 Processor 6-402 calls the Queue Manager 6-412.
Decision block 5-30, figure 5D, first checks to see if any DDCBs need to be posted.
Decision block S-32 then checks if any DDC~s can be issued to the Lower Layer Service Provider 6-6. If DDCBs can be issued then in block 5-34, the Queue Manager 6-412 calls the Workstation Control ~anager 6-418 and sends the DDCB to the appropriate Provider Module 6-422 through 6-446 vi~a the Module Dispatcher 6-414. This operation is repeated through decision block 5-32 and block 5-34 until all of the DDCBs have issued. Then block 5-36 returns control to the Process Manager 6-416 and in block 5-38 control returns to the Operating System 6-1 and the operation is completed.
lS If in decision block 5-30, there are DDC~s to be posted then block 5-40, figure 5E, the Queue Mana~er 6-412 posts one DDCB. If the status word in the DDCB
indicates an error then the error vector is called.
The creator of DDCB ~usually the Application Module) tries to correct the error. Posting the DDCB calls for the Queue Manager 6-412 to test the interrupt vector.
I f this is not zero and the DDCBs status words do not indicate an error, then the function pointed to by the interrupt vector is called. This is usually a function in the Application Module. The status words are copied to the PMCB and is written into Word Offsets 8, 9, 12, 13, 14, 16 and 17 of the IORB.
Decision block 5-42 tests if there are more DDCBs to be posted. If so, block 5-40 posts them. When the last DDCB is posted then decision block 5-44 tests if there are any more DDCBs left on this PMCB.
;, ~ , ` If there are DDCBs r~maining on this DDC8 then in block 5-48 control passes to the caller, in this case the Queue Manager 6-412. If there are no DDCBs left in this PMC~ then in block 5-46 the PMCB status is copied back to the IORB and the IORB Processor 6-402 is called to post the IORB back into the Application 6-2. Then in block 5-48 this post process returns to the caller.
What is claimed is:
~. ' ~ ' ` ' ",
Claims (10)
1. A communication subsystem in a data processing system comprising:
Application means for generating first requests for said system to perform prescribed functions to accomplish a specified job;
Network Terminal Driver means coupled to said application means and responsive to said first requests for generating a plurality of control buffers, said Network Terminal Driver means including first and second module means responsive to information stored in said plurality of control buffers for generating a sequence of orders;
Terminal means coupled to said Network Terminal Driver means and responsive to said sequence of orders for performing said prescribed functions.
Application means for generating first requests for said system to perform prescribed functions to accomplish a specified job;
Network Terminal Driver means coupled to said application means and responsive to said first requests for generating a plurality of control buffers, said Network Terminal Driver means including first and second module means responsive to information stored in said plurality of control buffers for generating a sequence of orders;
Terminal means coupled to said Network Terminal Driver means and responsive to said sequence of orders for performing said prescribed functions.
2. The communication subsystem/claim 1 wherein said first module means comprises:
Kernel Module means responsive to said first requests for generating one of said plurality of control buffers and a plurality of second requests.
Kernel Module means responsive to said first requests for generating one of said plurality of control buffers and a plurality of second requests.
3. The communication subsystem of claim 2 wherein said first module means further comprises:
Application Module means coupled to said Kernel Module means and responsive to said one of said plurality of control buffers for generating a plurality of third requests.
Application Module means coupled to said Kernel Module means and responsive to said one of said plurality of control buffers for generating a plurality of third requests.
4. The communication subsystem of claim 3 wherein said first module means further comprises:
Provider Module means coupled to said Kernel Module means and responsive to said plurality of second requests for generating a common set of said plurality of control buffers for each of said one of said plurality of control buffers;
and responsive to said plurality of third requests for generating a specific set of said plurality of control buffers.
Provider Module means coupled to said Kernel Module means and responsive to said plurality of second requests for generating a common set of said plurality of control buffers for each of said one of said plurality of control buffers;
and responsive to said plurality of third requests for generating a specific set of said plurality of control buffers.
5. The communication subsystem of claim 4 wherein said second module means comprises:
said Kernel means responsive to both said common set and said specific set of said plurality of control buffers for managing a sequence of both said common set and said specific set of said plurality of control buffers;
said kernel means being further responsive to first indications from said Provider Module means for managing said sequence.
said Kernel means responsive to both said common set and said specific set of said plurality of control buffers for managing a sequence of both said common set and said specific set of said plurality of control buffers;
said kernel means being further responsive to first indications from said Provider Module means for managing said sequence.
6. The communication subsystem of claim 5 wherein said second module further comprises:
said provider module means responsive to said sequence of both said common set and said specific set of said plurality of control buffer for generating said sequence of orders;
said Provider Module means is further responsive to second indications from said terminal means for generating said first indications.
said provider module means responsive to said sequence of both said common set and said specific set of said plurality of control buffer for generating said sequence of orders;
said Provider Module means is further responsive to second indications from said terminal means for generating said first indications.
7. The communication subsystem of claim 1 wherein said first requests are Input Output Request Buffers.
8. The communication subsystem of claim 2 wherein said one of said plurality of control buffers is a Provider Module Control Block.
9. In a data processing system comprising:
a central processing unit (CPU);
a memory unit connected to the CPU for storing system programs and application programs to be run by the CPU and for storing data to be operated upon by the programs;
a plurality of terminals of one or more types at which users enter commands requesting application programs to be run by the CPU and view results of those programs; and one or more communications media of one or more types, each for interconnecting the CPU with certain of the terminals of the plurality of terminals, a network terminal driver operatively connected between the CPU and the communications media for facilitating communication between the application programs and the plurality of terminals, the network terminal driver comprising:
a plurality of application modules, each associated with a different data format used by the application programs, for specifying data formats being used by each of the application programs;
a plurality of provider modules, each associated with a different one of the types of communications media, for specifying the characteristics of each of the communications media;
a plurality of device profiles, each associated with a different one of the types of terminals, for specifying the characteristics of each of the terminals; and means responsive to said specification of data formats, communications media characteristics, and terminal characteristics for interpreting transmissions from the communications media and assembling messages to the communications media according to said specifications of data formats, communications media characteristics, and terminal characteristics.
a central processing unit (CPU);
a memory unit connected to the CPU for storing system programs and application programs to be run by the CPU and for storing data to be operated upon by the programs;
a plurality of terminals of one or more types at which users enter commands requesting application programs to be run by the CPU and view results of those programs; and one or more communications media of one or more types, each for interconnecting the CPU with certain of the terminals of the plurality of terminals, a network terminal driver operatively connected between the CPU and the communications media for facilitating communication between the application programs and the plurality of terminals, the network terminal driver comprising:
a plurality of application modules, each associated with a different data format used by the application programs, for specifying data formats being used by each of the application programs;
a plurality of provider modules, each associated with a different one of the types of communications media, for specifying the characteristics of each of the communications media;
a plurality of device profiles, each associated with a different one of the types of terminals, for specifying the characteristics of each of the terminals; and means responsive to said specification of data formats, communications media characteristics, and terminal characteristics for interpreting transmissions from the communications media and assembling messages to the communications media according to said specifications of data formats, communications media characteristics, and terminal characteristics.
10. The data processing system recited in claim 9, wherein further:
a certain application program encountering an instruction directing it to communicate with a certain terminal generates and forwards to the network terminal driver a first request block;
the network terminal driver, responsive to the first request block and one certain of the application modules according to the data type used by the certain application program, generates a second request block;
the network terminal driver, responsive to the second request block and to one certain of the provider modules according to the certain communications medium by which the certain terminal is connected, generates at least one third request block;
the network terminal driver, responsive to the second request block and one certain of the device profiles according to the type of the certain terminal, generates one or more fourth request blocks; and the third and fourth request blocks are input to a lower layer service provider which is responsive to the third and fourth control blocks to perform communication over the certain communication medium to the certain terminal, whereby the lower layer service provider performs the communication between the CPU and the certain terminal according to the data type used by the certain program, the protocol employed by the certain communications medium, and the characteristics of the certain terminal.
a certain application program encountering an instruction directing it to communicate with a certain terminal generates and forwards to the network terminal driver a first request block;
the network terminal driver, responsive to the first request block and one certain of the application modules according to the data type used by the certain application program, generates a second request block;
the network terminal driver, responsive to the second request block and to one certain of the provider modules according to the certain communications medium by which the certain terminal is connected, generates at least one third request block;
the network terminal driver, responsive to the second request block and one certain of the device profiles according to the type of the certain terminal, generates one or more fourth request blocks; and the third and fourth request blocks are input to a lower layer service provider which is responsive to the third and fourth control blocks to perform communication over the certain communication medium to the certain terminal, whereby the lower layer service provider performs the communication between the CPU and the certain terminal according to the data type used by the certain program, the protocol employed by the certain communications medium, and the characteristics of the certain terminal.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US07/196,597 US4951245A (en) | 1988-05-20 | 1988-05-20 | Network terminal driver communications subsystem |
| US196,597 | 1988-05-20 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA1325483C true CA1325483C (en) | 1993-12-21 |
Family
ID=22726042
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA000598149A Expired - Fee Related CA1325483C (en) | 1988-05-20 | 1989-04-28 | Network terminal driver communications subsystem |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US4951245A (en) |
| EP (1) | EP0342320B1 (en) |
| AU (1) | AU615271B2 (en) |
| CA (1) | CA1325483C (en) |
| DE (1) | DE68920628T2 (en) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0290330A (en) * | 1988-09-28 | 1990-03-29 | Hitachi Ltd | Program constitution system |
| JPH0743683B2 (en) * | 1989-02-13 | 1995-05-15 | 日本電気株式会社 | Protocol machine |
| EP0419064A3 (en) * | 1989-09-22 | 1992-08-05 | International Business Machines Corporation | Computer system having apparatus for providing pointing device independent support in an operating environment |
| US5053947A (en) * | 1989-09-29 | 1991-10-01 | Allegro Microsystems, Inc. | Extended multistation bus system and method |
| US5708810A (en) * | 1989-10-10 | 1998-01-13 | Unisys Corporation | Image-based document processing system having a platform architecture |
| US5179666A (en) * | 1990-06-07 | 1993-01-12 | Unisys Corporation | Block oriented peripheral device interface |
| US5278955A (en) * | 1990-06-18 | 1994-01-11 | International Business Machines Corporation | Open systems mail handling capability in a multi-user environment |
| US5097528A (en) * | 1991-02-25 | 1992-03-17 | International Business Machines Corporation | System for integrating telephony data with data processing systems |
| FR2679351B1 (en) * | 1991-07-15 | 1995-01-27 | Bull Sa | OPERATING SYSTEM FOR A UNIVERSAL DEVICE FOR COUPLING A COMPUTER BUS TO A SPECIFIC LINK OF A NETWORK. |
| US5483647A (en) * | 1992-12-17 | 1996-01-09 | Bull Hn Information Systems Inc. | System for switching between two different operating systems by invoking the server to determine physical conditions to initiate a physical connection transparent to the user |
| US5673418A (en) * | 1994-10-07 | 1997-09-30 | Bull Hn Information Systems Inc. | Method and apparatus for emulating the operations of an emulated system terminal driver on a host system |
| US20030208637A1 (en) * | 2002-05-03 | 2003-11-06 | Intel Corporation | Application layer interface |
| WO2007114911A2 (en) * | 2006-04-04 | 2007-10-11 | Symbol Technologies, Inc. | Driver interface for data capture systems |
| US8028915B2 (en) * | 2006-04-04 | 2011-10-04 | Symbol Technologies, Inc. | Configuration migration for data capture systems |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3937925A (en) * | 1974-06-25 | 1976-02-10 | Ibm Corporation | Modular transaction terminal with microprocessor control |
| US4281315A (en) * | 1979-08-27 | 1981-07-28 | Bell Telephone Laboratories, Incorporated | Collection of messages from data terminals using different protocols and formats |
| SE448919B (en) * | 1983-03-04 | 1987-03-23 | Ibm Svenska Ab | METHOD FOR TRANSFERING INFORMATION DEVICES IN A COMPUTER NETWORK, AND COMPUTER NETWORK FOR IMPLEMENTATION OF THE METHOD |
| US4756007A (en) * | 1984-03-08 | 1988-07-05 | Codex Corporation | Adaptive communication rate modem |
| US4701841A (en) * | 1984-07-25 | 1987-10-20 | Digital Equipment Corporation | System for altering data transmission modes |
| JPS61133454A (en) * | 1984-12-03 | 1986-06-20 | Hitachi Ltd | Terminal control system |
| US4787028A (en) * | 1985-09-03 | 1988-11-22 | Ncr Corporation | Multicommunication protocol controller |
| US4977499A (en) * | 1988-04-08 | 1990-12-11 | International Business Machines Corp. | Method and apparatus for commanding operations on a computer network |
-
1988
- 1988-05-20 US US07/196,597 patent/US4951245A/en not_active Expired - Fee Related
-
1989
- 1989-03-02 DE DE68920628T patent/DE68920628T2/en not_active Expired - Fee Related
- 1989-03-02 EP EP89103644A patent/EP0342320B1/en not_active Expired - Lifetime
- 1989-03-22 AU AU31603/89A patent/AU615271B2/en not_active Ceased
- 1989-04-28 CA CA000598149A patent/CA1325483C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US4951245A (en) | 1990-08-21 |
| EP0342320A3 (en) | 1992-05-20 |
| AU615271B2 (en) | 1991-09-26 |
| DE68920628D1 (en) | 1995-03-02 |
| DE68920628T2 (en) | 1995-09-21 |
| EP0342320B1 (en) | 1995-01-18 |
| EP0342320A2 (en) | 1989-11-23 |
| AU3160389A (en) | 1989-11-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA1325483C (en) | Network terminal driver communications subsystem | |
| US5349675A (en) | System for directly displaying remote screen information and providing simulated keyboard input by exchanging high level commands | |
| US5483647A (en) | System for switching between two different operating systems by invoking the server to determine physical conditions to initiate a physical connection transparent to the user | |
| US5721880A (en) | Small computer system emulator for non-local SCSI devices | |
| US5485570A (en) | Display station controller | |
| US6530078B1 (en) | Virtual machines in OS/390 for execution of any guest system | |
| US4787026A (en) | Method to manage coprocessor in a virtual memory virtual machine data processing system | |
| US6370606B1 (en) | System and method for simulating hardware interrupts in a multiprocessor computer system | |
| JP3270102B2 (en) | Licensing method and system | |
| US5590288A (en) | Distributed data processing system and method utilizing peripheral device polling and layered communication software | |
| EP0366581A2 (en) | Method to provide concurrent execution of distributed application programs by a host computer and an intelligent work station on an sna network | |
| JPH0772884B2 (en) | Computer system | |
| JPS63275243A (en) | Communication controller | |
| EP0477124B1 (en) | Method and apparatus for distributed processing of display panel information | |
| JPH09512358A (en) | Interface device and method | |
| US6938257B1 (en) | Apparatus and method to provide persistence for application interfaces | |
| US6226659B1 (en) | Method and apparatus for processing reports | |
| US5396629A (en) | System architecture, and use of this architecture in a method for replacing boards | |
| US7010609B1 (en) | System and method for adding transport protocols in distributed middleware applications | |
| US5051926A (en) | System wide local copy management of screen copy printing | |
| CN112084128A (en) | Message interrupt communication method, computer device, and storage medium | |
| JPH06348512A (en) | Resource-control computer system | |
| KR100482316B1 (en) | Console server method on operating system and apparatus thereof | |
| Chess | A tight coupling of workstations | |
| JPH04370870A (en) | Multi-host log-on control system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MKLA | Lapsed |