If you trace back the family tree of the modern iSeries 400 server, you will eventually encounter the IBM S/3 computer. One of the key focuses of the S/3 was to take input from punch cards and then internally process the input to produce a printed report. The modern printer of that time was an impact printer, making marks on the input media (green-gray bar paper) with a series of mechanical components that typically struck an inked ribbon.

The definition of an IBM midrange printer has typically stayed very close to this original S/3 concept in that the printer has been seen as a physical device that took some form of printable media from an input source (frequently continuous form green or gray bar paper) and produced marks on that media according to the instructions the printer received from an IBM midrange server. After completing the making of the marks on the page, the output was moved to some sort of output destination.

In this article, I will cover some of the possible benefits that could be obtained by defining some nontraditional devices (cell phones, personal digital assistants [PDAs], vending machines, etc.) as printers on an iSeries server. Most of the information contained in this article describes possible applications that could be implemented with existing technology, rather than summarizing or explaining applications that already exist. Thus, the examples contained in the article are illustrative and are meant to stimulate your imagination for what could be done in the future.

Targeting Wireless Devices as iSeries Printers

The benefit of thinking of a wireless device as a printer on an iSeries is that it makes the device capable of receiving information that is usually only available in a printed format. Thus, the target audience (users with wireless devices) can receive more valuable information from the server without significantly increasing the overhead cost to the owner of the server.

As an example, imagine an iSeries software application for dispensing prescriptions at a doctor’s office. If you visit the doctor’s office and need a prescription, the healthcare professional is able to enter the prescription information into the system, and a prescription is then printed for you on some type of traditional printing device.

It’s possible that at some point in the future, healthcare providers will want to be able to send prescriptions to patients directly, rather than have patients come into the office.

How do you accomplish this? One solution could be to consider wireless devices, such as cell phones and PDAs, as iSeries printers.

In this scenario, the software vendor could link the powerful database capabilities of the iSeries server with the convenience of a personal wireless device. The prescription application could be enhanced to print remote refill prescriptions in the following manner. The prescription would consist of three text components:

• Header—Doctors’ office information and authorization signature
• Body—Text describing what should be dispensed by the pharmacy
• Footer—A security signature used to prevent unauthorized dispensing of prescriptions

The text could then be sent to the patient by printing the information from the iSeries server on what the iSeries thinks is a LAN-attached printer but in reality is an input queue at an ISP. You use an ISP to send text messages to cell phones or text pages to PDAs. The ISP would receive the information and then dial the appropriate phone number to send the text message or page. It could also be possible to print the information to an iSeries output queue that feeds a paging or voice-calling response unit that was part of the iSeries server itself.

Patients would receive messages and temporarily store them on their cell phones or PDAs. When they later visit the pharmacy, they would transfer the text message into the pharmacy server for printing and to be filled. The header text would trigger the pharmacy server to pull from the software vendor’s database the proper overlay for the prescription, the prescription data in the body of the message would be entered into the overlay, and the security information would be pulled from the software vendor’s database—all on the local server.

A Role for AFP Printing in the Wireless World?

Frequently, iSeries users decide to create applications that take advantage of the AFP report-generation capabilities that are an integral part of OS/400. The image shown in Figure 1 (page 82) shows a standard page format, frequently used in North America, for printing statements that include an electronic form overlay. Here’s a scenario where you might use a wireless device to display an AFP document.

Imagine that a bank wants to offer its customers the capability to query the customers’ current account balance from a wireless device. When the bank investigates its iSeries environment, it finds that the data it wants to offer its wireless customers is already included in an AFP-generated report formatted as shown in Figure 1. What could the bank do to get this information out to its customers without a significant amount of programming effort?

One possibility is to use a wireless device as an AFP report viewer. On a standard PC, it is possible to run a Client Access-based application that allows you to view AFP files on your screen. It is also possible to create a scaled-down version of this concept that could run on a wireless device. One of the nice benefits of the IPDS data stream, which is generated to support AFP-based applications, is that it is a page description language. A cell phone or PDA acting as an IPDS-capable printer can report back to the host the paper size currently loaded into its input drawer. This feature allows a viewing program to create a type of zoom feature that can ensure most of the received page is ignored, and only a small area of the report page to be displayed will be visible on the screen.

The benefit of this solution is that the iSeries server would always know whether the data actually reached the wireless customer or not, because verification of delivery is a requirement of the IPDS data stream. One potential downside of this idea could be that the typical wireless network bandwidth available would not be able to support sending the complete page of the report, with its overlay, just to show a single data field on the screen of the wireless device.

Another option would be to use some IPDS data stream conversion software to change the data stream from its native format into a bitmap. The software looks like an IPDS-capable printer to the generating application and would receive the page to be printed in IPDS format. The application would then convert the IPDS data describing the page into a bitmap of the page. A bitmap parsing program could then extract the required information from the bitmapped page and include this much smaller bitmap in a Web page or other low, overhead transmission scheme to get the information out to the wireless device for viewing.

Thus, the answer to whether delivery of AFP content can be achieved to wireless devices is yes, but the delivery method must be carefully analyzed so as not to overwhelm the bandwidth available in today’s wireless networks.

SNMP: Can Anything to Do with Printing Be Simple?

SNMP is the acronym for Simple Network Management Protocol. SNMP describes a network management concept, typically used in TCP/IP-based networks, that relies on processes known as agents. The agent processes, which are running within the network, are able to learn about many different types of network conditions in order to allow SNMP manager applications to manage the network events effectively on a recurring basis. The management of print devices is described in Internet request for comments (RFC) document 1759. The RFC document explains the requirements for installing a management information base (MIB) in a device operating as a printer that will be compatible with printer monitoring agents in an SNMP-managed network. By following the guidelines outlined in the RFC, it is possible to turn many different types of devices into SNMP- compatible printers. For the purpose of explanation, I will outline how a vending machine could be added to a TCP/IP network and managed as a printer from an iSeries server using SNMP.

Why a Vending Machine?

In many companies, it is possible for employees to select from a series of optional deductions to their paychecks. Some optional choices can frequently be monthly parking passes or monthly commuter passes on public transit. I always thought it would be a great idea to have a vending machine deduction. The purpose would be to allow employees to determine how much money per month they wanted to put aside for purchasing snack food from vending machines that are installed in their workplace. In order for this idea to work, you would probably need a software application that would be able to keep track of the amount of money currently available in an employee’s snack account. You would also need a method for the application to transfer requests for snacks to a network-attached vending machine. Since printers are usually the recipients of host-based data, printers are probably one of the best choices for an application of this kind.

The SNMP-enabled Vending Machine as a Printer

Following the outline of RFC 1759, I will assume the Sparkling Vending Machine Company has decided to offer a new 10/100 Ethernet network-attachable vending machine for the workplace. The machine offers the ability to support eight different flavor selections of soda. The machine that I will be analyzing is configured as shown in Figure 2.

One of the requirements of the RFC is that the MIB printer characteristics must include the number of input trays available in the device and the media type (typically paper size) that is installed into each of these trays. What you can see from the chart in Figure 2 is that the MIB, for the vending machine acting as a printer, has defined the eight bays where soda will be stored as input trays. The current flavor selections available are listed as the media types. If a different flavor is loaded into any of the bays in the vending machine, an LED panel in the machine allows the person filling the machine to select the new flavor that is now in the bay. The LED panel updates the SNMP MIB stored in the network interface of the machine.

Managing the Vending Machine

The Sparkling Vending Machine Company has partnered with an iSeries back-office accounting vendor to ensure that their new 10/100 Ethernet-attachable vending machines can be used by companies that own an iSeries server. The software vendor provides a set of display screens, which allow employees to locate the vending machines closest to them. The process might work as follows:

1. Employees log into the iSeries application and choose the appropriate vending machine from the list of choices.

2. The application queries the appropriate SNMP agent to get an updated status as to the current flavors available in the machine.

3. A second screen is then displayed that lists the flavor choices and costs of the soda available in the target machine.

4. The employees then make their selections.

5. The application verifies that the employees’ accounts have enough credit to cover the transactions. If not, the application returns an error message and requests that a new selection be made.

6. Assuming the transaction is found to be valid, the application prints a header page for the iSeries spool file to be created with an order number. The application then prints a report page to the input tray (in iSeries printer file terminology, this is called a source drawer), which includes the requested flavor. On this report, the application prints a special vending code followed by a capital S for each soda requested by the employees. The S is the only character supported by the vending machine printer because it means “prepare to vend a can or bottle of soda.”

7. The application then waits a predetermined amount of time to see whether the vending machine printer reports via SNMP an “out of forms” condition—meaning that there is not enough soda left to fulfill the request. If this event occurs, an error message is generated for the employees, and a request to make a new selection or end the transaction is displayed.

8. If no error message is received, the application continues with other flavor requests by sending report pages to other input trays until the whole order is completed. If no “end of form” messages are received, the application moves toward the payment phase of the transaction.

9. The application now sends a payment authorization value to the vending machine to close the transaction. The application prints the final page in the spool file using a special payment code. The page format is the payment code followed by the capital letter P, the order number from the header page, and a randomly generated code that the employees will have to enter through the keypad on the vending machine to prompt the vending machine to vend their orders. Employees have the option to set the amount of time the authorization code will be active in the vending machine printer. They can then copy down their activation code from the screen or have it emailed to them.

Keep in mind that this application doesn’t actually exist yet. This application is, however, a definite possibility, and it illustrates just one way you might support a new

application requirement on your iSeries server by using a nontraditional printing device. If you would like to see how to define a nontraditional printing device (e.g., a vending machine) via SNMP to an iSeries server, please read the sidebar called “Defining an SNMP Vending Machine Printer” on the Web at www.midrangecomputing.com/mc.

Figure 1: A typical AFP printer file used with portrait documents printing on letter-sized paper might use an overlay.

SNMP Described Input Tray Soda Flavor Available from This Tray

Tray 1 Cola Tray 2 Cola Tray 3 Iced Tea Tray 4 Root Beer Tray 5 Lemon-lime Tray 6 Orange Tray 7 Grape Tray 8 Diet Cola

Figure 2: This table shows what the vending machine configuration might look like.