Columbus Output Management

I N T E L L I G E N T • S Y S T E M S • M A N A G E M E N T
Columbus Output Management

Introduction
UQCA-4500-00 Columbus OM 4.5

Publication number Trademark acknowledgements
UQCA-4500-00 (December 2005) Product and company names mentioned herein may be the
trademarks or registered trademarks of their respective
owners.
Documentation set
The documentation relating to this product includes:
License information
■
Introduction
Copyright © 2005 Macro 4. All rights reserved.
■
How to install Columbus OM
This publication, as well as the software described in it, is
■
How to configure Columbus OM furnished under license and may be used or copied only in
■
How to use Columbus OM accordance with the terms of such license. The information
in this publication is furnished for informational use only, is
■
How to use the command line interface subject to change without notice, and should not be
■
How to use the uq menu interface construed as a commitment by Macro 4. Macro 4 assumes
no responsibility or liability for any errors or inaccuracies
■
How to integrate with SAP R/3
which may appear in this publication.
■
Technical Reference
Except as permitted by such license, no part of this
publication may be reproduced, stored in a retrieval
Making comments system, or transmitted, in any form or by any means,
electronic, mechanical, recording or otherwise, without
We welcome suggestions from all users regarding our
prior written permission from Macro 4.
software products and their accompanying documentation.
Please contact your local Macro 4 representative, email us
at tech.authors@macro4.com, or write to:
Technical Documentation
Macro 4
The Orangery, Turners Hill Road,
Crawley, West Sussex RH10 4SS
United Kingdom
www.macro4.com
3
Contents
Introduction UQCA-4500-00
About this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapter 1 Columbus OM and your environment . . . . . . . . . . . . . . 7

Using single and multiple instances of Columbus OM . . . . . . . . . . . . . . . . . . . . . . 8
Columbus OM queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapter 2 Setting up Columbus OM . . . . . . . . . . . . . . . . . . . . . . . 11

Using a single Columbus OM instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Using multiple instances on a host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Communications between components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Multiple host computers and instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 3 Accessing Columbus OM . . . . . . . . . . . . . . . . . . . . . . . 19

Columbus OM Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Columbus OM web interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Command line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
uq menu interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Chapter 4 Configuring the print environment . . . . . . . . . . . . . . . 23

Document handling capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Servers used for printing documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Local printing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Distributed printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Setting up printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Printer features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Monitoring the status of printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Enhancing printed documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Chapter 5 Controlling documents with the dispatch features . . . 35

Document handling capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Columbus OM dispatch facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

4 CONTENTS
Chapter 6 Other output channels . . . . . . . . . . . . . . . . . . . . . . . . . 39

Faxing documents with Columbus OM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Using Columbus OM to email documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Webpublishing documents with the Columbus OM webserver . . . . . . . . . . . . . . 45
Chapter 7 Event logging and monitoring . . . . . . . . . . . . . . . . . . . . 47

Recording events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Responding to actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Chapter 8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

First level security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Controlling access to Columbus OM functions. . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Authorized user groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Group security for printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Document and destination security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Chapter 9 Integrating Columbus OM with other applications . . . . 55

Integration with other Macro 4 applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Integration with third-party applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

5
About this manual
Introduction UQCA-4500-00
This manual provides an overview of how to implement a Columbus OM output

management system. It describes the features of Columbus OM, how they work,
and how to use them.
This manual assumes you are familiar with your operating system and that you
have access to information about your network.

6 About this manual ■

7
CHAPTER 1
Chapter 1 Columbus OM and your

environment
This chapter describes:

■
‘Using single and multiple instances of Columbus OM’ on page 8
■
‘Columbus OM queues’ on page 9

8 CHAPTER 1 ■
Columbus OM and your environment ■
Using single and multiple instances of Columbus OM
Using single and multiple instances of

Columbus OM
You can install single or multiple instances of Columbus OM.
A single Columbus OM instance

In a basic system, one instance of Columbus OM controls one or more printers. To
access the instance to add documents and monitor their progress, you can use
Columbus OM Explorer, the Columbus OM web interface, and the command line
interface.
For more information, see ‘Using a single Columbus OM instance’ on page 12.
Multiple Columbus OM instances on a host

You can run two or more instances of Columbus OM on the same computer. This
might be useful to:
■ keep printers that serve different groups of users (for example, some in the
Accounts department and some in Sales) separate
■
spread the workload on a heavily used system.
Each instance has its own queues, folders and servers, enabling them information to
be kept separate. However, the instances are usually configured so that they can
communicate with each other if necessary.
For more information, see ‘Using multiple instances on a host’ on page 13.
Multiple Columbus OM print instances on a network

In a more complex system, you can have Columbus OM instances on different
computers that communicate with each other across the network.
This enables you to use both the printers that are controlled by your local instance,
and the printers that are controlled by remote instances, even if they are thousands
of miles away.
You send your document to the local instance of Columbus OM; Columbus OM
transfers the document across the network to the remote instance; and then the
remote instance prints it. It sends status information back across the network so that
you can monitor its progress.

CHAPTER 1 ■
Columbus OM queues
9
Columbus OM queues
Columbus OM stores the entries that it processes in queues. Columbus OM gives
each entry a number to identify it.
■ The pending queue contains entries that are waiting to be processed.
■
The completed queue contains entries that Columbus OM has finished
processing (whether successfully or not).
■
The archive queue contains entries that have been stored after Columbus has
finished processing them. The archive queue is optional; you can also either
delete entries or transfer them to another application, for example
Columbus DW.
Columbus OM automatically moves entries between the queues automatically.
You can also move and delete entries manually.
Managing queues
When you install Columbus OM, you have to specify the size of the queues, that is
the maximum number of entries that you want to be in a queue at once. The size of
the queues affects the disk space that they occupy; even if there are no entries in a
queue it occupies the same space as if it was full.
Managing the pending queue

The pending queue must be large enough to hold all the entries that may be
submitted to Columbus OM in a period that it takes to process them.
If the pending queue is full when you try to add an entry, Columbus OM rejects the
entry. You can configure the pending queue to extend automatically so that you
can always add new entries.
Managing the completed queue

The completed queue is usually much larger than the pending queue (for example,
five times as large) because entries tend to accumulate.
If the completed queue is full when Columbus OM tries to move an entry to it from
the pending queue, the entry stays in the pending queue (with its status set to
“Completed” to indicate that Columbus OM has finished processing it).
You can configure the completed queue to delete entries that have finished
processing automatically, or to move them to an archive queue.
Managing the archive queue

The size of the archive queue is controlled by Columbus OM. It automatically
extends if necessary.
Usually, there are several archive queues to store the entries for a specific period
(for example, daily, monthly or quarterly). Choose a naming convention to
accommodate this, for example:

10 CHAPTER 1 ■
Columbus OM queues
\usr\ColumbusOM\archive2000.Q1
Disk storage considerations

The Columbus OM program files require very little disk space. The space used by
the queues containing copies of documents is much more significant, and this
amount depends on how many jobs and the size of documents that the instance
processes. 100 jobs at an average size of 25,000 bytes per job uses approximately
2.5MBytes. Each queue needs approximately 1K per entry for the maximum
number of entries.

11
CHAPTER 2
Chapter 2 Setting up Columbus OM
The topics covered here are:

■
‘Using a single Columbus OM instance’ on page 12
■
‘Using multiple instances on a host’ on page 13
■ ‘Multiple host computers and instances’ on page 17
■
‘Using multiple instances’ on page 17.

12 CHAPTER 2 ■
Setting up Columbus OM ■
Using a single Columbus OM instance
Using a single Columbus OM instance

The simplest Columbus OM system uses a single instance. The instance controls
the processing of documents. It accepts requests from users, works out what to do
with the documents, and then passes them onto a device to output them.
When you install a single instance system, most of Columbus OM is already
configured for you. All you have to do is add the printers that you want it to
control; Columbus OM can search your network for printers, and add their basic
configuration to your system.
Accessing the instance

To access the instance, you can use one of the Columbus OM interfaces, for
example, Columbus OM Explorer. You can install Columbus OM Explorer on the
same computer as the instance (if it is a Windows computer), or on a different
computer (if the two computers can communicate with each other).
The interfaces and the instance communicate by using Columbus OM’s
communication service (uniqcs) and its uqserver program.
Single instance on a single host and one communication service

to talk to Columbus OM Explorer
Columbus OM uniqcs uqserver Instance1

Explorer (port 2006)
PC HostA

CHAPTER 2 ■
Using multiple instances on a host
13

Multiple instances can be run on the same host.
Each instance runs separate copies of the servers that it needs (for example,
printmaster and the printer servers), except for uqserver (the communications
server). Usually, you need only one copy of uqserver running on a host, however
many instances there are.
Examples of using multiple instances

This section shows different ways in which multiple instances may be used. The
most usual choices are Examples 1 and 4.
1 Enabling instances to share resources
Simple setup, everything shared.
2 Preventing instances from communicating
Shared incoming communication, but instances do not know about each other.
3 Hosts with multiple TCP/IP addresses
Multiple addresses (network cards), shared incoming communication service.
4 Keeping incoming requests separate
Separate incoming communication services.
Enabling instances to share resources

