Print Management

EDBOK Guide

What is Print Management?

There are many definitions of Print Management. It is most simply defined as the management of the process used to deliver output to a marking device. Why do we need print management at all? If the printer is directly tied to the application that produces the output, only one job at a time can be processed and printed.

Since emerging as a discipline in the late 1950s, Print Management has evolved and grown in sophistication from lists on white boards to a series of clicks in an application to schedule a task. To understand the role of Print Management today it helps to understand where it began.

The Start

Initial Print Management implementations were a multi-stage affair. A limited operating system on the printers, whose sole purpose was to accept one job at a time, required an independent two-stage management process usually starting with a print file sent to an external tape drive. Print jobs were collected sequentially before the tape reel was removed and then loaded to a tape drive directly connected to the printer. Jobs printed one line at a time with no variability; whatever was on the tape, correct or not, printed.

Evolution to a Single Manager for Multiple Printers

A computer Operating System capable of handling multiple tasks and subtasks arrived in the late 1960s. A Print Manager followed on the heels of this capability, the most notable being the IBM Houston Automatic Spooling Priority (HASP), developed in conjunction with the National Aeronautics and Space Administration (NASA – Houston). It was the forerunner of the Job Entry Subsystem (JES) available on mainframes to this day. The spooling system took advantage of partitioning to operate multiple activities within a single partition, simultaneously receiving files for print, managing print selection, and printing to a device, each in a separate sub-task. The spooling tasks could include other input/output options such as card reader input and card punch output.

With an intermediate disk drive repository for the print data, use of job queues became possible. Now the job print sequence could be based on algorithms, such as priority queues and priority jobs within the queues, as well as operator selection and reorganization. Rudimentary commands allowed print job restart at a selected point, back up line spacing, and other commands. Programmable exits made job accounting possible as well as inspection of job control information.

Print start and stop, execution time information and line print counting for impact printers provided the start to user billing to accurately pass charges for print back to the requesting organization. As print batching capabilities expanded, identification of user jobs led to the addition of cover and trailer pages with at least job name, file name and time stamping. Exits permitted additional information to be appended to identify user names, departments and other information beyond simply the job name.

Now the print process could be dynamically customized. Job parameters, some relating print queues and priorities, could be modified. Exits also provided basic data manipulation as each line of data was intercepted for inspection and potential modification.

Despite these enhancements to the print management function, print was “as is”; whatever was received was printed. Job name, sender and content limited the information available to the operator. Whether the printer was operational or not could only be determined by the number of print lines remaining or more likely walking over to the printer to determine its state. Some larger print facilities added a not ready light to ease the surveillance.

When printers were remotely connected by telephone lines, a remote operator console for the purposes of starting, stopping and selecting print also appeared. The remote operator console initially used a typewriter-like device on a low-speed phone line.

As the technology improved remote operators could view and manipulate jobs at the mainframe queue.

With the introduction of page printers in the 1970s, print services took on a larger role. Initially the printers appeared as impact line devices to spoolers; they accepted the lines of print set up to identify fonts, line skipping, and spacing at the printer. Some printers stored the fonts and formatting instructions within the printer activated by instructions in the print file. These printers also downloaded the print jobs before starting their printing. Others required an enhancement to the print management software to download the various resources based on instructions to the printer before each print job.

Alongside the emergence of multiple font capability came strategies to handle the font changes. Initially limited to four fonts, a character position was added to the line of data to signify which font was to be used. The column for the “carriage control” was also liable to move away from the first position of the print line. The Xerox line conditioned data stream (LCDS) to printers was one of the first such implementations in the 1970s.

At this point the character mode of operation gave way to encompass the electro- photographic technology in the printers; resolution enabled text of varying sizes and qualities, graphics and positioning beyond line spacing. Xerox Metacode and IBM Advanced Function Printer Data Stream (AFPDS) became the most common production print data streams to support this capability. This challenged spooling systems due to a larger use of memory and disk to accommodate the files, plus a new way of measuring these files, by the page (actually by the impression as in one side of the page).

