HVTO Search Engine
Search AFP FAQ
OUTPUTLINKS ONLY
600+ HVTO SITES
HVTO Columnists Guide
In This Section
This column will deal with the technical and implementation aspects of AFP. This column is for the person who, ultimately, needs to make this stuff work and so we welcome your comments, questions, or suggestions for topics of interest for future articles.
Contact a Columnist

All emails are read, but columnists cannot respond to each query because of the volume of email received. When contacting a specific columnist, please put his name in the subject line of your email. Thanks!

Columnist

AFP FAQ

AFP Frequently Asked Questions

Peruse the wisdom shared and questions answered by some of the HVTO industry’s premier AFP talents. Feel free to submit your questions to AFPGuru@OutputLinks.com.

Article
Sep 15, 2008

Make Your Data Flow Like A River – Segment Three

By Paul Kiel and Dave Webber, Senior Output Consultants


Welcome again to AFP Tech, where we deal with the technical and implementation aspects of AFP and the computer output environment. In this series of articles, we’ve been exploring the Record Formatting Function of the page definition. In our first article, we introduced Record Formatting Function, the second article we explained how this function works and presented a common output scenario where it could be applied. In this article we’ll show how the Record Formatting Function can be used to meet the formatting requirements in our example from Part 2.

 

Using Record Formatting

In our last article, we presented a typical bank statement as a formatting problem. We then considered how to actually meet the formatting requirements using different techniques: conditional processing; pure AFPDS output; mixed mode output – but each of these routes has significant drawbacks. However, with Record Formatting all you need is a handful of LAYOUT commands and associated record IDs to meet the requirements.  For instance:

·         Page numbering: One LAYOUT command within the pagedef; within the data, one data record with a record ID matching this layout command and all of the page numbering for the statement is complete no matter how many pages long it is.

·         First page information: One LAYOUT command in the pagedef; within the data, one line of data starting with the record ID matching this layout command followed by the variable data (customer address, etc…) needed.

·         Checking account information: Just to get a little fancy we’ll use three LAYOUT commands:

o        Checking account column headings: One LAYOUT command in the pagedef; within the print data, one data record with a record ID matching this layout command.  All of the headings for the checking account information is taken care of whether the there is only one check or 100 pages of checks

o        Checking account data:  One LAYOUT command in the pagedef; within the print data, one line of data for each transaction starting with the record ID matching this layout command followed by the data to be printed.

o        Checking account summary:  One LAYOUT command in the pagedef; within the print data, one line of data starting with the record ID matching this layout command followed by the summary information (totals, etc…) to be printed.

·         Savings account information: Implement the savings account formatting just like the checking account (LAYOUT commands and record IDs for headings, data & summary) but make the appropriate changes as required.

·         Marketing message: One LAYOUT command in the pagedef; in the print data, one data record with a record ID matching this layout command and the any variable data you would like to add to personalize it. Or, you could have several LAYOUT commands with different marketing messages and have your application choose (via record ID) which one to deliver to the customer this month.

 

And that, friends, is all there is to it. No counters in your application to keep track of page numbering; No subroutines to determine if there’s enough space left after the end of the checking account information to start the savings account information on the same page or do a page eject first; No keeping track of what line you’re on so you can determine when to stop printing data and print the page number at the bottom of the page. Just create your pagedef with the appropriate LAYOUT commands, send your data to the spool with the matching record IDs, and then go watch your printer do its thing.  It’s like you’ve died and gone to Boulder.

 

How to get started?

When you first brought in your AFP printers, you probably had an application or two that justified the entire installation.  To get those applications up and running you probably had your vender ante up some skilled resources to do a significant portion of the work and provide skills transfer in the process.   You should get started with Record Formatting the exact same way.

 

Cast your gaze about your particular print operation and pick an application or two that, for output formatting reasons, are either maintenance nightmares or just, shall we say, aesthetically challenged.  Now, take a good look at the output – are there sections of data that are variable in size? If so you probably have a good candidate for implementing Record Formatting. And just like when you first brought up AFP you want to consider bringing in outside help, probably in the form of contractors, to bring up your first Record Formatting application and to do skills transfer in the process. The frustration level will be lower and your chances of success significantly higher.

 

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.

 

Segment 1 >>>    Segment 2 >>>

Rate This Article
Fullname
Company Name
Email Address
Rating