PicLan Internals:

Version -September 19, 1995

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:

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:

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:

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:

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.