To enable resources to be shared between two or more instances on the same host,
you:
■
make sure that each instance knows about the other instances by listing them in
its systems file (systems.tab)
■
make sure that all the instances use the same communication service (as
defined in uqserver and in the services file) for incoming requests
■
run only one copy of uqserver.
This enables uqserver to direct each incoming request (from Columbus OM
Explorer, the command line or a remote instance) to the appropriate instance.
Multiple instances on single host and shared communication service and defined in
each other’s systems table so they can talk directly to each other
Instance1
incoming requests
uniqcs uqserver talking to
instance
(port 2006) each other
HostA
Instance2

14 CHAPTER 2 ■
Preventing instances from communicating

To prevent two instances from communicate with each other, remove the
references to each instance from the other instance’s systems.tab file.
The instances can still use the same uniqcs service and uqserver to receive
incoming requests, but they cannot receive requests from each other.
Multiple instances on single host with the same communication services

but not defined in each other’s system tables
Instance1
uniqcs uqserver not

incoming requests
(port 2006) communicating
HostA
Instance2
Hosts with multiple TCP/IP addresses

Where a host has more than one TCP/IP address, a shared uqserver can be set up
to intercept all incoming requests regardless of address.
Multiple instances on single host with multiple host addresses, shared

communication services and not defined in each other’s system tables
multiple Instance1
incoming requests addresses
for address1
uniqcs uqserver not
incoming requests (port 2006) communicating
for address2
Local host
0.0.0.0 Instance2

CHAPTER 2 ■
15
Keeping incoming requests separate

To keep incoming requests for two or more instances on the same host separate,
you can run two or more uqserver programs, each listening on a different port.
You also keep the instances separate by not defining them in each other’s
systems.tab file.
Multiple instances on single host, separate communication services and

not defined in each other’s system tables
Single host
uniqcs1
incoming requests uqserver Instance1
(port 2006)
uniqcs2
incoming requests uqserver Instance2
(port 2007)

16 CHAPTER 2 ■
Communications between components
Communications between components

Columbus OM instances communicate with each other, and with the user
interfaces which send requests (for example, Columbus OM Explorer), by using a
server called uqserver. This accepts incoming requests on a specific port number.
The port number is assigned a service name, usually uniqcs.
uqserver performs these tasks:
■
enable an Columbus OM interface to communicate with the instance
■
receive requests sent from other host
■
receive acknowledgement signals and non-acknowledgement signals (ACKs
and NAKs) from remote systems when these are issued.
Each instance has its own uqserver, but you can run only one uqserver program
for each port number. When you start the first instance on a host, it start its
uqserver. When you start another instance on the same host that uses the same
port number, it uses the first uqserver. You can start another uqserver only if it
uses a different port number.
uqserver configuration
uqserver requires minimal configuration. uqserver should be configured to use a
communication service name. The name is is usually uniqcs, but you could choose
a different name. It must match with an entry in the services file.
Multiple addresses for a host

If the host has more than one TCP/IP connection, then each instance could be
addressed at the IP level but doing this would be unusual. Typically uqserver is
configured to accept all host addresses by forcing it to communicate on only one
address: 0.0.0.0.
This configuration setting should be the same for all uqservers defined for a host,
because only one can run at any one time for each port number and it may not
always be the same one that starts, although ideally you should decide which one is
to start automatically and set all the others not to start automatically.

CHAPTER 2 ■
Multiple host computers and instances
17

In a system with multiple host computers, each with one or more Columbus OM
instances, the instances can communicate by using these Columbus OM servers:
uqserver and netmaster.
HostA
incoming uniqcs1
uqserver csuniq Instance1
requests for Port 2006
HostA
netmaster
HostB
netmaster
incoming
requests for uniqcs2
HostB uqserver csuniq Instance2
Port 2007
Communication csuniq is a program used by uqserver when a remote process such as netmaster
between hosts: transfers an entry to uqserver.
csuniq csuniq needs to be specified in the system defaults for client mode and also for the
ACK_Command for individual printer configuration when status feedback is not
being used.
Communication uniqcs is a service that enables:

between hosts ■
an interface to communicate with a host
and PCs: uniqcs
■ and print instances to communicate with each other.
uniqcs must be specified as a service in the services file on every computer in the
system.
Choosing a port number

uniqcs listens for requests on a specific port number. All communication between
Columbus OM components should use the same port number. The exception
would be if you want to exclude an instance or user interface from communication
with a particular instance by using a different number.
Using multiple instances
Account name
If you install two or more Columbus OM instances on the same host, it is
preferable that the same user account name, for example uniq, is used for owning
all the instances.

18 CHAPTER 2 ■
Instance names
Each instance must have a different name, for example Print01, Print02, Print03
and so on, or Sales, Accounts, Admin and so on.
Instance folders
Each instance must be installed in a different folder; the most efficient method is to
put each instance in a separate subfolder under a main Columbus OM folder.
Distributing entries across instances: the netmaster server

netmaster controls the sending of requests to remote systems. It performs these
functions:
■
monitor the local pending queue for entries to be processed by a remote
instance, and transfer those entries to the remote instance
■
send acknowledgments to a remote system when status feedback is not being
used and a print request completes or fails and the printer server cannot send
them
■
automatically switch to an alternative remote host if the preferred system is
inaccessible (failover operation)
■
maintain and distribute a list of known printers on remote systems.

19
CHAPTER 3
Chapter 3 Accessing Columbus OM
This chapter describes the interfaces that enable you to access Columbus OM.
Interface Description See
Columbus OM Explorer Windows interface page 20

Columbus OM web interface Web browser interface page 21
Command line interface Operating system command line page 22
interface
uq menu interface UNIX terminal interface page 22
UNIQ OUTPUT MANAGEMENT SYSTEM ARCHITECTURE

20 CHAPTER 3 ■
Accessing Columbus OM ■
Columbus OM Explorer
Columbus OM Explorer
Columbus OM Explorer enables you to access Columbus OM instances from a
Windows computer. You can access one or more instances at once.
Columbus OM Explorer provides access to almost every Columbus OM function,
including:
■ adding, changing and deleting entries and tracking their progress
■
configuring servers and printers
■ starting and stopping servers
■
enabling, disabling, pausing and resuming printers
■ controlling security.
The security features enable you to control which of these functions can be
accessed by each user.
For more information about using Columbus OM Explorer, see the How to use
Columbus OM manual.

CHAPTER 3 ■
Columbus OM web interface
21
Columbus OM web interface

The Columbus OM web interface enables you to access Columbus OM instances
and monitor and control entries by using a web browser. You can:
■ track the progress of entries in the pending and completed queues
■
delete entries; put entries on hold and release them; and resubmit entries
■ display information about entries, including displaying the contents of a
document.
■ display the pending and completed queues for devices
■
disable and enable devices; and pause and resume devices
■ display information about the features that devices have, and how the devices
have been configured.
There are some functions that the web interface does not provide: for example, you
can not add new entries to a queue, and you can not change the configuration of
printers and servers.

22 CHAPTER 3 ■
Command line interface
Command line interface

You can control Columbus OM by typing commands at the operating system’s
command line interface. Columbus OM commands can be used in your own
scripts and batch files.
For example, this queue management command submits a file called myreport
with a remark of ‘This is a test’ to be printed on a printer called Accounts:
apq myreport -at accounts -rt 'This is a test'
The commands that are available include commands to:

■
manage and control entries, queues, servers and printers
■
search for printers on the network, and add them to Columbus OM
■
integrate Columbus OM with SAP R/3.
For more information about the commands, see the How to use the command line
interface manual.
The command line is available on only the same computer as the Columbus OM
instance.
uq menu interface
(Available on UNIX.)
The uq menu interface enables you to administer and operate Columbus OM from
a character-mode terminal.
For more information about configuring and using the uq menu interface, see the
How to use the uq menu interface manual.

23
CHAPTER 4
Chapter 4 Configuring the print

environment
A Columbus OM print instance controls printers and manages the printing of

documents according to priority and printer availability.
This section contains information about these features:
■
‘Document handling capabilities’ on page 24
■
‘Servers used for printing documents’ on page 25
■
‘Local printing’ on page 26
■
‘Distributed printing’ on page 27
■
‘Setting up printers’ on page 31
■
‘Printer features’ on page 32
■
‘Monitoring the status of printers’ on page 33
■
‘Enhancing printed documents’ on page 34

24 CHAPTER 4 ■
Configuring the print environment ■
Document handling capabilities

