Brief: Writing barcoding applications used to be a job for only the most skilled programmers. Enhancements in printer technology, advanced function printing and DDS keyword support bring this capability within everyone's reach.

Creating a barcode application on the AS/400 should be as simple as writing a report or running a Query. But until the introduction of advanced function printing and the Intelligent Printer Data Stream (IPDS) printers, things were not so easy. (See "Barcode Printing on the AS/400," MC, January 1994.)

There are basically two ways to create barcode applications quickly. One way is to use a special DDS keyword in an externally defined printer file to be used in an application. The other way is to use IBM's Advanced Function Printing Utilities/400. Both methods use advanced function printing to print text and images on a printer.

The path you choose depends upon a number of factors: the availability of tools, the strategic value of the application, the maintenance profile and standards of the applications your shop creates, how urgently you need the application and-finally-your own desire to dig into the technical requirements.

You might decide to write an RPG program that takes advantage of DDS keywords developed specifically for advanced function printing and-in particular- barcode printing. For the majority of AS/400 programmers, DDS represents the most straightforward means of providing barcode capabilities: the complete power of IPDS printers and advanced function printing can be readily integrated into existing applications, and the learning curve is slight.

The other choice is to use Advanced Function Printing Utilities/400's Print Format Definition, which offers you a fast means of creating a simple application: the learning curve is very easy but this method may not fit into your environment.

The best methodology depends upon your environment and your application needs. This article shows you the technique of using an RPG program and an externally defined printer file. The Advanced Function Printing Utilities/400 technique will be covered in an upcoming article.

Requirements

You must have an IPDS printer available to you for this sample program. IPDS is the key that makes barcode applications easy to create on the AS/400.

The following IBM printers have IPDS capabilities:

o IBM 38XX series printers which include 3812 defined as AFP(*YES), 3816, 3820, 3825, 3827, 3831 and 3835.

o IBM 4XXX series printers which include 4028, 4224, 4230 and 4234.

If you're using any of these printers, you should verify that it will support the particular barcodes you need to print. For instance, my shop's IBM 3812 printer does not support POSTNET or Code 128 barcodes. The system won't inform you of the limitations of the printer to which you're sending your output. You need to obtain some printer specifications to learn what your particular machine supports. Printers attached through PC Support cannot print barcodes using advanced function printing even though the printer itself may be capable. However, some printers attached through PC Support can print barcodes using other methods. (Look for an article on this topic in an upcoming issue.)

The Sample Application

Our sample application is very simple: we'll create a report which prints a vendor master name and address list. Instead of printing the vendor number field in the usual numeric representation, we'll print it as a Code 3-of-9 barcode. A sample label is shown in 1.

Our sample application is very simple: we'll create a report which prints a vendor master name and address list. Instead of printing the vendor number field in the usual numeric representation, we'll print it as a Code 3-of-9 barcode. A sample label is shown in Figure 1.

A preliminary step to creating the report is to create a vendor master file- the DDS is shown in 2. The RPG program (3) to print our report is very simple; all the barcode- specific coding is defined in the DDS for the printer file (4). We simply open the file, read a record and write out the print file record.

A preliminary step to creating the report is to create a vendor master file- the DDS is shown in Figure 2. The RPG program (Figure 3) to print our report is very simple; all the barcode- specific coding is defined in the DDS for the printer file (Figure 4). We simply open the file, read a record and write out the print file record.

The DDS in this example utilizes the built-in row and column orientation to position the barcode. However, if we were working with an application requiring exceptionally small tolerances for the placement of the barcode (such as POSTNET applications on letters or labels), we could place the code at specific locations using the POSITION keyword instead. (POSITION allows you to identify the exact location of a barcode, image or graphic in increments of inches or centimeters.)

There are some specific requirements for barcode output. For example, the database field for vendor number (VNDNBR) is defined as a numeric field, but the VNDNBA field in our printer file must be alphabetic. The reason for this requirement is that if a barcode type allows alphabetic characterization, the DDS field referencing the barcode keyword must match those characteristics. Code 3-of-9, used in our example, allows alphabetic characterization.

Secondary parameters of the BARCODE keyword must also be specified to obtain the desired results. The format for the BARCODE keyword is shown in 5. We need only a few parameters for our sample application, but we'll review all the available options.

Secondary parameters of the BARCODE keyword must also be specified to obtain the desired results. The format for the BARCODE keyword is shown in Figure 5. We need only a few parameters for our sample application, but we'll review all the available options.

In our sample application, we're specifying a Code 3-of-9 barcode, with a height of two lines. No human-readable representation of the code will appear on the printout. And we'll use a check-digit of hex 02 to help us verify the reading of the barcode by our scanners. Refer to 4 for the DDS which defines these specifications.

In our sample application, we're specifying a Code 3-of-9 barcode, with a height of two lines. No human-readable representation of the code will appear on the printout. And we'll use a check-digit of hex 02 to help us verify the reading of the barcode by our scanners. Refer to Figure 4 for the DDS which defines these specifications.

The first two parameters specify the barcode type and the height. The DDS BARCODE keyword supports 16 different barcode types (see 6).

The first two parameters specify the barcode type and the height. The DDS BARCODE keyword supports 16 different barcode types (see Figure 6).

The HEIGHT parameter represents the number of lines which you want the barcode to consume. In our example, we specified a height of two lines.

