Version 126.96.36.199 -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
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
- 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
- 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
- The need for form-feed control allowing the adding and
deleting of both leading and trailing form-feed
- 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
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.