Supported formats
Columbus OM can accept documents in any format; some formats it can handle
directly; other formats have to be converted to enable Columbus OM to handle
them.
Columbus OM can directly handle these formats:
■
ASCII (unformatted text)
■
HTML
■
PCL
■
PDF (Adobe Acrobat document)
■
PostScript
■
AFP.
To handle other formats, they must be converted to one of these formats before
they can be submitted to Columbus OM. For example, to print a document that is
Microsoft Word format, you could print it to a file that is in one of the accepted
formats (for example, PCL or PostScript), and then you can submit that file to
Columbus OM.
Standard features
A Columbus OM print instance has these features, which are common to all types
of Columbus OM instance:
■
Priority management: Jobs with a higher priority are processed before those
with a low priority.
■
Deferred processing: Jobs can be held for processing until a specified date and
time.
■
Job dependencies: The processing of a job can be made dependent on another
job; Columbus OM starts processing the second job only when the first job has
completed.
■
Event handling: Specific actions can be performed in response to events such
as jobs completing successfully, failing, or being postponed.

CHAPTER 4 ■
Servers used for printing documents
25
Servers used for printing documents

These servers enable Columbus OM to print documents (these are in addition to
the servers that are used for communication between components):
printmaster: Handling print requests

printmaster monitors the queue for entries with a medium of PRINT, and then
sends them to the appropriate printer server. This server is created when you install
Columbus OM. Each Columbus OM instance should run one copy of printmaster.
printer servers: Controlling printers

A printer server sends documents to a printer. Create and run one printer server for
each printer that you want to use with Columbus OM. Usually, one printer server
corresponds to and represents one printer, but it is possible to control the same
printer in different ways by assigning two or more different printer servers to it.
The printer server uses a driver to control the printer. There are different drivers
for different types of printer. The most powerful is xprinter:
xprinter: Enhanced printer driver

xprinter is an enhanced printer driver. It can be used with specific types of printer,
and provides additional functionality.
statserver: Monitoring printer servers

statserver monitors the status of printer servers, and (optionally) integrates
Columbus OM into an SNMP network management environment. To use this
functionality, run one copy of the server.
lpdserver: Intercepting the lpd daemon

lpdserver makes Columbus OM’s printing facilities available to users on hosts that
do not have a Columbus OM print instance installed, but are able to issue remote
lp requests. The server ‘listens’ on lpd’s socket for lpd requests and translates them
to Columbus OM requests. There can be only one lpdserver per host because it
uses only one port number, 515.
ftserver: File transfer

ftserver server communicates with computers that do not have a Columbus OM
print instance installed, but do have the ability to transfer files to a machine that
does. ftserver monitors a directory looking for work to print.

26 CHAPTER 4 ■
Local printing
Local printing
Local printers are controlled by the instance to which the user is logged on and
where the job is submitted. Printers can be physically attached, or network
connected, or addressed using a modem.
Overview
1 You add an entry to Columbus OM.
2 Columbus OM puts the entry in the pending queue.
3 The pending queue is scanned at regular intervals by printmaster for entries
that are to be processed by printers that are controlled by the current instance.
4 When printmaster finds an entry, it sends the entry to the printer server that
controls the printer that you have specified.
5 The printer server sends the entry to the printer.
6 When the entry has been completed, Columbus OM moves it to the completed
queue.
incoming requests
uqserver printmaster
scans the queue for printmaster starts the printer

entries for printers server
pending controlled by this
Printer server PrinterA
queue entry1 instance
entry2 pserv1
...
all pending entries for PrinterA
are processed by the printer
completed server which disappears when
queue entry1 printing is finished
entry2
when printed, the request is
... transferred to the completed queue

CHAPTER 4 ■
Distributed printing
27
A Columbus OM print instance can control printing across a network of printers
that are controlled by other Columbus OM instances. This section describes the
environment and what you need to consider to set it up.
Overview
1 A user submits an entry to Columbus OM.
2 Columbus OM adds the entry to the pending queue.
The pending queue is scanned by netmaster for entries that are to be
processed by remote printers, that is printers that are not controlled by the
current instance.
3 When netmaster finds an entry for a remote printer, it transfers it to the
instance that controls that printer.
4 When the entry arrives at the remote instance, it is picked up by that instance’s
uqserver, and the entry is processed by the instance as if it were a local entry
(see ‘Local printing’ on page 26).
Tracking the progress of an entry

Information about the progress of the entry can be monitored by using the status
feedback feature. In addition, if the SFCache server is running, status messages are
cached.
Where the status feedback mechanism is not in use, or has failed for some reason
such as a host has failed, netmaster can detect ACKs and NAKs from remote
printers and send these to the originating host’s uqserver so the originating
instance can tell if a print has succeeded or failed.
In addition, an action on completion/action on failure mechanism is available,
whereby a user-proved script or program is called to handle a print completion or a
failure to print.

28 CHAPTER 4 ■
Remote printing
netmaster looks at pending

entries for remote prints
netmaster Remote host
pending uqserver printer

queue server
entry.1234 entry.5678 pserv2
..... copies the entry to the ..(1234)
remote instances’s
PrinterA
pending queue
completed entry.5678
queue entry.1234 ..(1234)
notifies the original host moves to
that the entry has completed queue
..... completed ..... after printing
For requests to remote printers, the network print scheduler netmaster scans the
queue and works out where print requests should be sent. It looks for the
destinations in remote.tab. The following diagram shows the flow of
communication between servers:
incoming requests
(uniqcs) uqserver gives the

netmaster uqserver
job to csuniq to
csuniq update the queue
remote.tab HostA should have a printmaster

remote.tab
identifying the host
where printerA is Printer document
attached server
pserv2
PrinterA
uqserver netmaster netmaster will send

back any ACKs and
HostA HostB NAKs from the
status feedback
print instance print instance printer if status
command
feedback fails
If status feedback has been configured, the printer program will attempt to return
entry statuses either directly or through the status feedback caching server,
uqsfcache, which caches the status feedback for efficiency reasons. If status
feedback is not configured, the printer program will queue a special entry called an
ACK or a NAK and netmaster will deliver this entry back to the originating host
when it can.
Spreading the workload

On busy systems, you can spread the workload by creating one more new print
instances. This works well where there is an even mix of different sized documents.

CHAPTER 4 ■
29
If large documents are being transferred to remote instances, the workload can be
spread by defining two or more netmaster servers. Configure each netmaster server
to process documents of specific sizes (for example, one to process documents of
100 pages or less, and one to process documents of more than 100 pages).
Defining remote printers

There are two ways that you can tell netmaster where the remote printers are:
■
remote printers list
The remote printers list contains the name of each printer, the host that they
are on, and the Columbus OM instances that controls them. From this,
netmaster works out its own route to the printer. Alternatively you can specify
the route that it is to use:
■
route definitions list
The route definitions list contains the full route (that is the DNS host name and
print instance) to each printer.
Maintaining the remote printer definitions

To use a remote printers list, you have to maintain only one copy of this list in one
specific instance, and you configure netmaster to distribute it to the other instances
in the system.
The remote printers list is not affected by changes to the network.
If you use a routes table, each netmaster server uses it to build its own remote
printers table.
Defining remote hosts

netmaster can transfer print requests to any accessible remote host system which is
running a Columbus OM print instance. (netmaster will know about remote hosts
using the installation-allocated host names and TCP/IP addresses.)
Optionally, you can specify extra information about remote hosts in the netmaster
hosts table. You can specify:
■
an alternative “failover” host, to be used if the remote instance cannot be
accessed
■
the maximum allowable delivery rate (in characters per second) when
transferring a queue entry to the remote host to avoid swamping the system
■ commands to compress and uncompress document files while they are
transferred to the remote host.
Enabling hosts and users to access a print instance

To enable access to a Columbus OM print instance, use the trusted hosts file,
cshosts.tab. The file controls:
■ which users can access the instance from Columbus OM Explorer and
■
which host systems that are running netmaster can transfer print requests to
this instance for remote printing

30 CHAPTER 4 ■
■
which host systems and login ids can be used for printing from ColumbusZ.
The file contains a list of host computers, and an associated list of users who can
access the print instance from that host. If the file does not exist for an instance, all
users are able to access the instance from any host.
The file does not control requests which are made directly, such as by using the apq
command.
Each instance can have its own trusted hosts file, enabling different users to access
different instances.

CHAPTER 4 ■
Setting up printers
31
Setting up printers
For each printer that you want to use with Columbus OM, you must set up a
printer server. The printer server tells Columbus OM information such as where
the printer is, the formats that it can print, and how you want it to operate.
To use the same printer in different ways, you can set up two or more printer
servers to control it.
Information needed to set up a printer server

To use a printer with Columbus OM, you must provide the information that
enables Columbus OM to connect to it and control it. Information that you need
includes:
■ how the printer can be accessed by Columbus OM (for example, if it is
connected to the network or to another computer)
■ its properties (for example, what languages it supports and the number of paper
trays)
■
what control codes the printer accepts to select paper trays, fonts, and so on
■
how it can provide information about its status
■
requirements for specific stationery for any print jobs.
Setting up printers
To set up printers, you can use these methods:
■
automatically scan the network for printers, and create a configuration file that
can be loaded into Columbus OM.
■
manually create a configuration file for one or more printers that can be loaded
into Columbus OM
■
provide all the information manually
■
set up one or more generic printer types, and then use them as the basis for
other printers.
Email or fax documents

