Facsimile and static presentation processing – Static presentation processing – Communication
Reexamination Certificate
1997-11-25
2004-03-09
Moore, David (Department: 2624)
Facsimile and static presentation processing
Static presentation processing
Communication
C709S227000, C709S228000, C709S230000
Reexamination Certificate
active
06704117
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field of the Invention
This invention pertains to virtual device selection in a client/server environment. More specifically, the invention pertains to client/server negotiation of virtual display, printer and/or terminal device selection to control session attributes, job routing to customized subsystems, user access control, and so forth.
2. Background Art
The growth of the Internet has resulted in a corresponding rise in need for TCP/IP applications and support tools.
In accordance with Telnet Protocol Specification (RFC 854), a fairly general, bi-directional, eight-bit byte oriented communications facility is described. Its primary goal is to allow a standard method of interfacing terminal devices and terminal oriented processes to each other.
In accordance with Telnet Option Specification (RFCs 854 and 855), a method of option code assignment and standards for documentation of options are described.
In accordance with 5250 Telnet Interface (RFC 1205), the interface to the IBM 5250 Telnet implementation is described. To enable 5250 mode, both client and server agree to support the Binary, End-Of-Record (EOR), and Terminal-Type Telnet options described in RFCs 856, 885, and 884, respectively. A partial list of 5250 terminal types is maintained in Assigned Numbers RFC 1700. More terminal types are also found in the OS/400 TCP/IP Configuration and Reference (IBM publication SC41-5420) chapter on Telnet Server, under “Workstation Type Negotiations and Mappings”.
In accordance with RFC 1572, there is provided a method for negotiating options allowing hosts to provide additional services over and above those available within a Network Virtual Terminal (NVT) and which allows users with sophisticated terminals to receive elegant, rather than minimal, services.
There is a need in the art to provide a method for inviting any Telnet Client (including 5250, 3270, Vtxxx based) to negotiate Telnet device name and secondary NLS language selection in a TCP/IP or the like environment. Such a pure TCP/IP solution is needed to eliminate the need for other protocol software to be purchased and installed while allowing full terminal device support for all kinds of new clients.
Currently, IBM AS/400 Telnet sessions use a virtual device naming convention of QPADEVnnnn, where “nnnn” typically varies each time the user starts a Telnet session, depending on what device is free or available. Under Telnet (TCP/IP), customers cannot choose or select a particular device name for their Telnet sessions. Consequently, customers are not able to start specific jobs based upon the device name, restrict application access based on device name (for example, based upon the location of the device), or select terminal and keyboard language information of this device (because virtual devices have National Language Support attributes already associated with them.) This lack of virtual device selectability limits client function and flexibility of client applications, and increases service costs associated with the AS/400.
By comparison, the IBM System Network Architecture (SNA) sessions can be named by customers, but TCP/IP sessions currently cannot be named by customers since no standard or solution for Telnet exists. Whereas in Telnet the device name (as distinguished, of course, from device type) is selected from a general pool of names by the operating system at the server, the SNA processes for connecting with bind allows for the passing of data which may include a device name. This difference in work management functionality renders impractical migration from an SNA to a TCP/IP environment of legacy applications and veteran Client Access users having available to them several important functions over SNA connections find they are not available to them if they choose native TCP/IP support. The principle deficiency is the inability to define 5250 printer emulation sessions. Moreover, even in the SNA architecture, if a client requests a session or device name, and the server does not accept or grant the requested name, the client/server connection is broken, there being no provision for retrying. Therefore, there is a need in the art for a way to migrate from an SNA to a TCP/IP environment without losing work management functionality.
More specifically, with respect to printing functions, while TCP/IP is a very simple and standard protocol accepted by the industry, which removes proprietary hardware and software requirements in communications, resulting in “open” systems architecture, many intranet and Internet software applications have a need for more and better print support over TCP/IP.
In particular, customers need a mechanism to support printing while using Telnet. Often, files for printing are created during a Telnet session on a remote system, but need to be printed on a local printer. With the development of the Dynamic Host Configuration Protocol (DHCP), TCP/IP Telnet clients have become more mobile in the sense that there is no fixed configuration associated with these clients. A good example would be the new Network Computer (NC) developed for the Internet. This NC is essentially a “thin client”, one whose configuration is dependent upon the network in which it exists. For such clients, there is the need to define a local printer and a method for printing to it.
The capability to print remote files on a local printer over a TCP/IP network either does not exist, or is defined by the LPR/LPD protocol set forth in RFC 1179. This protocol is too limited in function to support most new printers with sophisticated features. In addition, the LPR/LPD protocol requires knowledge of network topology and that additional steps be taken to initiate the print functions for each file. For DHCP clients, printing becomes a repetitive task to initiate and presents a configuration problem with LPR/LPD. Furthermore, as no new RFC for printer support over TCP/IP appears on the horizon from the Internet Engineering Task Force (IETF), a new RFC would take years to become an industry accepted standard for printing.
Current alternative print solutions such as Client Access/400 require that additional network transport protocols, like the IBM System Network Architecture (SNA), be loaded or supported in addition to TCP/IP. This can result in complexity, additional expense and lack of open architecture for customers. Client Access/400 supports remote-to-local print functions, but only by using special printer pass thru services over the SNA protocol. By comparison, the SNA protocol is much larger and more complex than the TCP/IP protocol, and therefore requires much more support to configure and maintain. There is a need in the art for a print solution facilitating migration away from SNA and dependent terminals to the more flexible TCP/IP used to run intranets without almost total loss of the rich print functionality of SNA.
Consequently, it is an object of the invention to provide a system and method whereby user customers may choose or select a particular virtual device name for their Telnet sessions.
It is a further object of the invention to provide a system and method for allowing full terminal device support for all kinds of new clients. It is a further object of the invention to provide such full terminal device support without impacting legacy clients, those not configured to take advantage of the new functions provided by the system and method of the invention.
It is a further object of the invention to provide an improved system and method for defining a local printer and for printing to it.
It is a further object of the invention to facilitate migration from SNA to TCP/IP without loss of print functionality.
It is a further object of the invention to provide an improved system and method for selecting or creating and naming virtual devices, including setting client keyboard, code page and character set at display device creation time, and printer manufacturer, type and model, printer font, and forms type at printer device creation time.
SUMMARY OF THE INVENTION
System and me
Chintakrindi Rao Sivasankar
Murphy, Jr. Thomas Edwin
Rieth Paul Francis
Stevens Jeffrey Scott
Beckstrand Shelley M
International Business Machines - Corporation
Moore David
Poon King Y.
LandOfFree
System and method for server virtual printer device name... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for server virtual printer device name..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for server virtual printer device name... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3226664