Make Your Data Flow Like A River – Segment 2

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 our last article we introduced the Record Formatting Function of the page definition.  In this article we’ll explain how this function works and present a common output scenario where it could be applied.

The Mechanics of the Record Formatting Function

In our last article we laid out many of the features of the Record Formatting Function, but now for the million dollar question – how is all this accomplished?  First let’s look at the data on the spool.  Remember the carriage-control character?  With Record Formatting instead of a CC you have a record ID that is a 10-byte field and the beginning of each data record.  Unlike CC, which mostly functions as vertical tabs, the record ID serves to define what type of data is in the record.  Is the data in this record a header that should be repeated every page or just one of several line items that should be printed as part of a table?  It’s the record ID that informs the pagedef what type of data is in the record.

How, exactly, does a record ID tell a pagedef anything?  The record ID matches up with a layout format within the pagedef.  To implement Record Formatting you need a pagedef that uses the LAYOUT command instead of the PRINTLINE command.  There are four types of LAYOUT commands:

·         Page Headers – Printed on every page

·         Page Trailers – Printed on every page

·         Group Headers – Text and graphics to be printed at the beginning of a group of data.  If a logical page eject occurs before you reach the end of the data for a group, the group header is printed at the top of the next page prior to the remaining data (think headings for columns of a variable sized table that might span pages)

·         Body records – Basically, any record that isn’t one of the above.  Body records make up the majority of the data in the spool file.

What you end up with is a pagedef with LAYOUT commands defining how record IDs are to be handled.  Those same record IDs are then found prefixing each record in the output data sitting on the spool.

A few important notes about using Record Formatting:

·         A pagedef for Record Formatting uses the LAYOUT command instead of PRINTLINE command.  You cannot mix LAYOUT and PRINTLINE commands within a single pagedef, you can use one or the other but not both

·         The record ID in the data is treated as a hexadecimal string, not as a character string.  Basically what this means is that if you’re going to be moving stuff between ASCII and EBCDIC platforms there is no transform done on the record ID in the data prior to attempting to match it up with a layout ID in the pagedef, so plan accordingly and test, test, test.

·         If you are using Record Formatting, TRCs are cannot be used.

·         If you are using Record Formatting, you can also use CCs.  You can have data that is mixed mode, using both Record Formatting and 5A records.  In this case all of your data must have a CC byte that is not counted as part of the 10-byte record ID.  If you’re not doing mixed mode, then a CC byte is allowed but not required.

A typical formatting problem

Let’s take a look at an example where Record Formatting might come into play by walking through a simple bank statement that shows monthly activity for checking and savings accounts.  Here’s what our target output should look like:

·         On every page, place the page number on the bottom left

·         On the first page

o        Bank logo in the upper left corner

o        Customer’s address block

o        Statement date in the upper right corner

o        Customer service number below statement date

o        Follow the above information with the customer’s account data

·         If the statement is more than one page long don’t print the information that appears on the top of the first page on the additional pages, just start printing the data with column headings at the top of the page

·         The customer data should be laid out as follows

o        After the above info begin printing the checking account information.

o        Once the checking account information is finished begin printing the savings account information

·         After the customer data, print a marketing message

This is a simple yet fairly typical banking statement.  Now spend a little time thinking about how you would do the above without Record Formatting (saying you’re going to install a package for dynamic formatting of AFP output is cheating).  Conditional processing is one route, but the variable length of the customer data sections would probably make conditional processing cumbersome or completely impractical.  You could certainly accomplish the above by having your application output AFPDS, but that can be a tricky proposition.  Probably the most practical way would require mixed mode output from your application, and then on the AFP resource side a few page overlays and a pagedef with several page formats.  But no matter what route you chose your application would need significant amounts of code for the formatting the statement, and down the road the ongoing maintenance of your application could be difficult. 

Now that you’ve got a high-level understanding of Record Formatting you should be able to get an inking of how it would apply to the bank statement example above.  In our next article we’ll give you an overview of our solution based on Record Formatting.

Watch for Part 3 of “Make Your Data Flow Like A River” in an upcoming issue of the OutputLinks eNews.  In our next article, we’ll provide more details on how to implement Record Formatting to format the output for our example bank statement.

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.