management: What to Do With AFP
From the 1980s, AFP has been the architecture to print documents and reports for IBM mainframes. A combination of standards, software and hardware, AFP includes features like graphics, letterheads, tables and more. But today LAN printers and online documents in formats like PDF have become the norm.
So is it time to let AFP go?
AFP in the 80s
In the 1980s, IBM released a giant of a printer called the 3800-3. A continuous form laser printer, the 3800-3 was a giant leap from previous IBM printers: it could print graphics. And not only graphics, but documents with many of the features we take for granted with our word processing software today. Features like fonts, text orientation, tables, and forms. But the 3800-3 couldn’t do this alone. It needed a suite of software, pre-defined resources, and data in the correct format. It needed Advanced Function Printing (AFP).
In its essence AFP looked like this:
AFP-compliant data would be sent to the JES SPOOL from a product like IBMs Document Composition Facility (DCF) or a user application. From here a product called Print Services Facility (PSF) would accept it, and perform processing to convert it to a printer-ready format. As part of this processing, PSF would combine the input data with other pre-defined resources such as:
- Page definitions – defining the page size and layout
- Form definitions
- Overlays – text and graphics to place over the top of data
PSF was also the printer driver, managing the AFP printer (such as the 3800-3) to print the document. Originally released for MVS, versions were later released for VM, DOS/VSE, AS/400s, AIX and PCs.
The 3800-3 wasn’t the first printer that could print documents: Xerox was already there with their 9700 print subsystems. However AFP became the most popular. IBM produced other AFP-capable printers such as the 3820, and other printer vendors (including Xerox) soon followed.
AFP still works today. The software and standards still exist, and printer manufacturers continue to market AFP-capable printers. In fact any mainframe-based document creation today will probably use AFP.
However printing and documents have come a long way since the 1980s. The days of centralized printing have long gone, and now organisations print to smaller remote printers. To reduce expenses, many are now minimising hard-copy printing, preferring electronic archiving and online formats like PDF. Interestingly, AFP (now called Advanced Function Presentation) has kept up with this change in printing needs. Let’s look at some of the innovations for AFP.
Text to AFP
An easier alternative to creating AFP input is convert plain text into more pleasing formats using AFP resources like fonts and page definitions. For this IBM created the Page Printer Formatting Aid (PPFA) in 1990. PSF can also accept plain text for printing on AFP printers, as well as XML data.
Easily Create AFP Documents
Initially creating AFP documents from applications was difficult. IBM fixed this with their AFP Toolbox (previously AFP API). A small number of Microsoft Windows solutions for designing and producing AFP documents such as the ISIS OverView AFP designer are also available. Other non-mainframe tools for analysing existing AFP data for design and debugging can also be found.
Interestingly, the Apache project has released an AFP Renderer for Apache FOP. However this has not been updated since the initial version was released in 2005.
Print to Other Printers
The days of centralised printing are over, and companies are now printing on smaller remote printers. Software such as PSF supports and manages AFP printers connected via channel, SNA or TCP/IP. Other products allow AFP printing on non-AFP printers, including standard PCL and PostScript LAN printers.
View AFP Online
Because AFP is a combination of input data and resources such as fonts and overlays, it has never been designed to be used as a file in the way that PDF has. However AFP can be saved as files from the AFP Conversion and Indexing Facility (ACIF) included with PSF. IBMs Content Manager on Demand also uses a version of ACIF to create AFP documents for online viewing. AFP documents can also be created by some non-mainframe AFP design tools, and other software such as ISIS Papyrus.
These AFP documents can be viewed online by PC based software such as IBMs AFP Web Viewer and ISIS Papyrus AFP Viewer. IBMs Content Manager on Demand also provides an AFP online viewer.
Convert Other Formats to AFP
In some cases it makes sense to use AFP printers or facilities for non-AFP output. This could include PDF or web content, or data streams for other printers such as PCL, PostScript, Xerox LCDS and metacode, or Xerox XES. There are products that will do this, including IBMs Infoprint Server, Xerox XPAF, ISIS Papyrus, and LRS VPS/XES.
Convert AFP to Other Formats
There are now many products that will take AFP data, and convert it to other formats. For example LRS VPS/PCL, MPI Tech DocOut and IPS OnePrint will print AFP output on non-AFP printers. Other products such as LRS VPS/PDF, IBMs Infoprint Transforms and MacKinney Print Transform will convert AFP documents to PDF files. Similarly products such as CrawfordTech Transforms will convert AFP to HTML.
Include PDF and JPEG
AFP can print images in AFP formats: GOCA (Graphics Object Content Architecture) and IOCA (Image Object Content Architecture). However AFP today includes containers. Or in other words, more familiar objects such as PDF documents and JPEG images can also be included in documents.
Colour, Unicode and True Type Fonts
AFP has been enhanced over the years to include all of the above and more.
An Independent, Open Standard
AFP was initially created and owned by IBM. IN 2004 IBM created the AFP Consortium, a group of companies working to enhance and improve the AFP standards. AFP was handed over to this group in 2009. So now AFP is an architecture that is not owned or controlled by any one company.
Archive and Distribute Documents
There are now several output management products that support AFP documents for archiving, online viewing and distribution. We talk more about output management in our LongExp article on Report and Output Management Products.
AFP is a Page Description Language (PDL), though it also performs other functions like printer management and control. The most familiar alternate PDL is Adobe’s PDF. Discussions comparing AFP and PDF generally agree that PDF is easier for online viewing and document sharing, whereas AFP comes through for high-throughput printing. Other PDLs include Adobe’s PostScript, HPs PCL, Microsoft XPS and Xerox’s LCDS/Metacode.
For mainframe users, the reality is that few of these alternate PDLs are available. Xerox’s LCDS/Metacode certainly still exists, but is considered a legacy option. Interestingly there are almost no commercial z/OS-based APIs for creating PDF documents . SAS/ODS and Java PDF libraries are the best to be found. z/OS based APIs for PCL, PostScript, XPS or any other PDL familiar to non-mainframe users simply don’t exist. Most solutions assume an AFP input, and perform translation to PDF, PCL, PostScript or XPS as required.
The Way Forward for AFP
It is easy to debate the relative strengths and weaknesses of AFP against its competitors. However the fact is that AFP does the job, and in mainframe high-volume printing environments, does it better than others. With recent enhancements, AFP continues to provide the functionality needed for todays document and report creation. And many solutions let AFP play with the rest of the world: printing AFP documents on any printer, or converting them to more familiar formats like PDF.
From a mainframe perspective, AFP isn’t going anywhere. Mainframe sites generating documents on the mainframe use AFP. They already have the software and the hardware, together with existing applications and solutions. Those wanting to say goodbye to AFP are faced with few mainframe based alternatives. This will no doubt force some to move document generation and creation off the mainframe.
It’s clear that for mainframes, AFP is here to stay.