PicLan Internals:

PicLan Network Printing Design Philosophy and Constraints

PicLan network printing functions have been the source of both joy and consternation for many PicLan users. For reasons that I still do not understand, network printing continues to be one of the most complicated aspects of design, configuration, and operation within a network.

The PicLan Network Printing Model

First a quick look at the "rules" regarding network printing:

When a print job is "detected", it is moved, as a job entity if possible, to it's destination and then deleted from the Pick spooler.

Exactly how this works is somewhat dependent on what the "destination" of the job is. Here are the possible destinations:

• A remote Pick system. Pick to Pick printing is very straight forward. The job is literally moved from one Pick spooler to another with H and S options and copy count maintained. Because the job is going to another Pick system, the meaning of the H and S options are clearly defined.
• A network print queue through a DSG. This is already pretty straight forward. The print job is re-spooler as a NetWare print job with the generating account and port number included in the job header's description field. The copy count is also maintained. If the job was spooled with an H option, then the NetWare "user hold" flag is set. Options also exist to either generate or suppress NetWare headers and extra leading form-feeds (which are different from Pick generated form-feeds).
• A local DSG printer. When spooling to a DSG local printer, less control over the job is possible. The primary reason for this is that once the job is transferred to the DSG, there is no user-interface available to manipulate the job. The DSG simply prints the job, right or wrong. This means that the H option is ignored, although the copy count still works. The biggest problem here is that there is no way to kill a printing job without shutting down the gateway. Fortunately, this type of printing is rare.
• A slave or routed printer. In this case, the SERVER-PROCESS is actually printing the job cooperatively with the PL-DEV.EXE DOS driver TSR. Again the biggest problem is that there is no user interface to control jobs. This means that jobs just print ignoring the H option (but again using the copy count). In addition, the clear out network problems, if the print goes off-line for more than 5 minutes, the job is pitched.

In understanding the PicLan network printing model, it is important to understand some history. PicLan network printing started out as Pick to Pick printing. The design goals were simple, maintain the integrity of Pick print jobs and simply move then from system to system. In a Pick to Pick environment, this model makes sense and feedback from users indicates that this model fits this environment well.

Limitations Within this Model

There are some obvious limitations with this printing model. First and foremost, PicLan is trying to bridge diverse printer control environments, sometimes with mixed results. The second, and often the more severe, issued arises from the lack of a user-interface at several points of the process. The following specific complaints have been raised about PicLan printing functions:

• The need for form-feed control allowing the adding and deleting of both leading and trailing form-feed characters.
• Utility routines for the setup of printer characteristics such as portrait vs. landscape on laser printers.
• Maintenance of Pick HOLD jobs for subsequent re-printing.
• The ability to use Pick spooler commands instead of NetWare PCONSOLE commands to manipulate print jobs.
• The ability to kill, hold, and otherwise control DSG local and slave/routed printing.

All of these problems are real. Some of them can even be considered severe for some customers. In general, these limitations fall into several categories:

• Things that make sense and are easy to implement within the current PicLan design model. This includes form-feed manipulation functions (which are already implemented in the current release).
• Utility functions such as printer setup routines which can be argued to be application problems and not network printing problems. These problems are typically present even if the printer is not a network printer and thus are unlikely to be addressed within PicLan (although this is not written in stone either).
• Print jobs behavior issues like the deletion of hold jobs when they are moved to another system. This is actually a conceptual problem in addition to an implementation problem. PicLan is not a printer. Instead it acts and an agent to transfer jobs from system to system. If hold jobs are not moved, but instead copied, you now have two independent jobs that are actually the same contents. In addition, PicLan's interface into the Pick spooler is quite crude. In essence, the only operations that are implemented are read job, write job, and delete job. Functions to change job status like "the job has been printed" are simply not implemented and would be difficult to implement at the level that PicLan operates and the number of different Pick platforms that PicLan operates on.
• Control functions for DSG and slave/routed printing are obviously needed. These functions are also pretty straight forward to implement, although they will likely require a different user interface than the Pick spooler uses (SP-KILL won't work). The only reason that these are not here now is limited resources and the need to practice walking before running. Remember that these are both relatively new PicLan functions.

How to Implement Some of These Functions Yourself

It is possible to implement some of these functions yourself without involving PicLan. Some of these techniques are crude, and some are quite elegant. The important this is that they are all under your, and not our, control. This is not to imply that these functions will not be added to PicLan in the future, but now is now and these techniques may get you out of a jam.

Killing slave/routed printing

You can use the PL-KILL command to kill the network connection for slave or routed printing thus killing the job. This was never designed to work this way, but does work according to one customer who uses it (we never thought of this). You can also stop the PicLan SERVER-PROCESS with PL-STOP-SERVER, delete the job with PL-EDIT, and then re-start the SERVER-PROCESS with PL-START-SERVER.

Preventing hold jobs from being deleted

This is one of the more common requests, and although difficult to implement, the following procedure can be effective.

In general, implementing this type of function requires that you write a Pick phantom process that periodically "looks" at the spooler and "copies" jobs from one form queue number to another. The first form queue number (the one that the application generated the job under) is not assigned to PicLan and the second form queue number is assigned to PicLan. This allows your user application to control through your own coding how jobs get deleted and moved around. This phantom process must do two main processing operations:

• It must "look" at the spooler to see if jobs are present. You do this by EXECUTEing LISTEQS from within BASIC and CAPTURING the output. Messy, but it works (this is actually how the PicLan SERVER-PROCESS looks at the spooler).
• It must "copy" the job. This is done by executing SP-EDIT and spooling the job to a temporary file. The job can then be re-printed using SP-ASSIGN and RUNOFF (remember that). Again messy, but assuming that the job does not contain binary data that is incompatible with runoff, works well.

As messy as this may sound, it can work. Along the way, one site uses this type of processing to translate control characters for foreign language support.

Happy coding.