Restarting a job now had to take into account each page boundary.

Networked High-speed Printers

Printer spooling initially meant routing output to devices connected to the host, either in-house or at remote sites, with the digital printers controlled by the central process. Hindered by the costs of telecommunications and printers themselves, networks were limited in scope. The operators still understood the jobs as “lines of data” to be managed.

As the costs came down for printers and telecommunications, larger networks were developed. The insurance industry took a lead in remote printing in the early to mid- 1980s, recognizing that the cost of the printers was in the $50K range for devices that reached 50 impressions per minute with running costs of multiple cents per impression. Many companies in the insurance industry incorporated a small print server at each location to manage the printer, receiving print files through the night on the cost effective low speed lines, with actual printing performed in the morning.

Where a server wasn’t included, the printers were point-to-point on dedicated lines. IP technology did not come into use until standardization in 1998.

Office Printers

With office printing requirements growing, once a printer was at the remote site it became worthwhile to share the device, delivering alternate data streams found in the office. PCL and PostScript, initially considered desktop device data streams, could now be distributed to any printer capable of receiving it. These printers could do double duty with connections to the central site and locally print jobs, as well. Initially, the print server needed instruction; a PCL and PostScript capability had to be defined for each printer, otherwise a data stream sent to an incapable printer just spewed out odd characters, often running through pages of stock with a single line on each.

The choice of papers required another level of management for the variety of paper types and post processing requirements. The print queues for cut sheet devices had to account for the number of input trays / bins along with the paper type to be used in each. To print efficiently, the spooler had to keep track of the type of paper placed in each bin, placing holds on jobs until the operator acknowledged the proper paper had been loaded. This process was not automated as no printers could identify what paper they held. Operations or systems programming had to set up print queues to minimize paper changes.

Managing Networks and Print Data Streams

The data stream also had to reflect new capabilities in printers and job spoolers. The IBM approach required a twofold upgrade. The first was a means of predefining the printer characteristics, ideally discovered from the printer. The second feature was a protocol that defined itself with a bi-directional communication between spooler and printer, interrogating the printer to determine capabilities before transmission and then verifying that the resources were in the printer or downloading them.

IBM’s Intelligent Printer Data Stream (IPDS) in the early 1980s was one of the answers for production class page printers. As market requirements changed to embrace multi- channel delivery, the data stream name evolved to the Intelligent Presentation Data Stream. This capability took AFPDS and added print device specific commands that allowed the spooler to react to the needs of the printer before continuing. This ranged from resource downloads to recovery through a restart, knowing what page was last produced. This required the spooler to constantly update its understanding of page completion, receiving messages of print success as the job progressed.

Adding Personal Computers to the console was the next development as the mainframe green screen offered only lines of data. The initial implementations were built around a single server to a single printer, delivered from a single high volume mainframe. As the printers came down in cost the Personal Computer also gained dramatic performance improvements and came into its own in the 1990s, though until Internet Protocol (IP) addressing they saw limited implementation. A display, now often called a dashboard, contained the job information and more valuable color-coded printer activity for quick status evaluation by the operator. As an information center, start and stop times could be tracked and delays identified.

Queues could be defined for single or multiple printers with one queue to many devices to spread work and provide printer redundancy. The queues could relate to individual printers or like groups of printers, defining the acceptable data streams, the ability to assign print priorities.

Input from multiple sources/hosts could deposit their jobs into queues, or hot folders, though a limited amount of information came with jobs to identify their provenance as metadata. A limited solution was to have one queue / hot folder per sender.

Network managers with disparate printer types distributed across geographies found that adding new devices, addressing, and functional characteristic definitions created a major operational headache. An effective improvement came with the IP addressing scheme, where the print server could search for printers across a range of addresses to find newly added devices and define a standard device metric. This dramatically reduced network maintenance where more than a thousand printers might be the norm for an enterprise or governmental organization.

