 |
Description  |
|
|
This invention relates to the automated management of a complex environment
and more particularly to the efficient retrieval of data spread throughout
a large object-oriented database.
CROSS REFERENCE TO THE RELATED APPLICATIONS
Several patent applications filed concurrently herewith relate to the
invention herein. They are patent application Ser. No. 08/334,810
entitled, "Table Driven Graphical user interface"; patent application Ser.
No. 08/334,584 entitled "Desktop Management of Host Applications"; and
patent application Ser. No. 08/334,948 entitled "client Network
Interface".
BACKGROUND OF THE INVENTION
The desire to develop control technologies in order to produce end-products
more efficiently, or more cheaply, or of higher quality has existed for
many years. Machines utilizing mechanical controls, hydraulic controls, or
pneumatic controls were developed in the eighteenth century. With the
advent of electrical technology, the increased ability to control the
movement of work pieces from one work station to another down conveyor
lines enabled a significant advance in the cost, efficiency and quality
objectives of control technology. With the development of computers,
particularly general purpose computers, control technology became much
more flexible. Improvements in the control of a process could be effected
by changes in software, as opposed to changes in hardware which were
necessary on the earlier systems. Also, computer technology brought about
the ability to automate processes not previously subject to machine
control. For example, accounting work that was previously done by hand
with the aid of simple adding machines or other calculating devices of
that sort were automated by computerized systems to produce end-products
in a much more efficient and less costly manner. The preparation of
documents has been automated to some extent by the use of word processors.
Generally speaking, computers have enabled the automation of information
processes much the same as in an earlier day the electrical technology
enabled the automatic movement of work pieces down a conveyor line.
The continued development of semi-conductor technology has enabled enormous
computing capacity in very small computing elements. As a result,
microprocessors have found use within machinery as control elements,
replacing cams and gears and relays and other such devices of the previous
control technologies. As a result the flexibility of programmed
microprocessor is now available in many types of equipment. With
microprocessor control of machines so pervasive, there occurs the need
that various types of equipment in a work process be tied together and
report to various processors which can manage the overall operation.
Management may occur at the process level, i.e., to send a work piece from
one work station to another and perform the operations called for, and it
can occur on an information level as well, i. e., for example, processes
can acquire information about machines so that they can be maintained
prior to a breakdown, processes can schedule jobs, maintain inventories
and automatically perform other accounting functions.
The particular complex environment in which the current invention was
developed is the large mail room operation. In such an operation a variety
of documents must be printed, fed along conveyor lines for correlation
with other documents to comprise the particular mailing, through devices
which may trim the documents, fold them, place them in envelopes and place
them on trays. The envelopes will have a printed address so that a
weighing mechanism may determine the postage that is needed and place the
postage on the envelope. There are machines to sort mail according to zip
codes and by walk sequence, i.e., the sequence that a mail carrier will
follow delivering mail along a particular route. Finally, the outputs may
be boxed according to the location to which they are sent and delivery
automatically ordered for the next airplane leaving for that location.
In the large mailroom, information about recipients might be included in a
database. For example, certain mailings may go to those people who are
known to enjoy golf and other mailings may go to people who are in the
dental profession. Some mail room operators may wish to track the
effectiveness of marketing promotions. For example, people in a certain
area might be targeted to receive a discount on an item and coupons for
those people would receive a certain bar code. Another area might receive
a different discount and have a different bar code. Later, once the
coupons are returned, data relating the amount of interest developed by
the promotion can be accumulated by reading the bar codes and
automatically producing the reports.
As may be observed from the above description the amount of data which is
organized in large mail room operations is enormous. It is not unusual for
these operations to include banks of computers, banks of data storage
equipment, various types of printers from many different manufacturers and
complex inserting equipment capable of merging documents from several
paths into one stack, folding, cutting, inserting, franking, sorting, and
packaging.
In the current environment marks may be placed on the paper in a certain
location so that scanning those marks can trigger the correct operation to
direct that particular paper along its route to its destination in the
proper envelope. Such marks can be on each page of a document or they can
be on header pages. Such marks might require the trimming of a document
before it is actually sent out to a customer.
FIG. 1 shows a simplified configuration that is utilized at the current
time in print mail room facilities. The print job originates with
application processes on a host 16 which is typically a large mainframe
computer, making use of database facilities attached to the host. The
generated print stream is converted into a device specific data stream and
sent to the controller 11A of printer 11 for production of documents. An
unwinder mechanism 10 is used to unwind rolls of paper and feed the paper
into the printer 11. The printer output is passed to a folding machine 12
and organized on trays 13. The tray 13 is moved manually to provide input
to a second line of machinery which may include devices to cut and trim
the stacks of paper into individual documents and feed the documents
through an inserting machine 14. Inserting machines are complex devices
under the control of a microprocessor based controller 14A. The inserter
may also receive documents from other document feeding devices and
envelopes from another printing source for inserting the proper group of
documents into a properly addressed envelope. The envelope may then pass
through a franking machine and through sorting apparatus before being
placed on trays 15 from which the properly sorted mail is packaged and
sent off to the Post Office. An important advantage of the configuration
as shown in FIG. 1 is that the printer line is separated from the inserter
line of machinery. As a consequence the problems of matching the speed of
these two lines is eliminated and printers are not held up by the
operations of the inserters or vice versa. Such a configuration also makes
the printer available for non-mail jobs. One of the important
disadvantages is that marks are needed on each document or at least on
header papers to correctly move the job through the equipment and into the
proper envelope.
FIG. 2 shows a coupled configuration which is also in use at the current
time. Again, the print job originates in the host 16 and in its large
database and the print stream is sent to the controller 11A of printer 11.
In this configuration an unwinder mechanism 10 unwinds a roll of paper for
feeding to a printer 11, the output of which is directly coupled to the
inserter line 14. The advantages of this type of configuration is that a
folding machine 12 in the printer line is eliminated. Only a single
operator is needed and the output of the printer is packaged for immediate
mailing. An important disadvantage is that the operations of the inserter
and the printer must be speed matched. Also, in this configuration the
printer is dedicated to mail applications and the system is only as
reliable as its weakest link. Marks on the paper are still needed to
coordinate the documents from a printer with envelopes fed into the
inserter from a different document feeder.
FIG. 3 shows a system which may be termed an intelligently coupled
configuration. This system is similar to the configuration shown in FIG. 2
except that the controller 11A for the printer and the controller 14A for
the inserter are enabled to exchange information so that as documents are
printed, the printer can inquire if the inserter is ready. If it is, then
the printer can send the document on to the inserter. This system enables
the printer to communicate with the host 16 that originates the print job
and provide the host with information about the inserting equipment that
is connected to the printer. As a consequence, the system is enabled to
ascertain the capabilities present on the equipment in the print path.
This system also enables processes running on the host to advise the
printer and the other equipment in the path when a job begins and when a
job ends so that the need for marks on the paper is diminished or
completely eliminated. This system also provides an error recovery
operation such that if a job is completed without incident that can be
recorded. This system provides software control over the process but still
retains certain disadvantages. For example, the speed between the printer
and the inserter still must be matched. The entire line is only as
reliable as its weakest link and the printer is dedicated to mail
applications.
FIG. 4 shows a network coupled configuration for which this invention is
designed. The print jobs originate with application processes at a host 16
for generating a print stream sent to the controller 11A of a printer 11
in much the same manner as the other configurations described above. In
this system, FIG. 4 shows an unwinder mechanism 10 is used to unwind rolls
of paper and send them to a printer 11. It should be noted that paper
input to the printer could be from cut sheet document feeders, a
continuous form feeder or any other type of paper feeder. The output of
the printer 11 is sent to a medium modifier 17 which may be, for example,
a mechanism to imprint a color plate on a medium, or make a perforation
cut on a page to be returned by a recipient. From the medium modifier, the
document path leads to a folder mechanism 12 for stacking the documents on
a tray 13. In this configuration the printer line is separated from the
inserter line. Consequently, there is a movement of the tray 13 to the
input of the inserter line which is illustrated in FIG. 4 as a manual
movement. In this configuration there is direct communication between the
controller 14A in the inserter 14 with the system manager located on the
network 18. Likewise, the system manager has direct communication with the
controller 11A of printer 11 and perhaps with other devices in the system
that have microprocessor based control. The communication may be either
direct or through communication with the controller 11A in the printer or
the controller 14A in the inserter. In that manner, error recovery
procedures may be implemented throughout the system. The marks needed on
paper are kept to a minimum. There still must be marks in order to
identify jobs from the printer line when they reach the inserter. Speed
matching is not a problem in this system since the printer line and the
inserter line are separate and consequently the printer is available for
non-mail jobs.
FIG. 5 is a more complete description of the system shown in FIG. 4 and
shows that host 16 is connected into network 18. A customer application 20
is run on the host 16 to generate a print job. During that generation
various value-add programs and indexing programs 21 may add to the print
data stream and include data in the print files. Such programs may, for
example, add bar codes for sorting files in zip sequence and generate the
codes needed for proper finishing of the print job. Print files 22 and
index files 23 may be created. Print Service Facility (PSF) 24 which also
runs on host 16 will generate the print data stream for driving the
printer 11. The system manager 25 resides on a work station which is
connected into the network 18. The network may be either a local area
network (LAN) or a wide area network (WAN). Also connected into the
network are various work stations illustrated as graphical user interface
(GUI) 26 and graphical user interface (GUI) 27 which may be placed in
various locations for different purposes. For example, one may be at the
inserter for the use of the operator of that line, one might be at the
printer for the operator of that line, one might be at a warehouse for the
warehouse manager to check the need for supplies as they are being used,
e.g., paper, toner, etc.
In the system shown in FIG. 5, mutilated mail pieces are reprinted on
demand on a smaller remote print station 28 attached to the network. In
that manner, replacement documents are automatically generated as the
system automatically senses the mutilation of a document.
FIG. 6 shows a generic interface model for the large mail room system of
FIG. 5. Such a system is a coordinated set of hardware and software
components and interfaces that work together to automate the output
processes associated with high volume printing, finishing and delivery of
individual mail pieces. Work begins in the data processing portion of the
system with applications 20 that generate print data 20A. In many
instances these applications are existing "legacy" applications on large
mainframes that produce many types of large mailings such as, for example,
the billing statements of utilities for customers. As shown in FIG. 6 the
print data 20A from customer applications is further processed by
value-add applications 21A and advanced function presentation (AFP)
functions 21B that condition the data for printing and prepare object
files 21C, D, and E for downstream operations.
In today's modern environment there are many tools available to assist in
generating customized print output. Examples of value-add functions are
programs which provide address verification, presorting of statements by
their postal characteristics, programs 21G for building insertion
instructions based on information contained in demographic and marketing
databases and programs 21F for segmenting print data into manageable units
of work.
Examples of advanced function presentation functions are services that
convert line data into page data, build document index objects for
locating individual groups of pages and building print files for reprint,
viewing and archiving services for storing and retrieving the manageable
printing units of work.
Host value-add programs and AFP services are designed to be application
independent so that they do not require changes in the customer's print
producing applications in order to perform their function. Once the VA and
AFP process is complete the print files are scheduled for printing.
Control information for the insertion process is separately sent to the
finishing server when the finishing hardware is not in line in the print
path. Bar code or optical recognition marks on the paper are used by the
finishing server to correlate the finishing instructions for a print job
with individual mail pieces to be assembled and packaged for postal
delivery.
FIG. 7 shows a generic model of the system manager, mailing operations
manager 30, which must provide a message handler interface 31 that is used
by all of the various hardware and software processors 32A-G to define
themselves to the system and report changes in status. Information about
the processors 32A-G is maintained by the systems manager in a database
called the Management Information Format (MIF) file 33. The system manager
must also provide the request, reply, message interface 31 used by
application agents to query status and obtain information about the
products, mailing jobs and mailing pieces in progress over a network 34
providing client/server functions.
The system and models shown in FIGS. 5, 6 and 7 were developed by a council
of users and vendors called LMO Systems Workgroup. That workgroup,
comprised of research companies, is now known as the Data Management Task
Force (DMTF) Finisher Workgroup, and was formed to identify key
requirements of large mail room operations (LMO) and to explore the
possibility of defining an open systems architecture standard for meeting
them. This work resulted in demonstrating the capabilities of an
integrated system at the "XPLOR" conference in November of 1993. The
"Large Mailing Operations Standards Specification", Version 1.0,
incorporated herein by reference, was published on Oct. 31, 1994, by the
DMTF Finisher Workgroup and is available from Pennant Systems, Inc.,
Boulder, Colo. 80301-9191. It is the standard that has been developed by
the workgroup to manage hardware and software processors in the large mail
room operations systems environment.
The demand for standards is fostered by the need for selecting an
architecture base that is widely accepted, easy to implement and
extendable to future requirements. Customers and vendors alike need to
feel that their solutions and products are built on interfaces that are
durable and can take advantage of emerging technologies. In the desired
system, easy to understand graphical interfaces commonly used on desktop
computers are important.
In looking for currently available open systems standards for modeling the
functions required in the large mail room operations (LMO) environment,
the LMO standards work group discovered that the standard base that most
closely meets these requirements is the DeskTop Management Interface
(DMI). The DMI standard is managed by a group of companies calling
themselves the DeskTop Management Taskforce (DMTF) who published the
DeskTop Management Interface Specification, Version 1.0 on Apr. 29, 1994,
incorporated herein by reference. The publication may be obtained from any
company who is a member of the taskforce including IBM Corporation, P.O.
Box 1900, Boulder, Colo. 80301-9191.
Implementations of the DMI are available today or committed in OS2,
Workplace OS, DOS and AIX. Other platforms are sure to follow. By building
LMO objects and management protocols on the DMI, LMO standards may be
established in a uniform manner across all of these platforms.
In the terminology of DMI, components are physical or logical entities on a
system such as hardware, software or firmware. Components may come with
the system or may be added to it. The code that carries out management
actions for a particular component is known as "Component
Instrumentation". FIG. 8 shows a generic model of the DMI.
A management application 100 is a program that initiates management
requests. A management application uses the DeskTop Management Interface
to perform management operations. The management application is
exemplified by a program such as an application with a graphical user
interface (GUI), an application program agent, or it may be a network
management protocol agent that translates requests from a standard network
management protocol such as SNMP or CMIP to the DMI and back again.
The service layer 102 coordinates access to component instrumentation and
component provided data in the Management Information Format (MIF)
database 104.
One may note the natural relationship of the DMI model shown in FIG. 8 with
the LMO model shown in FIG. 7.
In the use of the DMI, component descriptions are defined in a language
called the "Management Information Format" (MIF). Each component has an
MIF file to describe its manageable characteristics. When a component is
initially installed into the system, the MIF file for that component is
added to the MIF database 104 for use by the service layer.
The component interface (CI) 103 is used by component vendors to describe
access to management information and to enable a component to be managed.
The CI shields vendors from the complexity of encoding styles and
management registration information. Vendors do not need to learn the
details of emerging management protocols.
The management interface (MI) 101 is used by applications that wish to
manage components. The MI shields management application vendors from
understanding the different mechanisms used to obtain management
information from elements within the system.
The CI and MI are data interfaces as opposed to procedural interfaces. Data
blocks are used as the format for data transfer--not parameters to a
function call. The behavioral mechanics of the CI and MI make up the data
transfer mechanism.
The service layer (SL) 102 is an active, resident piece of code running on
a computer system that mediates between the MI and the CI and provides
access to the database 104.
It should be noted that the DeskTop Management Task Force which developed
the DMI did so to close the gap between management software and the system
components that require management on a desktop computer. Within a
computer system, the DMI has been designed to be independent of any
specific computer or operating system. It is designed to be independent of
any specific management protocol. It is designed to be independent of a
network but it is designed to be mappable to existing management
protocols, e.g., CMIP or SNMP. Basically, however, the DMI is designed for
a single desktop computer where components are physical or logical
entities on the computer system, such as disk drives and word processors.
The DMI does not address or specify a protocol for management over a
network but the prospect of managing several desktop computers within a
network was considered by the DeskTop Management Task Force. The LMO
standards work group has greatly extended the vision of the DMI by
applying it to a network which not only includes desktop computers, but
also includes complex machinery, such as document finishers and inserters.
Moreover, the vision of the DMI is extended to include large mainframe
host equipment and processes running thereon. The LMO system calls for
defining the manageable characteristics of complex machinery and the
manageable characteristics of mainframes and mainframe processes in an MIF
database so that these characteristics can be managed from a workstation
or desktop computer or any GUI on the network.
SUMMARY OF THE RELATED INVENTIONS
In implementing the large mail room system manager model on the DMI
interface several problems were revealed which resulted in the inventions
which are the subject of this patent application and the related patent
applications named above.
In a large mail room operation there are many hardware and software
processes to be managed and many management applications requiring access
and control over the manageable data. Most of these processes and
management applications are located on, or controlled by computing systems
other than the particular computing system containing the DMI and the MIF
database. To satisfy the networking requirements of the large mail room
operation, the DMI model needed to be extended to provide for
client/server communication in a manner that preserved the syntax and
semantics of the DMI standard, while enabling the service layer to
continue to dynamically coordinate and arbitrate requests from the
management applications to the specified component instrumentations.
Related patent application Ser. No. 08/334,948 provides a solution to this
problem. It was observed that because the nature of the service layer is
to provide support that handles run time management of both the management
interface and the component interface, simple request/reply, client/server
protocols would not suffice. To solve this problem has required the
invention of a network client protocol capable of handling three-way
dialogues between clients, servers and instrumented components all
residing on different nodes. To do that the client interface was
established by supporting all of the functions of the MI and the CI at
each of the required client platforms. This is accomplished by porting DMI
function calls to those platforms and implementing them on a "Remote
Procedure Call" (RPC) base using Transmission Control Protocol/Internet
Protocol (TCP/IP) as the transport carrier. The underlying RPC support is
handled by the client interface code and is transparent to the DMI
programmer. The invention enables operation in a consistent manner across
a variety of operating systems, hardware platforms and different
architectures. In addition, it is capable of allowing a client implemented
on one architecture to inter-operate with a server implemented on another.
The invention preserves the semantics and syntax of the MI and CI, while
enabling data transfer mechanisms to and from client, servers and
instrumented components, all of which may reside in different nodes in the
network.
A problem faced in implementing the system manager models involved the many
legacy applications running on mainframe platforms to prepare print jobs.
In a large mail room operation there are many applications and value-add
processes running on mainframe computers that need to be tracked and
managed as an integral part of the mailing operation. Examples of these
are programs which generate print output, like bills for mailing; programs
which pre-sort | | |