The next parameter is optional and defines the orientation of the barcode- horizontal (*HRZ) or vertical (*VRT).

The *NOHRI parameter prevents the human-readable interpretation of the code from printing. The default value of *HRI causes the interpretation to be printed along the bottom of the barcode and *HRITOP prints it along the top.

When printing a Code 3-of-9 barcode, you can specify *AST or *NOAST as an optional parameter. *AST only affects the human-readable interpretation (if one is requested), not the barcode itself. Specifying *AST forces a single asterisk to print on either side of the human-readable interpretation. However, these asterisks are not translated into the barcode. The default of *NOAST suppresses the printing of these asterisks. In either case, the barcode itself looks the same.

The check-digit (hex 02) parameter identifies the check-digit type, which can be any one-character hexadecimal value other than FF. Check-digit scanning-if supported by your barcode reader-places an extra digit within the barcode as a means of validating a barcode. In such a validation scheme, the characters of the barcode are internally summed by the reader and compared to the check digit. If they match, the barcode is considered valid. Otherwise, the barcode is rejected automatically by the reader.

*WIDTH specifies the width (in inches) of the narrow bars of the barcode. The valid values are .007 through .208.

*RATIO specifies the ratio of wide bars to the narrow bars. The valid values are 2.00 through 3.00. For example, a value of 2.00 specifies that the wide bars should be twice the size of the narrow bars.

Advanced Function Printing Makes It Easy

Whichever means you use to create your barcode application-either through DDS or Advanced Function Printing Utilities/400-advanced function printing provides you with adequate tools and a good maintenance profile. No longer are you required to translate printer control codes into hexadecimal encapsulations. IPDS printers and advanced function printing provide you with an architecture which will support your applications without laborious translation. While you are still required to research the capabilities of the IPDS printer you're using, you don't have to "get down and dirty" to get the application to work.

Best of all, as your printers change-through upgrades or turnover-your barcode application will remain viable. And if your shop develops a need to print a different type of barcode, the changes to your application will be slight. Overall, the DDS keywords and IPDS printers offer us a good method to meet the printing demands of our users.

T.M. Stockwell is an associate technical editor for Midrange Computing.

REFERENCE Data Description Specification Reference (SC41-9620, CD-ROM QBKA7402).

Barcoding with DDS

Figure 2 The XTS001PF Physical File

 *============================================================ * To compile: * * CRTPF FILE(XXX/XTS001PF) SRCFILE(XXX/QDDSSRC) * *============================================================ *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+.. A R VNDMST A VNDNBR 5P 0 A NAME 25A A ADDR1 25A A CITY 15A A STATE 2A A ZIPCD 5P 0 A VNDSTS 76A *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+.. 
 
 Barcoding with DDS
 
 Figure 3 The XTS001RG RPG Program
 
 *============================================================ * To compile: * * CRTRPGPGM PGM(XXX/XTS001RG) SRCFILE(XXX/QRPGSRC) * *============================================================ *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+.. FXTS001PFIF E DISK FXTS001P1O E PRINTER C READ XTS001PF 99 C *IN99 DOWEQ*OFF C MOVE VNDNBR VNDNBA C WRITELABEL C READ XTS001PF 99 C ENDDO C MOVE *ON *INLR *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+.. 
 
 Barcoding with DDS
 
 Figure 4 The XTS001P1 Printer File
 
 *============================================================ * To compile: * * CRTPRTF FILE(XXX/XTS001P1) SRCFILE(XXX/QDDSSRC) + * DEVTYPE(*AFPDS) * *============================================================ *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+.. A R LABEL A VNDNBA 5A 1 1BARCODE(CODE3OF9 2 *NOHRI - A *AST X'02') A NAME 25A 5 1 A ADDR1 25A 6 1 A CITY 15A 7 1 A STATE 2A 7 17 A ZIPCD 5 0 8 1 
 
 Barcoding with DDS
 
 Figure 5 The Format of the BARCODE Keyword
 
 BARCODE(bar-code-id [height] [[*HRZ || *VRT [*HRI || *HRITOP || *NOHR [*AST || *NOAST [check-digit] [*WIDTH value] [*RATIO value]]) 
 
 Barcoding with DDS
 
 Figure 6 DDS Supported Barcodes
 
 Barcode ID Data Type Field Length MSI signed numeric 1 - 31 UPCA signed numeric 11 UPCE signed numeric 10 UPC2 signed numeric 2 UPC5 signed numeric 5 EAN8 signed numeric 7 EAN13 signed numeric 12 EAN2 signed numeric 2 EAN5 signed numeric 5 CODEABAR character 1 - 50 CODE128 character 1 - 50 CODE3OF9 character 1 - 50 INTERL2OF5 signed numeric 1 - 31 INDUST2OF5 signed numeric 1 - 31 MATRIX2OF5 signed numeric 1 - 31 POSTNET signed numeric 1 - 31 

Thomas M. Stockwell is an independent IT analyst and writer. He is the former Editor in Chief of MC Press Online and Midrange Computing magazine and has over 20 years of experience as a programmer, systems engineer, IT director, industry analyst, author, speaker, consultant, and editor.  

 

Tom works from his home in the Napa Valley in California. He can be reached at ITincendiary.com.

 

 

Also Read

Practical Middleware: Architecting for the Future

Practical Middleware: Starting the Journey

IBM i 7.2: The Carrot Versus the Stick