The simplest resource to implement looked to be the ESPUL HP 3000 software written and sold and supported by Richard Corn. The creator posts rarely on the newsgroup, but Corn offered this detail on how to use the print management product.

You would be using our product ESPUL to print from the HP 3000 to a Windows box into printer queues set up on that box. If you currently have Windows printing in your environment and a Windows system that hosts or has queues for the printers you want to use, you can make use of that from the HP 3000. One other option is using ESPUL to print to a locally attached printer via Reflection or MS92 session.

Finley began solving with the advice, "It can be done with mostly off-the-shelf open source stuff. But someone still needs to do a little programming."

1) You need to create what the HP 3000 thinks is a network printer to which the HP 3000 will send its output.  So, in this case you need to configure the Linux computer to look like a JetDirect box to the HP 3000. This means that you need a way to have something listen on TCP port 9100 and accept raw data from the HP 3000.

2) You need to strip out and/or convert CCTL characters to standard ASCII print controls. Therefore, you need an intercept program that processes the raw data you get from the HP 3000.

3) You need to alter your report programs so that there are some tags in each report identifying which customer it belongs to.  Your filter program needs to read the tags in the report.

4) You need some sort of PDF conversion software that will take the HP 3000 reports and convert them to PDF. You need a PCL to PDF (not text to PDF) converter to do this.  Otherwise, you will need to send the output to a printer instead of PDF.

5) You need either a web application that will restrict users to certain directories based on their login or you could even do it without a web application. This should be simple enough because you can give each user a unique Linux user account.

6) You need some sort of directory browsing application.  You could even let the customers use Reflection with its file transfer capability.

Essentially, it can be done with simply having one program that:

1) Listens on port 9100
2) Does the CCTL conversion
3) Reads the tags in the report and places the report in a specific user account based on the tag.
4) Converts PCL to PDF

Once all of the print output is in PDF, you do not need to address their printers.  Therefore, you do not need to print to their printers at all. They will be able to print from any printer at their own site.

Another 3000 vet suggested packaged software from OpenSeas, OpenPDF. Tony Summers said, "It is a product from OpenSeas on the HP 3000, and we continue to use it even though we’ve migrated onto HP-UX. The raw spoolfiles were converted in a simple two-stage process which we wrapped up into a UDC and the end result was FTP’d to the end user as a PDF file."

In the discussion that flowed across a Thursday afternoon and into Friday, Anderson was sparked by some of the ideas. "Having something that looks like a Jetdirect printer to the HP 3000 is key! My thinking is that something that looks like a JetDirect printer could be a CUPS print server. Then using CUPS in combo with Samba, and maybe SCP, will make the network connectivity issues easier to resolved, and enable the possibly of sending the output directly to the remote printer without any user intervention."

John Pitman added that he's used "an intermediate Windows box running BP FTP Surfer, with user and passworded access. Each HP user who directs printout to a specific device (that isn’t physically present) gets the output sucked off the HP to the FTP surfer to a directory specific to the user as a txt file. This is mostly to save paper and to provide data suitable for importing to Excel. Requires a job on the HP 3000 to move spoolfiles to a Posix directory, and an FTP job on the Windows system to suck them across every few minutes.

After reading Anderson's progress on the printing process, Finley summarized how available open source software and JetDirect gets the job done.

Since you are simply planning on using the Linux/CUPS machine as a store and forward message server. you could do the following:

1. Set up a CUPS server on each IP address you can give the Linux computer.  There are ways to assign more than one. One way to cheat is to pretend you have a multiport JetDirect.  I may be out of date, but the last multiport one I worked on had TCP ports 9100,0102, and 9103.  If you can get enough TCP/Port IP address combinations to satisfy all of your printing needs you may not need to do any programming.  For example 4 IP addresses = 4x3 separate “printers." I haven’t confirmed this, but if you can make each of those represent a separate Queue on the Linux computer you can assign one to each real printer.

2. Configure each Queue on the HP 3000 and print to it just as you would any network connected printer.

3. On the Linux end, simply configure each real printer to match each queue. Then I believe you’re done.

If you can’t do the above, you can send all of the output to one pretend JetDirect address and create a little intercept filter to separate the output to each real queue.

Anderson had enough advice by the end of Friday to go into a test "with two CUPS servers using scp, connected through the cloud, and setup a NPCONFIG device on MPE to print to it"

It is simple, and if addition massaging of print files is needed, the CUPS server is equipped with many powerful scripting tools, regexp, awk/sed, and tcl.

Using SCP to copy printfiles between the local CUPS server and the remote CUPS server should be very efficient, and the remote CUPS server can be anywhere in the world, anywhere that supports an internet connection. So, from the HP3000 spooler, you’ll be able to print anywhere in the world, after setting up local and remote CUPS servers. And MPE will just think they are normal JetDirect printers.

In Unix, you can use the |scp| command to copy files and directories securely between remote hosts without starting an FTP session or logging into the remote systems explicitly. The |scp| command uses SSH to transfer data, so it requires a password or pass-phrase for authentication. Unlike |rcp| or FTP, |scp| encrypts both the file and any passwords exchanged so that anyone snooping on the network can’t view them.

Less than 24 hours later, with the help of six 3000 experts, one solved problem. Independent support takes a lot of forms this year, but going to the remote network of veterans can yield a wide array of solutions.