Transforms from one printing protocol to another added flexibility where printers might not be able to handle all the data streams. This required a definition of the printer capability against the understood source queue to be automated. For example, when a PostScript file arrived on a PostScript queue but only a PCL printer was available, the transform could be configured to start automatically as the job moved to the print queue. At a later point, automated data sniffing identified the original data stream, but there was no available process to recognize the printer’s attributes.

Print servers tended to emphasize the functions expected in the particular environment. Print servers on UNIX, Linux would differ from OS2 or Windows-based functionality, with different file delivery commands, transforms, levels of manipulation and job acceptance. Requirements for job checkpoint and restart, job recovery or job reprint functions tended to vary, with financial institutions requiring the most elaborate functionality.

Bi-Directional Network Protocols

The next step in the evolution was the development of bi-directional printer protocols to establish a conversation between the server and the print device.

SNMP (Simple Network Management Protocol), a network protocol used to monitor and manage network devices, was developed in the early 90s. Printers, being network devices, had various MIB’s (description of information about a device) which covered information from the printer’s state, media loaded, and status of submitted print jobs. With this information, print management tools determine which printers are available and have the resources required to print a job. SNMP is widely used in distributed office environments where being able to remotely monitor printers is beneficial. Most production equipment is also SNMP-enabled; however other more optimized methods are typically used.

Internet Printer Protocol

An Internet Printer Protocol (IPP) was introduced for discussion in 1999 with the standards evolving through 2005. This new capability offered the ability of the network manager to interrogate the printer capability and potentially restructure the job!

Consider today’s laptop needs; a user in a hotel wants to send a file from the hotel room and is provided with the address of the printer. The objective is to print without initially knowing the exact printer capabilities. Using the IPP, the PC first determines if the print job can be sent “as is”. If not, what alterations must be made? A particular impediment (and annoyance) is the shortage of memory when transmitting large images. One would prefer to know this before transmission. IPP, similar to IPDS, provides a method to do equipment discovery, transport the print file, provide printing instructions, and monitor print jobs status.

Job Definition Format and Job Messaging Format

In a different paradigm, JDF (Job Definition Format) and JMF (Job Messaging Format)

provide similar capabilities, but are generally used to describe how a print job needs to be manufactured. It lets the destination decide the details of how it is done. JDF provides information that includes how the document is initially composed, attributes of how it should be printed, as well as how it needs to be finished, packaged, and shipped providing a start to finish description.

JMF provides the transport for the print document, device information for print management tools, and sends details to Print Management Information Systems (MIS) often used for billing and tracking. These characteristics are not seen in other protocols. JDF/JMF is used with PDF print files, which are the industry standard in graphic arts printing and less common (but growing) in transactional print. With the run lengths of transactional documents coming down in some industries, the use of JDF and PDF are becoming more viable, particularly as some traditional transactional documents are being repurposed as short run transpromotional pieces with graphic arts requirements.

Managing Print

Print Reduction Options

Through a combination of workstation and print server software, a new class of print management software debuted. It puts a barrier between the user and print using features that require authorization to print, or deny access to print services. Each access type is determined by rules that have been defined for individuals or classes of users, as well as the type of print job.

These solutions were introduced as color printers entered the network, the immediate saving came from prohibiting the use of color when it might cost ten times the cost of printing on monochrome devices. Today with ink-based solutions, the distinction is not as great. The use of queues to manage print begin to control print to more expensive devices has evolved to queue-based management for a variety of business purposes beyond simple print reduction.

Print Server as a Business Model

Technology improvements evolved and offered the option to change how the print server is viewed in the context of the business operation. With improved storage and faster processors, and the addition of Internet access, intelligent job submission emerged.

Consider the situation where organizations not only want to print current files, but also print quality brochures or forms on demand. These brochures and forms can be managed in a digital asset management or content management for the corporate client staff to access as needed (within their permission structure). Staff heading toward a business show now sign on to print management function to order the types and quantities of pamphlets that are printed on demand instead of picked form a warehouse.

