Can you get Unix print services on par with mainframe print management?
When it comes to printing, Unix just doesn't measure up to the mainframe. What can you do about it?
January 1999
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Can you get Unix print services on par with mainframe print management?When it comes to printing, Unix just doesn't measure up to the mainframe. What can you do about it?
|
January 1999
|
Mainframe print services are far superior to those for Unix. How does Unix print management differ? Chuck details print management in both worlds and describes a couple of mainframe-style print tools made for Unix. (2,600 words)
 Mail this article to a friend |
ver the course of a year, we've looked at many aspects of the
mainframe computing world and examined the corresponding
capabilities within Unix. In many cases, Unix has similar features,
and in a few it has actually improved on the mainframe model.
Regrettably, printing isn't one of these areas. In fact, of all
the areas we've examined so far, printing is by far the most
immature in the Unix realm.
This is most likely due to the differing roots of the two operating environments. Mainframes were built to run businesses, and businesses run on paper. Reports, invoices, receipts, statements -- the amount of paper generated by a typical mainframe data center is awesome. From its earliest days to the present, the mainframe world has had big, robust printers, capable of chewing through a box of greenbar in a matter of minutes. Surrounding those printers were all the features that make high-volume printing easy and efficient. Over a span of four decades, the mainframe printing model has evolved into a highly efficient, versatile tool.
Unix was born of the research world, where printing is more of a low-volume, high-quality issue. Researchers rarely need to generate a stack of bills, but they do enjoy printing mathematical equations and elegant graphs and charts. Unix printing has supported line printer devices, of course, but over the years much effort has been expended on typesetting tools. Starting with troff and later TEX, Unix developers supported all sorts of fancy typesetting equipment and later, laser printers. While the output was the best possible given the current technology, Unix printing was never designed to support high-volume, bulk print jobs.
Mainframe print management
Mainframe printers are special devices. When you associate a
printer with a job, you can specify all sorts of control information
for the printer, including job priority, output destination, forms,
and special handling instructions. As your program generates
output, it is spooled by the system and held in a queue for later
disposition.
You can better appreciate the importance of printing in the mainframe world when you learn where the word spool came from. It stands for System Peripheral Operation Off Line, and it was coined at a time when the system could generate output or print it, but not both at the same time. Programs would run and write their output to tape. After completion, the system would be taken offline, the tapes would be mounted, and the output would be printed from the data on the tape. If you had the money, you might even have a separate machine to drive your printers while your mainframe crunched away on your data.
While systems got faster and soon could drive printers running your jobs in parallel, the idea of spooling data for later printing never went away. Few print jobs are actually spooled to tape now; instead they're held in queues on disk until they're ready to be printed. Once queued, the output will wait for the right printer, with the right forms, at the right time, to become available. Operators can move the print job from printer to printer, adjusting attributes so that everything prints correctly. Most importantly, an operator can start the print job, stop it in midstream, and restart it later where it left off. You can even move the job to a different printer after it stops, finishing the work started by a different printer.
Once printed, the job doesn't disappear. Depending on system policy, the print spool file might be held for a period of time, until users are assured that the output is correct. If something went wrong -- an incorrect form or a misaligned page, perhaps -- the entire job can be reprinted. In a feat that seems miraculous by Unix standards, print jobs can be restarted at specific pages, and page ranges within a print job can be extracted and printed independently.
The print job also carries information telling operators where it is to be delivered for further processing. In the case of large billing operations, the output might be fed into envelope stuffing equipment, where it is burst, folded, combined with other inserts (invariably reeking of perfume), and stuffed into an envelope. The envelope is sealed, dropped in the mail, and delivered to your doorstep, ready to be opened and paid.
|
|
|
|
|
Forms management
One of the hallmarks of the mainframe print world is the wide
variety of forms that can be mounted for printing. When you specify
a print job, you also indicate the kind of paper on which it is to
be printed. As the jobs queue up, operators can see which jobs
require which forms, and will group jobs sharing the same forms on
the same printer for efficiency. Once a particular form is mounted,
all jobs using that form can be printed.
It isn't uncommon for a shop to have dozens or even hundreds of form types. Beyond plain white and greenbar paper, you might stock letter and ledger size sheets, multipart forms, and all sorts of specialty paper stocks. In my shop at the American Kennel Club, we have all sorts of certificate stocks with gold seals and special logos that can be mounted as the need arises, along with standard forms for dog registration, address labels, checks, and even magazine subscription renewals.
The important aspect of forms management isn't that the mainframe has so many, but that they're so easy to request and use. Requesting and using a special form is trivial in the mainframe world, and users take for granted that a variety of special forms are available.
Unix print management
Printing is much different in Unix. In its quest to treat all
devices as either block or character devices, Unix relegated
printers to nothing more than simple serial devices, able to receive
and process a stream of bytes sent to it. This model works fine if
all you want to do is print a stream of jobs with no extra bells or
whistles. If you want to add mainframe-style print management, however,
things quickly become exceedingly difficult.
Right off the bat, Unix spooling utilities are second-rate. Jobs can be queued, of course, and queues can be suspended and resumed. But jobs can't be stopped and restarted, and heaven forbid if you want to move a job between print queues. Saving and reprinting a job if something goes wrong is almost impossible, and deleting a job from the queue often hangs the whole printing subsystem.
Now, System V Unix does include support for forms and somewhat better queue management, but it's still of limited use. Even with these extra features, there is no support for page-level job management. Printing just a portion of a job is impossible, and even counting the number of pages in a job is a herculean task.
This last limitation is more serious than you might think. In my shop, for example, we moved a major application from the mainframe to Unix. This app generates several hundred dog award certificates each night, which are printed on special stock and mailed out. The operator has one simple question before he prints the job: How much certificate stock (and cover letters and envelopes) will he need to complete the job? On the mainframe this was easy because the system would tell him exactly how many pages were in the job.
Unix systems have no idea how many pages are in the job. The job itself consists of data records that are converted to a PostScript-like page description language that drives a high-speed laser printer. While the PDL generates beautiful certificates, much nicer than the mainframe, you can't possibly examine the resulting data stream and determine the page count. Our hack? Have the certificate application send an e-mail to the operator telling him how many certificates were generated. Not elegant, but it works.
Mainframe tools for Unix
One way to solve your Unix printing problems is to buy a third-party
print management tool designed for Unix. These tools bring
mainframe-style print queue management to the Unix arena.
There are a number of these tools available on the market, and several are bundled as part of larger systems management packages, including offerings from Platinum Technologies and Computer Associates. While none of these tools can match the versatility of mainframe printing, one of the better ones is EasySpooler.
EasySpooler installs on most Unix systems, as well as Windows NT, and provides a significant additional layer of control over the print services on all the machines on your network. You can use EasySpooler to define various kinds of print services, associate those services with local, remote, and networked printers, and manage jobs associated with those printers.
EasySpooler sports a fairly pedestrian character-based user interface. Although not as fancy as other tools, you can use the same interface to manage printers from a dial-up connection, X display, or an operator's console. With EasySpooler, you can perform most mainframe print functions, including forms management, job stop and restart, partial job printing, and job requeuing. You can also control which users can print to which printers, providing an additional level of access control to print services.
EasySpooler works over the network with any other system running either EasySpooler or conventional lpd print services. If another machine is running EasySpooler, and is appropriately configured, you can completely control print services on that machine from your local host. If only lpd services are available, you can still queue and manage jobs on that machine within the limitations of Unix-based print services.
EasySpooler even tries to count pages and manage resources associated with print jobs. Page counts for plain print jobs are generated by dividing the job length by the page size, and PostScript jobs with correct page delimiting comments are handled correctly. In general, EasySpooler does a good job of bringing a better level of functionality to Unix print services.
Of course, there are plenty of other print management tools available for Unix, but this is one area where you should insist on a full evaluation copy of any product before you buy it. Many of these tools are nothing more than thin shells atop conventional Unix print management, and offer little or no additional features. Don't buy any print management tool until you've test-driven it in your shop, with your systems, using your printers with your print jobs.
Separate printing systems
A different approach to better printing mirrors the approach used
when mainframes first started out: shift the printing burden to a
different system. In this solution, a separate dedicated server
accepts print jobs from any machine on your network, routing those
jobs to the desired printer as needed.
This may sound a lot like standard Unix remote printing, but the difference is that the print management system has an enhanced set of printing features that provide greater control over your printing environment. An example of this kind of solution is IBM's InfoPrint Manager product.
InfoPrint Manager runs on a standalone AIX server. It accepts print jobs from any machine on your network, making print services available as standard remote Unix print queues. These print jobs are then routed to one or more printers attached to the server, either directly or over your network. The InfoPrint Manager offers an expanded set of utilities for managing print jobs once they've arrived on the server, allowing operators to stop, start, requeue, and change jobs as needed.
Since your network systems interact with InfoPrint Manager as if it were a simple remote Unix printer, some sleight of hand is required to implement support for forms and other print options. By creating a large number of remote print queues on the InfoPrint Manager system and associating each queue with a specific printer set up in a certain way, your systems can route a job to the queue that matches the desired printer, form, or other job characteristic. Once queued, jobs will hold until an operator releases them, presumably after making sure the right form is mounted on the right printer.
This kind of solution is targeted at large shops or commercial printing operations. Using InfoPrint Manager, you can migrate the responsibility for print management out of your data center and into your print shop or mail room. Instead of having operators print jobs, collate output, and deliver it to the intended party, you simply send the jobs to the InfoPrint system, where the recipient can control when and how it is printed.
We use the InfoPrint system exactly this way at the American Kennel Club. Throughout the day, as dog event data is processed, award certificates are generated and sent to the appropriate print queue. Operators in the mail room monitor the queue, and when enough certificates have accumulated, they load the appropriate paper into a printer, direct the queue to the printer, and release the jobs in the queue. The certificates are printed, stuffed into envelopes, and mailed. Moving control of the final printing step to the mail room means data center staff doesn't have to deal with forms management, and the mail room staff can print jobs when they're ready to completely process them.
Looking ahead
Any shop, big or small, can benefit from better print services.
While it may not be possible to completely emulate mainframe-style
features in your Unix environment, even adding basic print job
management tools can make a big difference in your customers'
satisfaction. Printing problems waste everyone's time: users will
rerun jobs that print incorrectly, operators struggle with balky
printers, misaligned forms, and misrouted jobs, and tons of paper is
wasted by even the smallest mistake. Anything you can do to
eliminate these problems, get output created faster, and relieve the
burden on your staff will be welcomed.
Even though the promise of the paperless office will never come to
pass, it is becoming easier and easier to eliminate printing instead
of enhancing it. You may find a better solution to your print needs
by eliminating them entirely, moving to Web-based solutions,
electronic reporting, and dynamic query tools. Next month, we'll
look at the kind of printing that was never thought possible when
mainframes ruled the earth: immediate, customized, and paperless
output, delivered to your desktop or around the world.
|
|
Resources
About the author
Chuck Musciano started out as a compiler writer on a mainframe system before shifting to an R&D job in a Unix environment. He combined both environments when he helped build Harris Corporation's Corporate Unix Data Center, a mainframe-class computing environment running all-Unix systems. Along the way, he spent a lot of time tinkering on the Internet and authored the best-selling HTML: The Definitive Guide. He is now the chief information officer for the American Kennel Club in Raleigh, NC, actively engaged in moving the AKC from its existing mainframe systems to an all-Unix computing environment.
Reach Chuck at chuck.musciano@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright99.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-01-1999/swol-01-print.html
Last modified: