Pertech transaction printer

[Paul Mitchell]

Hello,
  We've just upgraded a PeopleSoft installation at UNC (production, unfortunately) and a small, and unexpected, snafu has occurred.  The Pertech 5371 Slip/transaction printers (which are hanging off of USB ports on various Windows XP desktop in the Student Finances office) have stopped working correctly.

It goes without saying that the person who purchased these devices had no idea what they were doing. Not only do they have a superfluous paper roll capability, but they have no networking, whatsoever.

Previously, our App servers were running Solaris 10, and we were able to define the printers via the /etc/printers.conf file.  When the PeopleSoft software printed a receipt, the transaction printer would go into validation mode, and openning a slot to drop a check, or receipt into, before it would print.

The new App servers are running
2.6.18-238.9.1.el5xen #1 SMP Fri Mar 18 12:53:42 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux, and using both CUPS 1.3.7, and 1.4.6, when a receipt is generated, it prints directly to the paper roll, never entering validation mode.

The Pertech driver on the Windows box has "validation" mode selected, so it would appear that the CUPS generated print is not accessing the Pertech driver.
Local test prints from the Windows box go instantly into validation mode, as do print jobs from the retired Solaris servers.  The Pertech support-guy says we need to feed an <ESC><0><C>, but we're not feeding anything to it from the Solaris side and it works!

Any pointers will be appreciated! Thanks,

Paul Mitchell