Print management in this context encompasses Web-to-print tools. Now the same systems used to manage transaction documents also manage supporting marketing collateral. When integrated with inventory management the Print Management function becomes the focal point of activity.

Print Server Expands its Role for Commercial Printers

Figure 1 - An example of a front-end print service.

Many print server solutions have added front ends to become e-Commerce platforms. Not only as a client submission utility, but as a store front with composition, color management, job sizing and pricing, providing the functionality of a Print Suite. The client can track the job production throughout. At the back end, alternate output strategies and archiving options permit the Print Shop to have an expanded working relationship with their client.

Costing Principals

Defining the elements in a Print Process; consider yourself a printing business that must recognize all expenditures. Elements include:

• The print server itself: one-time costs for hardware & software; annual maintenance costs for the same. Include the floor space, power and cooling necessary or the monthly costs for the device if provided by another organization. May include the network construction and integration.
• Staffing percentage to manage and upgrade, assuming this is a proportion of a Full Time Equivalent (FTE) individual with the requisite skills, if part of your organization.
• Number of operators to perform the tasks. Operator training on the use of the Print Server, initially from the supplier. Refresher or training for new personnel required.

Costing for the print operation must cover:

• The printers, their initial costs, supplies, usage and maintenance,
• Print device supplies such as paper required to produce the output,
• Inserters, including maintenance (possibly parts that wear heavily such as knife edges etc) Usually requires a second set of operators with different training, and
• Postage for transactional print; possibly courier services for bulk shipments. This historically has represented 60 – 75% of the total operational expenditure.

The Evolution of Workflow: the ADF

In high-volume production print in the early to mid-1990s jobs were essentially printed as they arrived in the print queue. Then came the requirement to manage and then manipulate the data stream. Starting with print job receipt through insertion into an envelope, the entire process became the subject of detailed, automated management.

Coined in 1996 by Gartner, the Automated Document Factory (ADF) identified multiple stages in the flow of data from input through distribution. These stages were identified in what is now ADF Version 1.0 and 2.0 (2007). The Workflow represented multiple possible steps that could be incorporated for given jobs based on an initial setup.

The stages are:

• Receipt of data and transformation: This input phase covered not only the data, but commands or instructions on data manipulation. This required a form of instruction management that would later be used against the particular file. Identification of the suitable instruction set would most often be automated through the job name.
• Data transformation: Initially aimed at data stream conversion (for example, AFP to PDF) it might also include using a utility that could take line data using mono pitch fonts and reformat it into a document using typographic fonts. The key is that the composition process became integrated into and managed by the ADF flow, and reported back on success or failure before the next step.
• Content modification: Adding graphics (pie charts, line or bar charts) that might take information existing in the print file (for example, statement data) and build relationships, such as percentage of financial holdings representing net worth. The key facet was the ability to perform this graphic addition without returning to source information, though in general, preference would be given to the composition utility performing the action and storing the information before presenting to the ADF.
• Reformatting: This includes reformatting address information, relocating it on the page to meet requirements for address windows across applications, reducing the number of envelope types needed to perform the print center’s work. When businesses built print applications separately, it was not unusual to have 20 or more envelope types in use. Reduction to fewer sizes and window locations reduced costs and simplified insertion verification.
• White space management: Finding unused space on the page in which to insert messages in a predetermined priority sequence until the space is used. This represents an extension of the application without returning to the original preparation. The choice of messages varies by individual case, and is tracked as part of the output.

Managing Inserts

Before ADFs became common there was a sticker in use in many print rooms that said: Sorry, Damage by Mailing Equipment. ADF-managed print environments eliminate the problem.

The need to manage inserts added requirements for bar codes to encode the number of sheets expected in a document ensuring that the proper number of sheets were in each envelope. In some systems a sequential number on the first sheet in the envelope window for each statement is monitored by a scanner to ensure double stuffing (two statements placed in a single envelope therefore the sequential number has a skip) doesn’t occur.

At the inserters there are often supplementary stations that include preprinted notices, advertising, or return envelopes. As inserter manufacturers provided their own inserter bar code definitions, which may vary by device model, the ADF is tasked with the ability to provide a replacement bar code should a reprint with insertion by a different insertion device be planned.

Managing the insertion process requires tracking each statement in the print stream so that a reproduction can be produced if there is damage to one or more pages in the document. The Best of Breed approach is to throw out all pages of the damaged statement that may have been damaged by the inserter rather than simply reprint a single page and insert by hand. The objective is to remove a primary cause of error in producing mailed documents: human intervention. This is sometimes managed by File Based Insertion, a tracking process whereby each sheet is tracked through to the envelope.

Dashboards are the preferred method to provide operational and management surveillance of the process. High level elements of all the steps are generally indicated with drill down capability against a job a particular step or a device.

As the systems become more sophisticated, Service Level Agreements have become an essential part of operations. Incorporating a particular set of characteristics of a production job, SLAs include expected arrival and the required delivery. Notification is generally required when the job will be late at any of the operational stages, job in, through mail or courier out schedules.

Billing also comes into play. The ADF is expected to calculate mailing costs per document for direct payment to the Postal Service. As postage has been calculated at 70% of the total “printing” costs, including hardware, services and staffing, this is no insignificant amount. The ADF will also prepare the information of the number of envelopes produced for mailing and in some environments send the results to the post office with payment arranged.

From a management perspective, the statement preparation log can perform double duty. It can identify every statement that has been prepared for the mail, in many countries the accepted measure of the sender’s responsibility to delivery. For this reason the post to mail becomes a log of statement completion is documentation that should be maintained were it to be required for legal purposes.

Justifications for an ADF Workflow

• Service Level Agreement: better reporting toward on time delivery,
• Digital management: single level of control regardless of destination; digital delivery implementations should include simplified payment processes,
• Cost control: stronger relationship between work and its management,
• Compliance: increasing compliance requirements to respond to government legislation, including security, is leading to the implementation of effective piece tracking with return message management where possible,
• Post: Postal Service document production and savings, recognizing that each country offers different price rules and pricing scales; current workflows feature technology to provide document house holding, a means of combining multiple statements in a single envelope where permitted and acceptable to the recipients; sorting for the lowest cost mailings may also be permitted,
• Continuity: business continuity represent a means of switching from one server to another, including known job status in a time period deemed appropriate for the organization; as mentioned previously, this may be milliseconds for online systems; minutes to hours for print,
• Recovery: the recovery commitment will determine the architecture and resulting cost structure. Secondary servers can be “hot standby”, print server application startup, or alternate location management with the existing printers; the first two require common print spool storage accessible by each server; pricing is usually available for all secondary server running options, and
• Workflow Extension: extending the Workflow upward to include “document capture and conversion”, a scanning and storing process is part of the smaller general purpose workflows that are being implemented to encompass the entire realm of paper ingestion through print / archive.

Robustness; Security Considerations

We expect that any system to manage critical operational information be robust. Sending out statements must be recoverable as discussed in Disaster Recovery.

Equally, backup for print centers and the Document Factory servers must be provided. The design of these ADFs can include offloading to alternate sites, external printer management with secondary servers and additional functionality, supporting a Disaster Recovery strategy.

An interesting approach taken since the early 2000s is the implementation of an overload provision to in-house systems. Rather than buy additional printer for peaks, some jobs may be outsourced, ADF to ADF, for completion. This has limited applicability if unique paper requirements (i.e. logoed paper) are not stocked at the alternate location, though it has become easier with color digital printers able to work with white paper. This process still requires a substantial investment to develop the revised print application and the replacement electronic forms.

