Following is a description of the print symbiont developed for the
Apple LaserWriter laser printer.

The print symbiont is designed to run under the VMS operating system
version 4.0 or greater. It controls up to four Apple LaserWriter
laser printers connected to the VAX via a standard terminal port and
null modem cable connected to the 25-pin RS-232 port on the
LaserWriter (9600 baud).

The print symbiont is a full VMS symbiont implementation, and responds
correctly to all print queue functions, such as queue reset, task abort,
etc. Certain functions could not be implemented, as follows:

    a) In general, all form-related capabilities do not function due to
       the nature of the PostScript page description language, putting
       details of such control in the hands of the user. Such things as
       margin settings (from a form definition) are included in this
       limitation.

    b) Use of form setup modules is supported, but currently has no effect
       beyond the job flag and/or file flag pages. This problem may be
       corrected in the future. It is somewhat unclear what usefullness
       this has for this particular type of device. The file setup
       module support provides all the necessary functionality I can
       think of ever needing.

    c) Other form related control features, such as form type, queue
       characteristics, sheet-feed option, etc., are handled directly
       by the symbiont, since VMS does not (I think) provide a means to
       associate a queue with more than one form type. The LaserWriter
       can support two paper sizes (letter and legal), and has a manual
       feed capability available with either paper size.

    d) Detection of where individual pages begin and end is unreliable
       and not supported. As a result, any job reset functions that
       specify restarting the job at a particular page cannot be
       supported. This is risky business even if it were, since output
       for each page may depend on information supplied previous to the
       start of that page.

The symbiont sports the following features:

    a) Job flag, burst and trailer pages are generated by the symbiont,
       if the queue is set up to generate them, or if issued with the
       PRINT command.

    b) Detection of out-of-paper, paper jam and other problems that
       can occur while printing. A message is sent to the print
       operator when such conditions are detected, so that corrective
       action can be taken to clear the condition.

    c) Detection of errors generated by the interpretation of the
       PostScript file. The error, as reported by the LaserWriter, is
       printed on a special trailer page. A dump of the operand stack
       is also generated, appearing on the 'job output' page.

    d) Detection of job output from the PostScript program. All job
       output is printed on special trailer pages.

    e) The print symbiont can be instructed to take special actions
       by using the /PARAMETER switch when printing a file. The
       following options are supported:

       /PARAMETER=MANUAL_FEED

           This specifies that the LaserWriter is to pause for paper
           to be inserted while printing the main file. This does not
           affect flag, burst and trailer pages, which always feed from
           the paper tray. The operator must wait for the yellow light
           to come on before feeding the sheet into the LaserWriter.

       /PARAMETER=FORM:form_type

           Specifies a form type, such as company letterhead, to be
           manually fed. This information is conveyed to the print
           operator prior to the job starting.

    f) Most VMS print symbiont functions, such as recognition of the
       logical name PSM$ANNOUNCE (printed at the top of flag pages)
       are supported.

The symbiont has the following known problems and limitations:

    a) Sometimes a character being output from the LaserWriter is
       dropped. I believe this is due to the inability of the terminal
       communications interface (DZ-11, DMF-32, etc.) to respond quickly
       enough to the data to successfully capture it. There is no
       work-around for this, other than to make sure the LaserWriter is
       connected to your most efficient terminal controller. (This
       seems to only occur on the first print job following LaserWriter
       power-up.)

    b) The symbiont depends upon the type-ahead feature of VMS to
       capture the output from the LaserWriter. If your system has a
       a too-small type-ahead buffer size, problems may develop on a
       loaded system. Also, use of the alternate type-ahead feature
       of VMS is recommended for the LaserWriter port(s). This allows
       a longer warning time for XON/XOFF conditions to be detected.
       If the port is set to /NOTYPE_AHEAD/PERMANENT, then the symbiont
       will set up the alternate type-ahead automatically.

    c) The symbiont is limited to output from the LaserWriter not to
       exceed 199 characters per line. Lines of length greater than
       this are truncated, then continued on the next line (of course,
       lines this long won't fit on one output print line, anyway).

    d) Currently the symbiont will not work if the device is set up
       as spooled. As a work-around to this problem, do not set the
       device as spooled and just use an explicit file specification
       and PRINT command to get the file out (as opposed to using
       /OUTPUT=ddcn: on various VMS commands). The author has tried,
       unsuccessfully, to figure out why this does not work. He
       suspects there is some undocumented trick required to allocate
       a spooled device (ALLSPOOL privilege isn't enough). Currently,
       the error "DEVMOUNT, device is already mounted" is returned if
       the symbiont is started on a spooled terminal.

    e) The print symbiont performs special synchronization functions to
       properly coordinate each print job. To disallow the possibility
       of the job not terminating, a timeout is set up which triggers
       if the LaserWriter does not respond within a certain amount of
       time. There are circumstances where the timeout value used may
       not be sufficient for jobs that have a lot of computing being
       performed in the LaserWriter (it is even possible to deliberately
       put the LaserWriter into an endless loop). The timeout value
       should be adequate for normal print jobs.

       The timeout only works after successful transmission of the
       Control-D character by the symbiont. If the port is locked by
       XOFF from the LaserWriter, and the LaserWriter is in an endless
       loop, the symbiont may lock up on that job. A solution has been
       put into place, but at this point I am not certain that it will
       always work correctly.

    f) The "errordict" dictionary (described in the PostScript
       reference manual) is made read-only by the symbiont. Any attempt
       to modify the dictionary will generate an error.

    g) PostScript names beginning with 'SMB@' are reserved to the print
       symbiont. A small amount of space in userdict is used for
       symbiont-related definitions.

    h) The LaserWriter places paper in its output tray in reverse order.
       This causes flag and trailer page positions to be reversed. Print
       operators should be trained to recognize this anomaly.

    i) Although the symbiont is designed to control multiple LaserWriters,
       it has never been tested with more than one, so there could be
       undetected problems if one were to control two or more with this
       symbiont.

An important note to system managers:

    The symbiont runs with privilege. All print symbionts, when started
    by the Job Controller, have the SETPRV privilege. As a part of its
    initialization process, the symbiont obtains the following privileges:

        TMPMBX
        ALLSPOOL
        SHARE
        READALL

    Normally, there should not be a problem with these privileges.
    However, since the symbiont has SETPRV, anything is possible.
    Prior to installing this on your system, you should assure
    yourself that the supplied executable matches the supplied source
    code (re-compilation and linking is the preferred approach). The
    author of the symbiont is also a system manager, and understands the
    caution required when installing software that runs with privilege
    when the source of the software is unfamiliar. Furthermore, the
    author can control the software only as far as the input to the
    DECUS program library. Since modification is possible by any
    intermediary, the author recommends that anyone proposing to install
    this software conduct a review to ensure that the software operates
    as described.