In addition to printing documents, you can configure a printer server to send
documents by email, either as a message or as an attachment.
A printer server can be configured to transfer a fax document to a fax instance. This
is mainly used when faxing from SAP R/3.

32 CHAPTER 4 ■
Printer features
Printer features
Printer types
Printers defined in a Columbus OM print instance can reference a printer type as a
quick way of defining the printer attributes.
A printer type is a “family” of printers that have a common set of attributes such as
escape sequences, fonts, paper orientation, finishing, and so on. (for example, “HP
LaserJet”, “Xerox Laser” or “PostScript”). Columbus OM includes some basic
printer types that you can use, either as they are, or as the basis for your own
printer types.
Printer connection types

For each printer you need to define the method of connection:
Description of connection Type name
A printer that is directly attached to a serial or parallel port on the Device

local host
A printer that is on the network and that can be connected to by TCP/IP
specifying a host name and a port number
A printer that is on another host running an lp daemon, or has a LPR/LPD
network card that emulates the lpd protocol
A command into which the document is piped Command
A printer connected to a dial-up modem attached to a serial port or Modem
a terminal server using a network card
A printer that uses the advanced printer protocol such as XPP XPrinter
Paper types for special stationery

If stationery control is important, such as certain documents must print on invoice
paper and others as cheques, then you can create paper type definitions which can
be associated with specific printers, or with specific documents when they are sent
to print. Documents for a specific paper type will not print until the operator signals
that the paper type is loaded in the printer.
For each paper type there are several attributes, such as: page length; single-sided
or double-sided printing, stapling.
An alternative to pre-printed stationery is to use overlays or forms: see ‘Applying
overlays and forms’ on page 34.

CHAPTER 4 ■
Monitoring the status of printers
33
Monitoring the status of printers

Columbus OM can check the status of a printer at regular intervals, for example to
find out if it has been switched on, check if it has run out of paper and so on. This
information is used internally; it can also be directed to an external program such
as HP OpenView or IBM’s Network Node Manager.
■
If the printer is able to respond to SNMP (Simple Network Management
Protocol) status requests, see ‘Checking the status by using SNMP’ below.
■
If the printer is not able to respond to SNMP status requests, you can use one of
Columbus OM BackChannel commands or one of its own commands. See
‘Checking the status by using BackChannel commands’ below.
Checking the status by using SNMP

The status of printers can be checked by using SNMP. Information includes error
messages from printers, authentication failures and general changes in the
configuration.
This functionality is provided by Columbus OM’s statserver server. It polls
specified printer servers to get printer status. Any online program can then request
statserver for information by issuing the backstat command.
For more information, see the How to configure Columbus OM manual.
Checking the status by using BackChannel commands

For printers that cannot respond to SNMP status requests, BackChannel commands
can be used check their status. It may get back a response such as “Cover open”.
Use SNMP in preference to BackChannel commands where possible, because
SNMP is faster.
Checking status using PJL

For printers that support Printer Job Language (PJL), the Columbus OM pjlout
driver can be use. PJL enables status feedback to be requested from the printer, on
a per page basis if necessary. This is often useful for secure printing where the status
of each page has to be monitored, for example, when printing cheques.
Running operating system commands when a document is

processed
You can run an operating system command at the various stages of printing a
document, for example:
■
when a document is completed
■
when a document is started
■ when a document fails
■
while a document is being processed
■ when a document is postponed.
If a problem occurs, you can tell Columbus OM what you want it to do. For
example, if a printer runs out of paper in the middle of a document, you can tell it
to print the rest of the document on a different printer by running a command.

34 CHAPTER 4 ■
Enhancing printed documents
Making better use of printers

To make more efficient use of printers, you can create groups of printers called
printers classes. In a printer class, you put similar printers, for example, all the
printers in one office. When you send a document to a printer class instead of a
specific printer, Columbus OM selects the first printer in the group that is available.
(Printer classes are different to printer groups, which control what a user can view.)
Enhancing printed documents

Changing the document: Using input filters
You can change the format of a document by using an input filter. Input filters are
programs or shell scripts that are run before a document prints on a certain printer.
Examples of using input filters include:
■ Validate print data: You can create your own program or script for validation
of data to check print data, and cause the print to fail if the data is not
acceptable for use with Columbus OM.
■ Change document orientation: To change portrait-format documents to
landscape or landscape-format documents to portrait, Columbus OM includes
an input filter called rotate.
■
Change font size: To change the font size in a document, you can use the
rotate filter.
■
Print plain text on PostScript printers: If a printer supports only PostScript, you
can print a plain text document on it by using the input filter that is supplied
with Columbus OM.
Applying overlays and forms

Some documents need to be printed on stationery that has a fixed image onto
which the document data is printed. For example, the data for invoices is variable
and is what would be contained in the document waiting to print. This data needs
to be printed on a form which has the same layout for each page of the invoice
data.
The overlay files, or forms, can be created using a graphics package or
word-processor. The first page in the overlay can be different to the rest of the
pages. Complex double-sided multi-form overlays can be defined as well as simple
single-sided forms, restricted only by the capabilities of the printer.
Printing banner pages

Banner pages to be printed in front of documents can be applied.
The banner page can include control characters (escape sequences) to control the
printer, for example, to print the banner page on paper from a different tray than
the document itself. For information about escape sequences, see the printer’s
documentation.

35
CHAPTER 5
Chapter 5 Controlling documents

with the dispatch
features
The Columbus OM dispatch features provide an additional level of control over

documents. They enables you to process requests differently according to the
contents of the documents or some of the options that have been selected.
For example, you can:
■ make sure that all documents printed by users in a particular department are
printed on their printer
■ redirect documents sent to a printer that is unavailable to a different printer
■
put long documents on hold so that other documents can be printed first
■ combine separate documents into a single item or print only selected pages
from a document
■
control documents according to the text that they contain
■
process documents with multiple servers (for example, print an entry, fax it,
and then archive it).
Processing documents with a dispatch server

To use a dispatch server, you create a set of rules that identify which documents
you want it to process, and what you want to do with those documents.
To use different sets of rules, you can set up multiple dispatch servers, each with its
own set of rules.
One dispatch server is created and configured for you when you install
Columbus OM. To configure it to match the requirements of your installation, see
‘Columbus OM dispatch facility’ on page 37.
Using the dispatch server

Users add entries to the Columbus OM print queue with the medium of the entry
set to match the medium of the dispatch server they want to use. The dispatch
server works out if the entry is affected by its rules, and then processes it
appropriately.

36 CHAPTER 5 ■
Controlling documents with the dispatch features ■

Document analysis
Document analysis examines the properties of a document (for example, how
many pages it contains and whether it is black-and-white or colour). Columbus OM
can then select a suitable device to process the document.
Document bundling
Document bundling collects together a number of source documents, over a period
of time, to form a new document or bundle. The source documents are submitted
as discrete dispatch tasks with the task attributes set to identify the document as a
bundle component. Once created, the bundle is added as an entry in the pending
queue.
Bundles are treated by the Columbus OM dispatch facility as documents in their
own right and may be processed in the same manner as any other document entry
in the queue. Actions may be applied to the bundle to print the document, either in
its complete state or split into different views. Once all actions are complete, the
bundle entry is passed to the completed queue.
Document splitting
Document splitting extracts predefined sections or views from a specified
document without affecting the original document. Document splitting may be
applied to any pending dispatch task, including document bundles.
A view is defined by page numbers, or by the appearance of a specified text pattern
at a particular location in the document. A view could be a single page or the whole
document. Multiple views can overlap.
Document dispatch
The dispatch of a document is performed by executing a command, most
commonly printing it. The method of printing is determined by the dispatch server,
which you can customize. The method may be a call to a Columbus OM print
instance, or other print-management utility, or to the UNIX lp command.
Other available functions include:
■ Ensure that all documents printed by a department are printed on a printer in
that department.
■
Redirect documents sent to a printer that is out of order to a different printer.
■
Put long documents on hold so that other documents can be printed first.
■
Check the text of the document and act according to whether it is correct or
not.

CHAPTER 5 ■
Columbus OM dispatch facility
37

The dispatch features are provided by these components:
■
a dispatch server, which processes the dispatch tasks as they are submitted to
the queue
■
a rules file, which determines how tasks are processed: bundling, splitting, and
so on
■
area description files which define areas of text, such as a specific character
string on a page, and which have an associated rule in the rules file.
Overview
You add a document to the queue, with its medium set to dispatch.
The queue is monitor for entries by the dispatch server. When it finds one, it
applies the rules to the entry, for example, to create a bundle, or to split the
document.
It can also change the medium of the entry, and put it back in the queue for further
processing. For example, it could extract a page, change the medium to PRINT,
and then put the entry back in the pending queue as a “new” entry, which will this
time be processed by the server that is set up to handle “PRINT” entries (that is,
usually printmaster).
Bundling and splitting: the flow of operation
DISPATCH queue
Source
documents Pending entries
pending entries: completed
in a folder entries
submitted to Entries
queue marked for
bundling
completed
bundle being entries completed
built bundle
document
original
for splitting
document
Printer
or Print
management
Split documents
utility

