May 6, 2008
Planning your AFP Migration
By Paul Kiel and Dave Webber
Segment 1 of 3
Welcome again to AFP Tech, where we deal with the technical and implementation aspects of AFP. In our last article we presented Line Mode Migration (LMM), a feature specific to z/OS installations that eases the migration of applications to AFP impact printers. But let's face it; most of you are using AFP to drive laser printers so in this series of articles we'll explore migrating existing applications to an AFP platform and laser technology. The good news is that the migration of your output need not be difficult, especially if you use the following as a guide to plan the migration and make the transition as smooth as possible. For the purposes of these articles we are going to assume that your AFP software and hardware have been installed and tested successfully.
One final note: These articles will assume the use of pagedefs and formdefs for the migration. Although some of these tasks could be performed on some operating systems without the use of pagedefs and formdefs, all of these tasks can be performed with pagedefs and formdefs on all operating systems that support AFP.
Vocabulary words
Before we get started, we need to share a few vocabulary words for those readers that are completely new to AFP. Feel free to skip on down to the next section if you're already comfortable with the terminology.
Print Driver: Software that prepares the output file for printing and then controls the print process. In the AFP world the print driver has many names: For example, the names used in the IBM / IPS products vary depending on which operating system it runs under, either Print Services Facility (PSF - z/OS; VM; VSE; OS/400) or InfoPrint Manager (IPM - Windows; AIX). Also, there are AFP drivers from a variety of other companies such as LRS, Xerox and Océ¬ but basically if you have at least of these products you have an AFP installation. Since most people are familiar with the Windows world you can say that the AFP print drivers are like Windows print drivers but they give the user much more control of jobs through parameters and defaults.
Resources: Files used by your print driver and printer to produce your output. An example of a resource is a font or an image. AFP resources are platform independent meaning that you can use the exact same resource across different operating systems.
Page Definition: One of AFP's resources. A page definition (more commonly referred to as a pagedef) provides formatting information so output that is not in native AFP format (which is how most applications place their output on the spool) can be converted to AFP format for printing. In the z/OS - VSE - VM world think of it as a revved up FCB. In the OS/400 world, think of it as a revved up printer-file. It provides information used to format the logical page: Fonts, line spacing, etc.
Form Definition: One of AFP's resources. A form definition (more commonly referred to as a formdef) provides information on how to handle the physical sheet of paper, activities like: Which input bin should be used? Print on both sides (duplex) or just one (simplex)? Should the output be stapled? Etc.
Electronic Overlay: Also called an electronic form. Basically, it's what the name says it is - the electronic equivalent of a pre-printed form. Load the printer up with blank stock, send the data to the printer and tell the printer to lay an electronic form on the page with the data.
Multipart Form: A form that is multiple pages thick, each page is separated by carbon paper or each page is made from carbonless paper. The printer prints one page and, once you separate the parts, you end up with multiple pages.
The overall plan
So, how exactly does one get this whole thing started? Step 1 is to take an inventory of your current paper stocks. Determine which application prints on which stock. The simplest way to migrate to AFP isn't one application at a time, but one paper stock or form at a time. After you've inventoried your paper stocks, step 2 is to determine what can be migrated using the formdefs and pagedefs that come with your software; finally step 3 is to create custom formdefs and pagedefs for everything else.
Watch for Part 2 of 'Planning your AFP Migration' in an upcoming issue of the OutputLinks eNews. In our next article we'll walk you through step 1 of the migration ('Initial data gathering') and step 2 ('Migrating applications that do not require custom resources').
Need additional information on what you've just read? Got a question in some other area of AFP technical support? Do you have some AFP trick you'd like to share with the world? Is there a topic you'd like to see us cover? Just drop us a line at AFPTech@OutputLinks.com.
Planning your AFP Migration
Segment 2 of 3
Welcome again to AFP Tech, where we deal with the technical and implementation aspects of AFP. In our last article we got you started on your migration by laying the ground work: Defining some of the terminology used for those completely new to AFP and laying out the overall three-part structure of the migration. Today we'll pick up where we left off and walk you through step 1 of the migration ('Initial data gathering') and step 2 ('Migrating applications that do not require custom resources').
Step 1 - Initial data gathering
The typical print shop has one or two stocks that multiple applications print on (green bar, plain white paper, plain white 3-hole punch, etc.) and then every other stock is tied to a specific application or two. You'll need to create a chart for each form with the following information:
- Form name
- Width
- Height
- Line spacing
- Output orientation: Either landscape (wider than tall) or portrait (taller than wide)
- Page position (margins, horizontal and vertical) - this can be a little deceiving.
For example, your application may start every page by doing 3 linefeeds so the first printed line is a half inch down from the top of the form (assuming 6 lines per inch). The actual vertical margin in this case is really one half inch higher than it looks on the output. Remember, the margins are concerned with where the first line could be printed (for vertical margins) or the first character (for horizontal margins) whether or not any visible printing occurs on that spot or not.
- Paper source - cut sheet printers only (which input bin)
- Multipart or single part form; if multipart, how many parts
- FCB (if migrating from a channel attached printer)
- Simplex or duplex
- Pagedef (leave blank for now)
- Formdef (leave blank for now)
Step 2 - Migrating applications that do not require custom resources
Flag any multipart forms or any forms you're going to put an electronic overlay on and set those aside for right now, we'll get to those later.
For everything else you need to lay your mitts on the documentation for your particular AFP print driver. What you're looking for is a chapter or appendix in one of the documents titled something like 'Vendor Supplied Pagedef and Formdefs'. For example, in the PSF for z/OS documentation what you want is the PSF User's Guide, Appendix A. 'Form Definitions Supplied with PSF' and Appendix B, 'Page Definitions Supplied with PSF'. Now check the chart that you made of your company's forms against the formdefs and pagedefs that come with the software and fill in the formdef and pagedef column in your chart with the matches you find.
For the forms in your chart that have both the formdef and pagedef column filled in at this point, test your applications by using the appropriate pagedef and formdef. For the applications that pass this test you're done. For the applications that fail this test, we move on to step 3.
Watch for Part 3 of 'Planning your AFP Migration' in an upcoming issue of the OutputLinks eNews. In our next article we'll finish your migration by taking you through step 3 ('Migrating applications that require custom resources') and the ever popular 'Gotchas' section.
Need additional information on what you've just read? Got a question in some other area of AFP technical support? Do you have some AFP trick you?d like to share with the world? Is there a topic you'd like to see us cover? Just drop us a line at AFPTech@OutputLinks.com.
Planning your AFP Migration
Segment 3 of 3
Welcome again to AFP Tech, where we deal with the technical and implementation aspects of AFP. In our last article we moved you through step 1 (“Initial data gathering”) and step 2 (“Migrating applications that do not require custom resources”). Today we’ll pick up where we left off and finish your migration by taking you through step 3 (“Migrating applications that require custom resources”) and the ever popular “Gotchas” section.
Step 3 – Migrating applications that require custom resources
What you have left to do are the applications that use multipart forms, applications requiring electronic overlays, and applications that failed step 2 testing for whatever reason. You are going to need some custom pagedefs, formdefs and electronic overlays so you have some decisions to make as to how those custom resources are created.
Let us paint a picture for you. At one extreme you have print shops that are constantly changing or adding to their output: A bank that has a side business of printing customer statements for other banks, an advertising agency printing marketing materials for its clients, etc..; at the other extreme you have print shops whose output remains fairly constant for years at a time: A manufacturer that prints invoices, checks and internal reports, a school district that prints report cards for students and attendance sheets for teachers, etc… If your company sounds more like the first group, the group with the constantly changing output requirements, you should consider bringing the tools and skills needed to create custom AFP resources in-house, but if your company sounds more like the second group then you should contract that work out. There are several firms that will create resources for you, or modify existing ones. If you’re at a loss as to where to turn for this kind of work one of the premier providers of such services is COPI of Houston, Texas (http://www.888999copi.com ).
For custom resources (pagedefs, formdefs and electronic overlays) it’s a good practice to name them the same. For example, if you’ve got an invoice for which you’re going to use an electronic overlay, then create your resources and name them something like P1INV (the pagedef), F1INV (the formdef) and O1INV (the overlay). Doing this helps down the road should any maintenance be needed either on the application or the resources. If you are having the work contracted out it’s not a bad idea to tell your contractor what names to assign just to keep everything unique within your installation.
Gotchas
Enormously Misaligned Forms: One of the more frustrating problems to run up against during an AFP migration is the “Enormously Misaligned Forms” problem, or EMF (we just coined that acronym, but we like it so it’s staying). Rather than rehash the whole discussion follow this link (http://www.outputlinks.com/html/general/kiel_webber_030408.shtml ) to our article on LMM which explains the situation and helps you understand how to find out early on if you need to worry about it. If you do, you’ll probably need a custom pagedef and formdef to resolve the issue.
Support, either external (contract) or internal (education): One of the most frequent mistakes that we find in account after account is the practice of spending lots of money, sometimes millions of dollars, on fancy new hardware and software for computer output, and then not making the best use of that investment due to lack of skills. Those skills can be from outside the company by bringing in contract support personal and consultants, or those skills can be brought in house by training (and possibly additional software, depending on what your attempting to accomplish). For more information about AFP education follow this link (http://www.outputlinks.com/html/General/COPI_AFP_Course_073107.shtml ). Either way, if your plan is to bring in contract support or develop the support inside the company, having a support contract in place with experienced output specialists during your migration is something that needs to be considered and budgeted in the project.
Fonts: Font selection can be tricky because selecting fonts is as much an art as it is a science. Select a font that closely reflects the look and feel of the printed output you are producing now. If your form contains columns of number, be sure to select fix space fonts – like Gothic Text or Courier. The simple fact is that fonts are a world unto themselves so we’ll discuss fonts in their various flavors and issues in a later article.
Summary
No matter what your current print environment, migrating output to AFP can be accomplished relatively quickly with appropriate planning and focus. These articles have focused solely on migrating the application output that is the central part, but not the only part, of any comprehensive AFP migration plan.
Need additional information on what you’ve just read? Got a question in some other area of AFP technical support? Do you have some AFP trick you’d like to share with the world? Is there a topic you’d like to see us cover? Just drop us a line at AFPTech@OutputLinks.com.