Printing to Specialized Printers on the iSeries

by Michael Sansoterra

I had a customer using iSeries terminals as point-of-sale (POS) cash registers. In addition to some new 5250 thin-client stations, this customer purchased specialized Epson POS receipt printers, which had attached cash drawers. The receipt printer, of course, didn't print on a standard-sized sheet of paper and had specialized codes to print in red and to open the cash drawer! I wondered how the iSeries would be able to do something like open a cash drawer.

It's easy to print to a specialized printer from an iSeries, if you know the control codes required to make the printer perform its odd functions of printing in red and opening drawers, and if you are using an externally described print file.

I looked in the manual for the POS printer and located the control codes for the special functions I needed to use. As it turned out, opening the cash drawer was as easy as sending the hex string X'1B700032' to the printer. But, wait! It couldn't be that easy, because whenever data is sent to a printer from an iSeries, the iSeries attempts to convert the data from EBCDIC to ASCII, because the POS printer is an ASCII printer. One solution would be to convert the codes from ASCII to EBCDIC first, so that they would translate correctly back into ASCII when sent to the printer.

The thought of trying to revert the codes in the manual from ASCII to EBCDIC was unappealing for the several reasons. It would be time consuming to convert all the codes. And there are several different ASCII-to-EBCDIC translation variations on the iSeries; I couldn't determine which one the iSeries used when printing documents. Also, it might be confusing for another programmer seeing a discrepancy between the printer codes given in the manual and those that were actually in the printer file. And even if I could translate these into ASCII, what's to say that these codes wouldn't turn out to be the same as an existing *SCS printer command?

For situations involving specialized printers, it would be nice to just be able to send some commands to the printer without worrying about the EBCDIC-to-ASCII translation. DDS offers just such a feature, with a keyword called TRNSPY (transparency).

When TRNSPY is specified for a field or a constant, it instructs the iSeries to do nothing except pass the codes on verbatim to the printer (meaning don't perform data translation and don't try to interpret the hex data as a command). With TRNSPY, I had to do nothing more than type the hex codes into the printer file source member with this keyword specified. Here are a few examples that I used for the POS printer:

A          R DRWOPN
A                                      TEXT('Drawer Open')
A                                     1
A                                      X'1B700032'
A                                      TRNSPY
A          R CLRRED
A                                      TEXT('Color Red')
A                                     1
A                                      X'1B7201'
A                                      TRNSPY

Since the printer file contains the specialized codes, the rest is a piece of cake. Opening the drawer from an RPG program is now as simple as writing the DRWOPN record format. To print in red, just write the CLRRED format.

Of course, the point isn't how to print to POS printers on the iSeries, which most readers will never do. The point is that when you have an ASCII printer that has special capabilities (like POS or label printers), the transparency keyword is likely to be a valuable aid in getting the printer to function correctly. If you've ever shied away from a particular type of iSeries-related printer job because you weren't sure how to send it the proper codes, you need not wonder any longer. TRNSPY allows you to send the codes effortlessly from your iSeries!

Michael Sansoterra is a programmer/analyst for SilverLake Resources, an IT services firm based in Grand Rapids, Michigan. E-mail: msansoterra@silver-lake.com

Sponsored By DAMON TECHNOLOGIES

Make Stored Procedure Testing easy with STE STE (Stored Procedure Test Environment) is the easiest way to test Stored Procedures. · Prompts for input parameters. · Display the result set or multiple sets. · Display the returned parameters. · Screen or printed output. After creating a stored procedure, developers are faced with the challenge of testing. With STE, the developer can easily call the stored procedure, step through debug, view the returned parameters, and result set or multiple sets. STE is an excellent communication tool between the developer of the business logic and the web developer. STE will produce a report, listing the input parameters, showing the result set(s) and the out parameters, thus eliminating miscommunication between developers. Download your FREE copy of STE today! www.damontech.com