|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
WHITE PAPER |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
TECHNOLOGY AND APPLICATIONS |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Printing in IBM host environments |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
TABLE OF CONTENTS
Introduction IntroductionDuring the last decades, tremendous investments have been made in SNA applications (IBM host system resident applications designed to communicate over SNA networks) running on IBM Mainframe and Midrange host systems. This is where the majority of the world’s data resides and large enterprises in areas such as banking, education, government, industrial, retail and transport are depending on these applications for their day-to-day business. Although quite a few new applications are being developed on Windows and UNIX platforms, the IBM host systems still remain the main servers for many of these companies. The main vehicle for communicating with these IBM servers has been using separate SNA (Systems Network Architecture) networks. With the incredible growth of TCP/IP based intranets and the success of the Internet, companies often end up with two parallel networks and network administrators being faced with increasing demands to consolidate corporate networks down to one single (TCP/IP network) to cut costs. A lot has been said about technologies used to make SNA applications communicate over TCP/IP based networks often focusing on methods to connect a browser or TN3270/TN5250 emulator to the hosts or shipping entire SNA packets over IP networks. This paper provides a technical overview of the most common methods used for enterprise SNA applications printing over TCP/IP network. BackgroundSNA and TCP/IP stem from different backgrounds with different requirements. SNA has been developed, fine tuned and proven in mission critical business networks with tough demands on uptime, security, availability, response times, reliability and control. TCP/IP was originally designed to provide flexible, open, any-to-any communication services for universities. SNA and TCP/IP are based on different communication foundations. SNA applications are built assuming that a SNA network is available. Regular off-the-shelf IP routers are not able to route SNA the way IBM mainframes and FEPs (Front End Processors) are. Various SNA over IP encapsulation methods have been proposed. They are available but come with additional costs. Regular LAN attached printers used in Windows/UNIX environments do not speak SNA. SNA and TCP/IP use different printer command languages. SCS (SNA Character Stream) and IPDS (Intelligent Printer Data Stream) emulations are not available in standard PC printers. SNA and TCP/IP use different character sets for encoding text data. The native mode of encoding text data on IBM host systems is EBCDIC (Extended Binary Coded Decimal Interchange Code). Regular desktop printers use ASCII (American Standard Code for Information Interchange). Requirements & ChallengesIn general the requirements boils down to being able to deliver SNA applications print data over IP networks to local and remote printers. The demands on speed, reliability, efficiency and control naturally vary depending on the nature of the print data. A company with an occasional need to print out email hard copies cannot be compared with a bank or insurance company printing large volumes of checks and/or invoices. A number of different technologies have surfaced through the years fulfilling the demands above to different levels. From methods simply forwarding entire SNA packets encapsulated in TCP/IP down to schemes that terminate the SNA session on the host system, convert the data to ASCII and use standard TCP/IP print methods. All with their own advantages and drawbacks. Although a lot of efforts have been spent and are continuously being spent on improvements, there is still no method available that will fully match all aspects of SNA. Keep in mind that SNA enjoys the advantage of having been fine tuned for the last three decades in this environment. However, a set of more sophisticated, cost-effective and very promising methods such as TN3270E and TN5250E have been introduced. Both built on native TCP/IP but with SNA applications display and printer data flows in mind, bringing them close enough to real end-to-end SNA functionality for most users. Available print methodsLooking at the solutions available today we are able to identify a number of alternatives at different networking layer levels. First of all a couple of methods that carry SNA packets complete with THs (Transmission Headers) and RHs (Request Headers) more or less untouched over the WAN (Wide Area Network) deserve to be mentioned:
These methods require a full SNA stack at the client. They have been discussed in numerous articles and books and will not be covered in this article. Instead we will focus on native TCP/IP print methods used with SNA applications printing. The most popular ones in use today may be summarized as :
LPR/LPD (Line Printer Requester/Line Printer Daemon)LPR/LPD is a TCP/IP based print method that stems from the UNIX world. The official specification used today is RFC 1179. Print data, which is normally ASCII encoded, is sent from the LPR to the LPD print server. In the IBM host system arena this method often relies on host resident software translating the SCS/IPDS EBCDIC encoded print data to ASCII. Once the conversion is done, standard LPR/LPD is used to carry the data to the LPD/printer. The good part with LPR/LPD is that it is a widely used and available technology that may be applied over any IP network. However, when used with SNA applications printing the list of drawbacks is quite extensive. It lacks print job acknowledgment. Once the print data is transmitted to the LPD, the host will consider the job done. This fact does not necessarily mean that the job is actually printed. Another disadvantage of this method is the aging and not very detailed or concise specification leaving the door open for incompatible implementations of the protocol. Some implementations will not allow the user to select page ranges or multiple copies of a document to be printed. Other implementations may require PCL emulation in the target ASCII printer. Still, LPR/LPD is a popular method for printing in UNIX as well as IBM environments. It is available on all major platforms and although there are a number of drawbacks in the IBM environment it is an inexpensive and widely available method. It may very well be an appropriate choice for the occasional user.
A couple of vendors do offer EBCDIC to ASCII conversion software and/or LPR implementations for the mainframe environment. One example of an available product is: Network Print Facility (IBM). Looking at the AS/400 world, the HPT (Host Print Transform) EBCDIC to ASCII conversion utility and LPR/LPD are standard features of current OS/400 levels.
Reverse TelnetReverse Telnet is another protocol with roots in the UNIX world. It is a straightforward method that is based on simply transferring data safely to/from TCP ports that is now being used for printing purposes. This approach, sometimes called “raw TCP/IP” or “direct sockets printing”, eliminates some of the shortcomings of LPR/LPD. This is achieved by the driver implementation in the IBM host system taking advantage of the bi-directional status reporting capabilities of PJL/PCL printers.
This TCP based method was introduced in the AS/400 world with OS/400 V3R7. It is available in the mainframe environment as well. One example of a product is the VPS (VTAM Print Support) system.
PPR/PPD (Page Printer Requester/Page Printer Daemon)Starting with PSF/MVS V2R2 and OS/400 V3R1, IBM introduced a new TCP/IP based print method designed for IPDS (Intelligent Printer Data Stream) printing called PPR/PPD (Page Printer Requester/Page Printer Daemon). Although a limited set of commands and replies is specified, this method features built in bi-directional capabilities. Combined with the strong status reporting mechanisms of IPDS, good run-time control and monitoring of print jobs is provided. Enjoying extensive support from IBM in both host system drivers as well as the actual printers/print servers, this method has become a de facto industry standard for IPDS over native TCP/IP. It is available on all IBM strategic platforms including MVS and OS/400 and also optionally available for later IBM network printers’ models as well as from third party printer and print server vendors. Being based on native TCP/IP, supported by existing printers/print servers, delivering SNA-like control of print jobs and not requiring host resources for translating print data to ASCII, this method has given IBMs page printer language IPDS a renaissance in the last years. The major drawback of this method is the fact that it is proprietary. The specifications are not
publicly available leaving the door open for incompatible implementations. Another disadvantage is the fact that it is used with IPDS only, leaving a large number of existing SNA applications out in the cold.
TN3270ETN3270 is a TCP/IP Telnet based protocol used to carry SNA RU (Request Unit) data untouched between IBM host systems and TN3270 clients over IP networks. While the original specs from the mid 80s targeted display traffic, the TN3270E standard (RFC 1647 in 1994) featured a number of improvements including support for printing. The TN3270E data stream is created by a TN3270E server that basically replaces the SNA THs (Transmission Headers) and RHs (Request Headers) with TN3270E headers and ships the RU (Request Unit) data using TCP. The server may be implemented as a software package running on the mainframe itself, a router or other server hardware. Numerous product offerings are Windows or UNIX based. The result is a highly efficient block oriented protocol built with SNA applications display and printer data flows in mind that comes close enough to real end-to-end SNA functionality for most users. It is bi-directional by nature and does provide the possibility of transmitting positive and negative numbered packet acknowledgments making SNA-like control and management of print jobs possible. Both IPDS and non-IPDS printing is supported.
A wide range of TN3270E solutions are available. TN3270(E) is a popular technology today and is expected to continue growing.
TN5250EWith the introduction of OS/400 V4R2 in early 1998, IBM introduced a number of enhancements to the OS/400 Telnet implementation. This TN5250 extension supports a number of new features including SNA like SCS (SNA Character Stream) printing over native TCP/IP. Two new “terminal types” may be negotiated for printing purposes:
The 5553 type makes it possible to print Japanese, Korean, Traditional and Simplified Chinese character set based reports. TN5250E shares all the major advantages with TN3270E and additionally offers automatic configuration of printer devices. Although the basics specs look really promising a few limitations of the current implementation can be identified. One being the limited set of printer types that may negotiated. As no matrix printers are in the list of supported devices, users may run into problems with reports specifically designed for such printers. Another drawback is that IPDS printing is only possible by using HPT (Host Print Transform) on the host system converting IPDS print data to ASCII.
An indication of IBM’s commitment to TN5250E is the fact that upgrades/PTFs for OS/400 V3R2 will be made available enabling this technology to a majority of the existing AS/400 installations. Also the specifications originally driven by IBM (Murphy, Rieth, Stevens) have been submitted to IETF. Another sign of the interest in this method is the attention paid by several client vendors. A number of TN5250E clients for display and/or printing include Axis (External print servers) and IBM Client Access (PC SW).
The Axis solutionAxis host-to-LAN series print servers provide a flexible and cost-effective way for LAN printing from your AS/400, mainframe and workstations/servers. In addition to all the functionality of Axis regular print servers, enterprise-class support for IBM host system printing over TCP/IP and SNA protocols is offered. With a choice of SNA through TCP/IP including TN3270E and TN5250E, SCS as well as IPDS data streams, Axis Host-to-LAN series sets new standards. These products enable point-to point high-speed printing over the network without the need for application changes, host-based conversion software, or intermediate servers on the remote LAN. Running SNA in the mainframe environment, the Axis print servers emulate a LAN attached IBM 3174 Control Unit (PU 2, LU1/3) with subsequent SCS and IPDS coax printers. Looking at the AS/400 SNA world, IBM 5494 Control Unit emulation (T2.1, LU6.2) is available. These modes make up an excellent match running SNA over local networks or to remote offices using Frame Relay and/or DLSw technologies. If and when you are ready to go for SCS and/or IPDS printing using the newer PPR/PPD, TN3270E or TN5250E protocols, the Axis host-to-LAN series has got it all. Featuring an inbuilt HTTP server and a powerful installation wizard for IBM sessions, the print servers are easily set up and managed using a regular browser. By simply entering the IP address of the print server in your browsers URL field you are in control of any Axis print server in your network. Axis also offers a unique feature that allows the user to take advantage of digital copier finishing options. Without modifying applications or drivers on the IBM host system, features such as stapling, hole punch and copying may be activated. This option may be used by any system/protocol on the network e.g. IBM, UNIX, DOS etc. The print servers are available in different models to allow connection of printers with serial ports, parallel ports and USB ports. Axis Host-to-LAN series print server product selection guide
Network environments and protocols supported by Axis print servers: IBM Mainframe:
IBM AS/400:
SummaryThis white paper has discussed a number of available print methods with their own pros and cons. To determine what the right method is in every situation is out of the scope of this paper, but once it is decided what method to use, vendors like Axis deliver products with proven capabilities to fulfill your printing need and provide an efficient and reliable way to handle printing complexity in different environments. About Axis
Axis increases the value of network solutions. The company is an innovative market leader in network video and print servers. Axis' products and solutions are focused on applications such as security surveillance, remote monitoring and document management. The products are based on in-house developed chip technology, which is also sold to third parties. Information about Axis can be found at: www.axis.com |