38 CHAPTER 5 ■
Rules and area descriptions

The system rules file and associated area description files determine how the
dispatch instance operates. The file content will be directly derived from your
document handling and distribution requirements and will usually evolve as your
needs change.
For more information about rules and area description files, see the How to configure
Columbus OM manual.

39
CHAPTER 6
Chapter 6 Other output channels
This section describes how to use other output channels that are included with
Columbus OM:
■
‘Faxing documents with Columbus OM’ on page 40
■
‘Using Columbus OM to email documents’ on page 44
■
‘Webpublishing documents with the Columbus OM webserver’ on page 45

40 CHAPTER 6 ■
Other output channels ■
Faxing documents with Columbus OM

Columbus OM provide centralized control of fax communications, both outgoing
and incoming. It processes queue entries in a user-defined order, unlike
conventional fax processing systems where the entry at the head of the queue has to
be dealt with first.
Sending faxes
To send a fax, you prepare the document and submit to Columbus OM in the same
way as a document for printing.
Supported document formats

Columbus OM can send documents that are in these formats: ASCII, HP PCL5,
and PostScript. Other formats may be valid depending on the fax modem.
Documents can be converted to one of the supported formats before submitting
them to Columbus OM.
Enhancing documents
You can add these enhancements to faxed documents:
■ Coversheets (a standard single page that may contain information such as the
name of the recipient) can be added at the front of each document.
■ Banner lines, including information such as your company name, fax number,
and the current date and time, can be added to the top of each page.
■ Overlay graphics can be superimposed on transmitted pages. Each graphic
design is held in its own file in T4 fax format.
■
Graphics such as logos or signatures can be embedded in the message text.
■
A confirmation copy of every outgoing fax can be printed automatically.
■
Insert line numbers, change the margins, and change the fonts.
Fax features
■ Automatically redirect documents alternative fax numbers.
■
Prevent specific numbers from being used.
■ Define shortform numbers.
■
Least-cost faxing to transfer documents to a Columbus OM fax instance closer
to the destination fax number before transmission (for example, a fax for an
overseas fax number could first be transferred to a Columbus OM fax instance
in the destination country, and then transmitted.
■ Industry-standard automatic retry sequence, if the document cannot be
transmitted immediately (for example, if the destination is engaged, or the
connection breaks in mid-transmission).

CHAPTER 6 ■
41
Receiving faxes
Incoming faxes are placed in the fax instance’s queue and then distributed to
appropriate recipients, or actioned in other ways, such as printed.
■
Documents received can be converted from the fax format that the modem
handles (usually T4) to a format that is suitable for viewing.
■
Documents can be automatically distribution distributed to the recipient.
■ Automatic printing of received documents.
Components of a Columbus OM fax instance
user input
host
outgoing fax
user
document
interface
files
uqserver
fax modem
faxmaster: fax
fax
fax server
management telephone
queue
server for
system
incoming
fax
faxes
server
fax modem
faxprint:
incoming fax
fax print
document files
server
print output
How Columbus OM sends faxes

1 You add an entry to Columbus OM, specifying the message file and
destination, and set its medium to FAX.
2 The fax servers scan the queue for FAX entries.
The first fax server that finds an entry that is waiting to be processed, processes
it.
3 The fax server connects to its associated fax modem, dials the destination
number, transmits the document, and then closes the connection.
If the server fails to connect to the modem, or is unable to reach the
destination, the job is retried periodically.
4 When the fax server has sent the document, it moves the entry to the
completed queue.

42 CHAPTER 6 ■
How Columbus OM receives faxes

1 A fax server which has been configured to handle incoming faxes monitors its
associated fax modem periodically.
2 When an message is received, the server stores it in a file, then adds an entry to
the fax instance’s queue. The entry specifies the job’s message file and source,
and has a medium of FAX_IN.
3 The queue is continuously scanned for eligible FAX_IN entries by the
faxmaster server. faxmaster compares the source telephone number with the
entries in sender.tab, to determine how the message is to be distributed.
4 If the message is to be copied to a given folder or directory, faxmaster makes
the copy, and then marks the entry as Completed.
5 If the message is to be printed, faxmaster re-queues the entry with a medium
of FAXPRINT.
6 The queue is continuously scanned for eligible FAXPRINT entries by the
haslerpr server, which handles the printing and then marks the entry as
Completed.
Interfacing with other Columbus OM instances
Interfacing with other fax instances

A fax instance does not usually network in the same way as a print instance,
because it does not usually matter from which modem a fax is sent (whereas it does
matter where a document is printed). It is only in an international network where
least-cost faxing might be used (see ‘Least-cost faxing to transfer documents to a
Columbus OM fax instance closer to the destination fax number before
transmission (for example, a fax for an overseas fax number could first be
transferred to a Columbus OM fax instance in the destination country, and then
transmitted.’ on page 40), that fax instances communicate with each other.
in New York in Hong Kong

entry modem with
HostA transferred to HostA lowest call cost
telephone system
remote fax to destination

instance
fax instance fax instance

status returned status
netmaster netmaster
uqserver uqserver
Communication between the fax instances is controlled by the netmaster and

uqserver servers.
Interfacing with print instances

Print instances can transfer fax documents to a fax instance.

CHAPTER 6 ■
43
This configuration enables faxes to be sent from SAP R/3, which can interface with
a Columbus OM print instance. (A Columbus OM fax instance cannot interact
directly with SAP R/3.) A document is submitted to SAP R/3; SAP R/3 transfers
the document to the print instance; and then the print instance transfers the
document to the fax instance.
The fax instance process the fax, and then returns the status to the print instance so
the sender can see what has happened.
entry
HostA transferred HostB
telephone system
to fax fax modem
instance
print fax
instance instance

status status
returned
Servers used by fax instances

A Columbus OM fax instance uses these servers for handling fax documents. (It
also uses the communication servers.)
Connecting to fax modems: pfax, haslerfx, and faxbox servers

These servers connect to specific types of fax modem. They monitor the queue for
entries with a medium of fax, and then transmit those entries. Create and run one
copy of one of these servers for each fax modem that you use.
Server Modem
pfax Ascom Hasler AM2496F and US Robotics Class 2

haslerfx Ascom Hasler HFU Class 3
faxbox D&CE Faxbox and Faxbox 30
Processing incoming faxes: faxmaster

Incoming faxes are handled by the faxmaster server. For more information, see
‘How Columbus OM receives faxes’ on page 42.

44 CHAPTER 6 ■
Using Columbus OM to email documents
Using Columbus OM to email documents

An extension of the printing facility allows documents to be emailed to one or more
users. A single file can be transmitted or a number of files can be sent.
Overview
The email facility is designed to be used to process bulk document delivery using
the Columbus OM command line interface, for example, to send a document to a
mailing list of email addresses.
The basic components of the Columbus OM email facility are:
■
The ability to send messages to multiple addresses.
■ The ability to send multiple attachments.
■
The ability to monitor the progress of the message using the standard
Columbus OM queue monitoring facilities.
user
application
email + attachments)
print
queue
mail
mailer server
completed
queue
www
The mailer server monitors the queue for entries whose medium is mail, and then
submits these entries to the mail server (for example, Microsoft Exchange) for
delivery.

CHAPTER 6 ■
Webpublishing documents with the Columbus OM webserver
45
Webpublishing documents with the Columbus OM

webserver
The Columbus OM webserver posts documents to a folder where they can be
accessed by using a web browser.
Overview
This suite of programs consists of two main components: the webserver and the
Web Channel.
■
The webserver detects documents that are submitted to the Columbus OM
queue with their medium set to WEB. It copies the document to a central area.
It can optionally send an email message to selected users, to notify them that
the document is available for viewing.
■ The Web Channel is used to navigate to the central area, where the user can
examine the contents of the directory and display documents they are
interested in. The Web Channel can be accessed from any web browser such as
Microsoft Internet Explorer.
In addition to posting the documents as they are, the contents can be converted to a
different format.
print incoming fax

document queue document web Web Channel
files collection
SMTP mail

46 CHAPTER 6 ■
Webpublishing documents with the Columbus OM webserver

47
CHAPTER 7
Chapter 7 Event logging and

monitoring
This section describes some of the methods by which you can monitor the status of
the components of the Columbus OM system. See:
■
‘Recording events’ on page 48
■
‘Responding to actions’ on page 48

48 CHAPTER 7 ■
Event logging and monitoring ■
Recording events
Recording events
Information about events (for example, starting a server or adding a new one) can
be recorded for subsequent viewing and analysis.
The information can be either recorded in a file, or broadcast as SNMP (Simple
Network Management Protocol) traps for collection by another application.
Statistical data logging for print instances

Statistical data logging is a subset of event logging, and can record the occurrence
of specified events. The extra data logged contains:
■
the specific action that has occurred within the print instance
■ the UID of the queue entry to which it relates
■
a timestamp
■ details of the user who initiated the action
■
selected other data relevant to the action.
Responding to actions
You can specify operating system commands to be issued when a certain action is
taken or detected by a server program.
For example, you can configure a print server to issue a command when it starts
printing a document like this:
echo Printing document %UID at %TIME
To use this feature, use the servers’ Action_On parameters.
Some examples of when commands can be issued

■
For netmaster: When a print or fax request has been moved to the completed
queue.
■
For printmaster: When an entry is found to be blocked, for example because
the wrong paper is mounted on the printer.
■
For printer servers: When starting to print a document.
■
For faxmaster: When starting to process an incoming fax document.
■
For fax servers: When starting to send a fax.

49
CHAPTER 8
Chapter 8 Security
To ensure that users can access only the functions and data that they are authorized
for, Columbus OM includes extensive security features that can be implemented at
different levels. See:
■
‘First level security’ on page 50
■ ‘Controlling access to Columbus OM functions’ on page 51
■
‘Authorized user groups’ on page 52
■ ‘Group security for printers’ on page 53
■
‘Document and destination security’ on page 53

50 CHAPTER 8 ■
Security ■
First level security
First level security

For Windows operating systems
Ensure that the Columbus OM security system is made secure against any user who
has knowledge of Windows. You may already have a security setup into which
Columbus OM can be incorporated.
Set the Columbus OM folders’ permissions (by using the Properties dialog box) so
that only authorized users can update the Columbus OM Explorer security files.
For UNIX operating systems

Ensure that the Columbus OM security system is made secure against any user who
has knowledge of UNIX. Decide on a list of users allowed to modify
Columbus OM security files at UNIX level.
The ownerid for Columbus OM should be uniq, and this should be a member of
group uniqgrp.
Access to a host running Columbus OM

Ensure that all individual users and groups of users who need to access a
Columbus OM instance are allowed to access the host. Users can either be remote
from or local to the host.
To specify the host computers and users that can access an instance, use the trusted
hosts file, cshosts.tab.
Access to Columbus OM from Columbus OM Explorer

To access Columbus OM Explorer, users have to enter a user name and password.
Columbus OM can validate the user name and password against one of these:
■
the operating system’s user names and passwords
■ a list of user names and passwords that are specific to Columbus OM
■
(if you are using Columbus OM with SAP R/3) the SAP system’s user names
and passwords with SAP R/3.
Access to a Columbus OM instance from the command line

interface
Access to the command line interface corresponds to the operating system security.
Columbus OM enables you to control access to individual commands and
functions. See ‘Controlling access to Columbus OM functions’ on page 51.
Access to a Columbus OM instance from the uq menu interface

Access to the uq menu interface corresponds to the operating system security.
Columbus OM enables you to control which functions within the uq menu
interface can be accessed. See ‘Controlling access to Columbus OM functions’ on
page 51.
Access to a Columbus OM instance from the web interface

Access to the web interface is password-protected. You can maintain passwords
from within the interface.

CHAPTER 8 ■
Security ■
Controlling access to Columbus OM functions
51
Controlling access to Columbus OM functions

Security authorization
For commands and functions that you want to control access to, include them in
the security table. (For commands and functions that you want all users to be able
to access, exclude them from the security table.)
The security table also controls which users can change who can access each
command or function.
Security table access control file administration

commands for command: group name
Enable a printer Enable a printer Members in the groups
. can update this access
. control file
.
.
.
Disable a printer access control file administration
etc for command: group name
Disable a printer Members in the groups
can update this access
control file
Enabling users to access a controlled function

For each Columbus OM function that you have included in the security table, you
can specify a list of users who you want to be able to use it. The list is stored an
access control file.
access control file

for function
Enable a printer
Columbus OM validates
function against the file for the function userid = John
Enable a printer .
.
group name = Accounts
.
.
■
If there is no control file for a function, no one can use the function.
■
If the file exists but it is empty, everyone can use the function.
■
If the file exists and it contains a list of users, only the users who are in the list
can use the function.
For more information, see the Technical Reference.

52 CHAPTER 8 ■
Security ■
Authorized user groups
Authorized user groups

To make the lists of users in the security file and access control files easier to
maintain, you can create groups of users, and then add individual users to the
appropriate groups. Changing the access rights of a user group automatically makes
the same changes to the access rights of each member of the group.
Supplied user groups

Columbus OM includes three groups of users who have access to commands and
functions. From lowest level to highest level, the groups are:
■
operators
Operator can control queue maintenance, printer, and fax operations, on a day
to day basis
■
administrators
Administrators have overall responsibility for the running of the system.
■
implementors
Implementors have the authority to configure the system. (The implementors
group automatically includes the user who owns Columbus OM, uniq by
default, and the user who installed Columbus OM.)
Users who are not in any of these groups can perform only basic functions.
You can also create your own user groups.
Co-operative working
Entries submitted to the queue by a user are owned by the user group of which the
user is a member. This means that any member of the user group can control the
entry, for example to change its properties or delete it.
Teams
Teams are a special form of user group. Team members can treat only their own
entries and entries belonging to the team as their own, they cannot treat entries
belonging to other members of the team as their own.
Team: Accts Queue

all members see
this one
Members: Entry owned by Accts
Fred
Rick
Sam Entry owned by Sam
this one seen
only by Sam
In this example, Fred, Rick, and Sam can see entries for team Accts, but only Sam
can see entries owned by herself. You must choose between using user groups or
using teams: they cannot be used together on the same instance.

CHAPTER 8 ■
Security ■
Group security for printers
53
Group security for printers

To control who can use and control printers, create printer groups.
Printer groups affect which entries are shown on a queue display. For example, if
you send a document to a printer that is a member of printer groups A and B, then
the entry can be seen in the queue by only users who have access to those printer
groups.
Display by printer group is a global option for each instance; if you use this feature,
you must add every printer to at least one printer group. If a printer is not in any
printer groups, its entries are displayed only if you also allow users to view only
their own entries.
Document and destination security

To control the actions that users can perform on individual documents, you can
apply a security level for a document when you submit it. The security level
controls what users can do with the document. For example, the security level may
prevent other users from displaying its contents, changing its properties, or even
seeing that it is in the queue. Different groups of users can be given different access
rights.
Default security levels can be specified to be applied to all documents that are
processed by a specific server or sent to a specific destination.
These features are in addition to the existing security features that control access to
documents.

54 CHAPTER 8 ■
Security ■
Document and destination security

55
CHAPTER 9
Chapter 9 Integrating Columbus OM

with other applications
This section describes how Columbus OM can be integrated with other

applications to extend its role in your output management and document
processing system.
Integration with other Macro 4 applications
Columbus DW A document warehousing, data analysis and

presentation product which allows rapid retrieval of
archived documents and viewing in the original format.
See ‘Storing documents in a data warehouse with
Columbus DW’ on page 59.
Columbus Central A workflow processing application for handling
complex document processing structures.
Columbus OM can print documents that are submitted
to it by Columbus Central.
See ‘Printing documents from Columbus Central’ on
page 57
Columbus OM Prints directly from a Windows application to a printer
Windows Gateway that is controlled by Columbus OM, by creating a
printer port that intercepts the Windows Print Manager,
and prints directly to a Columbus OM instance.
See ‘Printing documents from Windows to
Columbus OM’ on page 58.
ColumbusZ OPEN A feature of ColumbusZ, Macro 4’s enterprise print
management product, that interfaces with
Columbus OM to provide cross-platform printing.
See ‘Cross-platform printing with ColumbusZ’ on
page 61.
Columbus OM Novell Provides a bi-directional gateway between
Gateway Columbus OM and Novell NetWare.
See ‘Using Novell Netware printers with Columbus OM
Novell Gateway’ on page 60.

56 CHAPTER 9 ■
Integrating Columbus OM with other applications ■
Integration with third-party applications

■ ‘Integrating Columbus OM with SAP R/3’ on page 63
■
‘Integrating Columbus OM with Oracle’ on page 65
■
‘Integrating Columbus OM with datastream processing applications’ on
page 65
■ ‘Integrating Columbus OM with file archiving applications’ on page 66

CHAPTER 9 ■
57

This diagram shows how Columbus OM can be integrated with other Macro 4
applications.
Using printers directly connected

to PCs
Columbus OM Cross-platform
print instance printing with
(Windows or ColumbusZ:
UNIX) Mainframe running
OS/390
Print from
Windows: Columbus OM
Windows Explorer
TCP/IP Gateway
Columbus OM Novell Gateway

Columbus Central
on a Novell Server
IPX/SPX LAN
Printing documents from Columbus Central

Columbus Central uses Columbus OM as its output channel for printing
documents.
Task plans created by using Columbus Central can include steps to print
documents as part of the workflow (along with steps for almost any other document
process). When a task reaches the “print” stage of its task plan, Columbus Central
submits the document to Columbus OM, and Columbus OM returns information
about the status of the document to Columbus Central. The status can be
monitored from the Columbus Central web interface; the integration of
Columbus Central and Columbus OM is transparent to users.
For more information about configuring Columbus Central to use Columbus OM,
see the Columbus Central documentation.

58 CHAPTER 9 ■
Printing documents from Windows to Columbus OM

To print directly from a Windows application to a printer that is controlled by
Columbus OM, use the Columbus OM Windows Gateway.
Windows host
myfile Print command

dummy
port Columbus OM
printer
The Columbus OM Windows Gateway implements a class of printer port, similar

to the LPT local ports.
You define a dummy printer that uses the port. You can then use the Print
command of any Windows application to send output to the dummy printer. The
port passes the output to Columbus OM, and adds it to the pending queue.
Columbus OM then process the document in the same way as any other entry.
Set up the Windows Gateway and the dummy printer on the same host as the
Columbus OM instance, and then make the printer available from other computers
by using the Windows sharing features.
Windows host defined as

shared
dummy
printer port Columbus OM
Print command
Windows host
myfile
dummy
network
printer
Using printers directly connected to PCs

To use printers that are directly attached to PCs, use the Columbus OM PC Printer
Channel. The PC Printer Channel means that any PC-attached printer can be
added to your printer network so existing equipment can be better used. Reports
generated on a host can be printed on any printer that is directly attached to a PC.
The PC Printer Channel can run on any PC running Windows.

CHAPTER 9 ■
59
TCP/IP
host PC
PC Printer Windows
Columbus OM
Channel Print Manager
PC printer
A user submits a job for printing in Columbus OM. Columbus OM transfers the
data to the PC Printer Channel on the PC by using a TCP/IP connection. When
the data has been transferred, Windows Print Manager is invoked to service the
print request, and the job is recorded as “Completed” in Columbus OM.
As well as TCP/IP access, you can also define LPD/LPR access to a printer. A print
server needs to be defined in Columbus OM relating to each PC printer that is to
be accessed.
Two or more printers that are attached to the same PC can be managed by
installing a PC Printer Channel to control each one.
Storing documents in a data warehouse with Columbus DW

For longterm storage, documents can be transferred to an archive in
Columbus DW, Macro 4’s data warehousing application. Documents can be
submitted to Columbus OM specifically for transfer to the archive, or the archiving
process can be made an additional step that is automatically applied to documents
that are printed, faxed or sent by email by using Columbus OM.

60 CHAPTER 9 ■
Using Novell Netware printers with Columbus OM Novell

Gateway
The Columbus OM Novell Gateway provides access to Novell Netware printers
from Windows or UNIX hosts running Columbus OM. It can also send output to
Columbus OM.
host
Columbus OM
TCP/IP
NetWare
server Columbus OM
Novell Gateway
IPX/SPX
Novell
PC
Netware Netware
printer printer
Columbus OM Novell Gateway is a Network Loadable Module (NLM) named

uqserver, residing on any Novell Netware File Server which is accessible using
TCP/IP. Columbus OM Novell Gateway acts as a bi-directional gateway between
Columbus OM and Novell Netware. It allows users to address printers on a
Netware network with no application or procedural changes required.
■
uqserver ‘listens’ on a nominated TCP service for print requests sent from a
Columbus OM instance running on a Windows or UNIX host. When a request
is received, the print job is added to a NetWare print queue.
■
uqserver monitors one or more NetWare print queues and transfers jobs from
those queues to a Columbus OM instance.
In both cases, uqserver sends an acknowledgement back to the originating host,
telling it if the document printed successfully.

CHAPTER 9 ■
61
Cross-platform printing with ColumbusZ

Cross-platform printing enables the two-way transfer of reports between
ColumbusZ on OS/390 and Columbus OM on Windows or UNIX. Connection is
made by using only TCP/IP or both TCP/IP and SNA.
This diagram shows TCP/IP connection only:
data can flow either way
ColumbusZ
communications TCP/IP Columbus OM

server
(COMMSERV)
If the connection is made with VTAM/SNA using APPC LU6.2 then the
OPEN SNA interface is required as shown in this diagram:
data can flow either way
ColumbusZ
SNA APPC
communications TCP/IP Columbus OM
LU6.2
server OPEN SNA
(COMMSERV) interface
The OPEN SNA interface converts SNA addresses to IP addresses and vice versa.
OPEN SNA can send to more than one Columbus OM print instance but can
communicate with only one ColumbusZ instance. If you need to communicate with
more than one, then install another copy of OPEN SNA.
Users can:
■
submit print requests directly from Columbus OM to ColumbusZ
■ direct print requests from ColumbusZ to a Columbus OM printer. Where
multiple Columbus OM print instances are interconnected, reports can be
routed to other instances using Columbus OM’s distributed printing facility.
Format conversion
Data transferred from ColumbusZ to a Columbus OM print instance is converted
from EBCDIC to ASCII, so that it can be interpreted by the network printers. Data
transferred from Columbus OM to ColumbusZ can be converted from ASCII to
EBCDIC by the communications server COMMSERV.
Sending a report to Columbus OM

Submit a file to ColumbusZ. For the destination, specify the name of the printer
that is set up to transfer documents to Columbus OM. ColumbusZ handles the
Columbus OM link as though it were a directly connected TCP printer, so escape
tables, forms flash, FCBs and job separators are processed in the same manner as
for any other printer, although they may not be interpreted by Columbus OM.

62 CHAPTER 9 ■
If the Columbus OM print instance cannot find a matching printer, it can try other
instances for a suitable printer where distributed printing has been set up.
Columbus OM to ColumbusZ communication

ColumbusZ uses its communications server (COMMSERV) to listen to
Columbus OM. Connectivity occurs by starting one or more servers, each one
being responsible for managing connections of a specific type, one of which is
Columbus OM via TCP/IP.
Any number of Columbus OM print instances can communicate with ColumbusZ
using its Communications server providing they transmit on the same port.
Sending a report to ColumbusZ

A file can be sent to ColumbusZ using the Columbus OM Explorer or the
Command line interface command apq. The user issuing the command must be
defined as a valid ColumbusZ user id as well as a Columbus OM user id.
ColumbusZ will return a message indicating the success or failure of the transfer of
the report.
Where will it print?

ColumbusZ usually manages reports by class and several printers might service a
specific class, which means that a report could be output on any one of those
printers.

CHAPTER 9 ■
63

This section describes how Columbus OM integrates with third-party applications.
Integrating Columbus OM with SAP R/3

Columbus OM has been certified and validated by SAP as a Complementary
Software Program (CSP) that can be integrated with R/3 via the official BC-XOM
interface.
Integration is available in two forms: basic access method ‘L’ or more powerful
access method ‘E’. You need to choose which method to use. The Columbus OM
print instance must be on the same host as R/3.
Access method ‘L’ integration
SAP R/3
lp command
emulation
Columbus OM
printers defined as
access method ‘L’ in R/3
Access method ‘L’ uses lp and lpstat command line integration using
Columbus OM’s lp and lpstat emulation.
■
Each printer known to R/3 must be configured as access method ‘L’ device in
R/3.
■ Columbus OM lp command must be specified as the R/3 print command.
When submitting a print job from R/3, the Columbus OM lp command is issued.
When R/3 needs to enquire on the status of a job, it issues an lpstat command.
Access method ‘E’ integration using SAP’s Device Polling and

Command Line interface
The functionality provides:
Job submission R/3 attributes such as title and R/3 owner are supported.
Attributes are mapped onto the most appropriate
Columbus OM Explorer attribute.
Job tracking Print jobs can be tracked from within R/3. All information
regarding a print job’s status is reported back to R/3.
Device status The current status of a Columbus OM print device can be
displayed from within R/3.

64 CHAPTER 9 ■
Job cancel Print jobs can be cancelled from within R/3.
SAP/R3
Columbus
OM SAP
logical logical logical
command
OMS OMS OMS printers defined
definitions
as access method
‘E’ in R/3
real OMS Columbus O
OMS = Output Management System
Columbus OM is the real Output Management System (OMS). One or more

logical OMS must be defined.
The R/3 commands used are SUBMIT, DPOLL, and CANCEL. These are mapped to
Columbus OM equivalents. These definitions are held in a file which is referenced
by R/3 and all the associated LOMS.
When defining each LOMS, its commands can be configured for just that LOMS,
for example the CANCEL command can be disabled for a LOMS, or commands can
be directed to a Columbus OM instance other than the ROMS.
Faxing from SAP R/3

SAP R/3 can create fax documents which can be received by a Columbus OM
print instance on the same host as R/3. Columbus OM can transfer these
documents to any networked Columbus OM fax instance according to a
destination number table. The fax instance returns the status when the fax has been
processed.
Set up Columbus OM and R/3 to communicate using SAP’s Device Polling and
Command Line Interface. Jobs can then be submitted from R/3 to the
Columbus OM print instance. Using the callback interface the Columbus OM fax
instance returns the status of jobs to R/3.
netmaster in Columbus OM to enable the print instance to communicate with the
fax instance.
If specified by the user, R/3 includes the fax destination dialling number when
sending to the Columbus OM fax instance. If omitted, then the number defined as
default in the printer configuration file is used.

CHAPTER 9 ■
65
Integrating Columbus OM with Oracle

Oracle-based applications can specify Columbus OM commands to assign report
attributes to Oracle-generated documents. Alternatively, Oracle output generated
via the UNIX lp command can be directed for processing by Columbus OM.
Another method is for the Oracle application to create a file of the document and
then for the host to transfer the document to the Columbus OM host for processing
by ftserver.
Oracle host Columbus OM

Columbus OM
command
Oracle
application
UNIX lp command
ftserver
create a file
document
file
Oracle printer
Financials configuration
feature
As well as using the methods described above, Oracle Financials also contains a
printer configuration feature that can be modified to pass reports to
Columbus OM.
Integrating Columbus OM with datastream processing

applications
Columbus OM can handle documents and datastream input generated by an
application such as SAP R/3. When Columbus OM receives datastream input, it
passes the datastream to a datastream processing application, such as StreamServe.
This formats and splits the datastream into individual documents, which are then
returned to the Columbus OM print queue.

66 CHAPTER 9 ■
datastream generator
application
datastreams
Columbus OM multiple child entries
DCS
queue
server
datastream processing
application
datastreams split and formatted
How it works
Datastream input requires special handling in Columbus OM. For each datastream
input, a master entry is added to the queue. This entry is detected by
Columbus OM’s Document Composition Server (DCS) as it monitors the queue.
The DCS passes the datastream to the external application, where it is formatted
and split into individual documents, called child entries. These are then submitted
to the Columbus OM print queue and processed as normal documents.
The progress of each master entry and its associated child entries is monitored and
its status is returned to Columbus OM, and to the originating datastream generator
application.
Integrating Columbus OM with file archiving applications

Columbus OM can pass documents marked for archive to an archiving application.
See also ‘Storing documents in a data warehouse with Columbus DW’ on page 59.
requests for archive input from sources

such as Columbus OM Explorer, uq
menu, command line, and SAP R/3
Columbus OM
ASP server queue file to

archive
queue entry points to
the document
file archiving application

CHAPTER 9 ■
67
How it works
Each queue entry that is marked for archiving is detected by Columbus OM’s
Archive Server Process (ASP) as it monitors the queue. It then passes the associated
document to the file archiving application. It ignores entries for remote queues
because these are transferred using netmaster to their appropriate destination.
The progress of each entry is monitored and status feedback is returned to
Columbus OM.

68 CHAPTER 9 ■

69
Index
A Columbus OM WebClient 21
security 50
access control file 51
Columbus OM Windows Gateway 58
accessing Columbus OM 19
ColumbusD Transfer 61
security 49, 50
ColumbusZ
account names 17
description 55
ACK signals 16
integration with 61
acknowledgement signals 16
security 30
administrators
command line interface 22
adding 52
overview 22
user groups 52
security 50
archive queue 9
communication between instances 16
managing 9
communication service 17
area description files 38
completed queue 9
managing 9
B connecting to printers 32
BackChannel commands 33 cross-platform printing 61
banner pages 34 cshosts.tab file (trusted hosts) 29
bundling documents 36 csuniq program 17
C D
Columbus Central 57 data warehousing 59
Columbus DW datastream processing applications
integration with 59 integration with 65
Columbus OM dcs servers 66
accessing 19 deferred processing 24
configuration 7 destination security 53
integration with ColumbusZ 61 disk storage space 10
Columbus OM Explorer dispatch features
description 20 overview 35
overview 20 dispatch instances
security 50 area description files 38
Columbus OM Novell Gateway 55 overview 37
integration with 60 rules files 38
Columbus OM PC Printer Channel dispatch servers 36
integration with 58 multiple 35

70 Index
overview 35 instances
using 35 accessing 12
dispatching documents 36 communication between 16
distributed printing 27 multiple 8, 13
document composition servers 66 names 18
document formats 24 single 8, 12
converting 34 integration with other applications 55
fax instances 40 Macro 4 applications 57
document handling 24, 36 SAP R/3 63
document operations third-party applications 63
bundling 36 interfaces 19
dispatch 36
splitting 36 J
document security 53
job dependencies 24
documents
validating 34
L
E landscape to portrait 34
least-cost faxing 40
electronic forms flashing 34
using SAP R/3 64
email messages 44
local printing 26
sending 44
lpdserver server 25
event handling 24
event logging 48
M
F Macro 4 applications
integrating with 57
failover system 29
mail messages 44
fax instances
mailer server
communicating with other instances
42 overview 44
overview 40, 41 multiple folders
servers 43 account names 17
faxing documents 40 locations 18
file archiving applications multiple instances 13
integration with 66 security 30
filters 34
font size N
changing 34 NAK signals 16
forms for documents 34 names
ftserver server 25 instances 18
netmaster server
G description 18
group security for printers 53 netmaster servers 18
network communications 17
between hosts 17
H between hosts and PCs 17
haslerfx server 43 port numbers 17
hosts non-acknowledgement signals 16
access 50 Novell Netware printers 60
multiple host system 17
O
I operators user group 52
implementors Oracle
user group 52 integration with 65
input filters for printing files 34 overlays for documents 34

Index
71
P S
paper types 32 SAP R/3
passwords 50 access methods 63
pending queue 9 datastream processing 65
managing 9 integration 63
pfax server 43 least-cost faxing 64
PJL (printer job language) sending faxes 43
status information 33 security 49
port numbers access to functions 51
choosing 17 documents 53
portrait to landscape 34 hosts 50
PostScript printers levels 52
printing plain text 34 operating system level 50
preprinted stationery 32, 34 printers 53
print instances 23 trusted hosts and users 29
overview 23 user groups 52
security 50 user interfaces 50
printer classes 34 sending faxes 40
printer servers 25, 31 process 41
printer types 32 servers
printers ftserver 25
connection types 32 haslerfx 43
defining 31 lpdserver 25
directly connected 58 pfax 43
group security 53 printer 25
overview 26 printmaster 25
paper types 32 statserver 25
printer types 32 xprinter 25
status information 33 SFCache server 27
printmaster servers 25, 26 single instance 12
priority management 24 SNMP integration 33
privileges 52 for printer status information 33
special stationery 32
Q splitting of documents 36
statistical data logging 48
queues
statserver 25
managing 9
statserver servers 33
overview 9
status feedback mechanism 27
status information 33
R StreamServe 65
receiving faxes 41 system examples 8
process 42 system security 52
remote hosts 29 systems.tab file 13
remote printers list 29
remote printing 28 T
remote.tab file 28
teams 52
resource sharing 13
trusted hosts
rotate filter program 34
description 29
route definitions list 29
TTY interface 22
rules (dispatch server)
description 35
rules files 38 U
uniqcs 12, 16
UniQLaser
integration with 61

72 Index
UNIX
menu interface See uq menu interface
security 50
uq menu interface
description 22
security 50
uqserver 12
shared 13
uqserver servers
communication between instances 16
configuration 16
shared 14
uqsfcache server 28
user groups 52
privileged groups 52
teams 52
user interfaces 19
security 50
users
types of 52
W
web browser interface 21
Web Channel
description 45
functionality 45
WebClient 21
webserver
description 45
functionality 45
Windows
interfaces 20
printers 58
security 50
X
xprinter
configuration parameters 25

I N T E L L I G E N T • S Y S T E M S • M A N A G E M E N T
www.macro4.com

Columbus Output Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Columbus Output Management

Uploaded by

Copyright:

Available Formats

I N T E L L I G E N T • S Y S T E M S • M A N A G E M E N T

Columbus Output Management

UQCA-4500-00 Columbus OM 4.5

About this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 1 Columbus OM and your environment . . . . . . . . . . . . . . 7

Chapter 2 Setting up Columbus OM . . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 3 Accessing Columbus OM . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 4 Configuring the print environment . . . . . . . . . . . . . . . 23

Chapter 5 Controlling documents with the dispatch features . . . 35

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Chapter 6 Other output channels . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 7 Event logging and monitoring . . . . . . . . . . . . . . . . . . . . 47

Chapter 8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

Chapter 9 Integrating Columbus OM with other applications . . . . 55

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

About this manual

This manual provides an overview of how to implement a Columbus OM output

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Chapter 1 Columbus OM and your

This chapter describes:

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Using single and multiple instances of

A single Columbus OM instance

Multiple Columbus OM instances on a host

Multiple Columbus OM print instances on a network

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Managing the pending queue

Managing the completed queue

Managing the archive queue

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Disk storage considerations

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Chapter 2 Setting up Columbus OM

The topics covered here are:

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Using a single Columbus OM instance

Accessing the instance

Single instance on a single host and one communication service

Columbus OM uniqcs uqserver Instance1

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Using multiple instances on a host

Examples of using multiple instances

Enabling instances to share resources

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Preventing instances from communicating

Multiple instances on single host with the same communication services

uniqcs uqserver not

Hosts with multiple TCP/IP addresses

Multiple instances on single host with multiple host addresses, shared

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Keeping incoming requests separate

Multiple instances on single host, separate communication services and

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Communications between components

Multiple addresses for a host

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Multiple host computers and instances

Communication uniqcs is a service that enables:

Choosing a port number

Using multiple instances

COLUMBUS OUTPUT MANAGEMENT INTRODUCTION

Distributing entries across instances: the netmaster server