Security is essential therefore passwords and permissions must be an integral part of the process. Control levels to limit the breadth of action by an operator are required parts of any design. While deleting a print job might be appropriate, you would not want to allow an operator to deliberately or inadvertently delete an active printer definition from the spooler’s available devices. When it happens it requires immediate action by an individual who can reconstitute the lost printer AND its definitions.

Depending on how the print queues had been defined, this may require significant recovery activity. A comment on the need for security against malicious acts; print may be delivered to the spooler from external sources. It is essential that the organization is protected.

Hosting: In-house or External

Implementations have improved to provide two sets of options for print servers:

• In-house print servers, the process that has been available in various guises to date.
• Externally web-hosted servers with the same functionality, with the financial justification developed on removing the print application maintenance from the client’s already stretched support staff while operations are unchanged.

Where to Next?

Technology has brought changes to the world of print. Many ADFs act as a platform for output, repurposing documents for electronic distribution. This will only increase. To meet this evolving output usage will require new models:

• A “pull” model, requiring action on the part of the recipient. This is accomplished today with QR codes.
• A “push” model, sending out the electronic equivalent of Direct Marketing, requires distribution addressing. Today this is managed when Internet subscribers signup for a service.

However, while the last step of output tracks each mail piece or message sent, proof of delivery is another matter. In mailing, registration with the delivery organization serves this purpose, email or file transfers usually have a return request blocked by the recipient’s server, a procedure developed to avoid unscrupulous use of the Internet.

Nor does regular mail currently provide a reliable means of tracking delivery in all countries. The Postal Services endeavor to deliver to the identified recipients and may in the case of error return the mailing, usually for a fee. The list of recipients for whom mailings have been produced and given to the Postal Service is a demonstration of logging controls and may be a sufficient equivalent to unregistered mail delivery.

Further automation should also be expected. From reprint processes through Business

Continuity, output management will be simplified for operations staff.

Security, auditing, and compliance mentioned earlier will receive greater emphasis as organizations face an evolving business environment. These capabilities will be either standard or optionally packaged. Organizations most heavily monitored (the financial and health industries) will lead implementations, as they have in the past.

How will print integrate with “socially acceptable media”? As social media demands immediacy and greater relevance than a typical mailed statement, there will be a need to integrate new sources of information. While this would be the purview of a composition utility, the logical placement of this action will need to be close to the message distribution to make it timely.

References

Print Services Facility for z/OS Customization S544-5622 http://publib.boulder.ibm.com/infocenter/zos/v1r13/index.jsp

CA-View Output Archival and Viewing System Reference Guide (formerly Unicentre) http://www.ca.com/us/products/detail/CA-Spool.aspx

IBM eServer iSeries Printing VII: InfoPrint Server Implementation ibm.com/redbooks http://publib-b.boulder.ibm.com/Redbooks.nsf/redbooks/

Levi Ray and Shoup Inc, Spool products http://www.lrs.com/eom/PDF/V2R11Products.pdf

z/OS Infoprint Server Customization S544-5744 http://publib.boulder.ibm.com/ infocenter/zos/v1r13/index.jsp

IBM IP Printway Guide S544-5379 http://publib.boulder.ibm.com/infocenter/zos/v1r13/index.jsp

StreamServe Business Communications Platform

RSA WebCRD Integrated Workflow http://www.rocsoft.com/ Storefront at EFI www.efi.com

IBM z/OS JES2…. http://publib.boulder.ibm.com/infocenter/zos/v1r13/index.jsp

Solimar Enterprise Output Management http://content.solimarsystems.com/pdf/SPDE_Benefits.pdf

Pitney Bowes DF Works http://www.pb.com/software/Print-and-Mail-Production/Automated-Document-Factory/

Ricoh PrintProcessDirector http://www.infoprint.com/internet/ipww.nsf/ vwwebpublished/solos_automated-document-factory_en

What is JDF? http://www.cip4.org/overview/what_is_jdf.html