Other names for this are the Background Process, Attendant Process, or Daemon.
The classic example is printing. Rather than tying up
a foreground process with physically printing a document, the foreground process creates a
new background process that handles the logic and I/O for the printer.
It is when the application becomes mission-critical and/or
more complex that designing a full feature asynchronous process becomes a major
- Providing prioritized queues for the requests,
- providing multiple asynchronous tasks to process the queues and the management that goes
- providing synchronous access (wait until complete) and asynchronous access with
- providing automated error recovery,
- providing back-out and restart,
- providing inquiry and modification to the execution environment.
This major design and implementation may cost so much in
time and resources that the team looks for easier alternatives.
It is for these reasons that there is Tymeac.
Tymeac is an asynchronous
process / task manager.
Synchronous tasks are
the Client tasks started by CICS in response to input of some kind.
Asynchronous tasks are
the tasks either the application starts and controls or the tasks Tymeac
starts and controls on a Backend Server. Tymeac relieves
you of the burden of managing asynchronous tasks.
You set up a Tymeac Queue
for each component application specifying the maximum number of asynchronous tasks.
- Tymeac balances work among those asynchronous tasks so
that they use the minimum amount of resources.
- Tymeac handles the recovery from anomalies (a huge
burden for applications.)
- Tymeac synchronizes all the asynchronous tasks (another
huge burden for applications.)
- Tymeac offers timing of requests (a synchronous request
is when you wait for completion of all Tymeac Queues.)
- Tymeac offers background processing (an asynchronous
request is when you schedule a request and do not wait for it to complete.)
- Tymeac links to your user-written application program to
execute the application logic.
Back-ends are the opposite of front-ends.
Front-ends are green screen, GUI services or any
application that one considers a client.
Back-ends are generally hidden from the user of the
application. These are any applications that one considers a server. In
addition, the server itself may require "services." This is where Tymeac
Anytime an asynchronous tasking is desirable. The list is only limited by
See also Real World Examples
To make use of persistent storage on a Backend Server.
Tymeac is a Backend Server
environment. Once Tymeac starts, the storage acquired by
asynchronous tasks within this environment persists.
For parallel processing:
A process requires access to two databases, (customer and pricing).
Set up a Tymeac Queue for each database
access. Set up a Tymeac Function that uses these two
Queues. [This is as easy as filling in the blanks.] When the client application uses
this Tymeac Function, both Queues are active
To time a request:
To run an autonomous request with call-back:
In the above example, tell Tymeac not to wait for
completion. The client is free to perform other work. When the last Queue finishes, it may
optionally schedule an Output Agent. The Agent may take the responses from the Queues
and send them anywhere.
To separate components:
See the key benefit, Gateway.
In the above example, the application requires two database accesses. Each of these may
be for a different vendor's database or even legacy applications. Incompatibilities
between products and/or applications is irrelevant. Tymeac
segregates logical units of work.
To separate client from server:
One of the essentials of Tymeac is the ability to
separate the Web-based interface from the rest of the company.
In the above example, this 'process' may be the back-end for an Internet/Intranet
front-end. You can put security, or anything else, in each component without ever touching
To isolate failures:
See the key benefit, Containment.
In the above example, if one database access 'hangs' or abnormally terminates, recovery
is easier. There is no need to handle every possibility in relation to every other
possibility. Tymeac isolates components.
Resources: Less asynchronous tasks means less
memory and less cycles.
Competition: Asynchronous tasks compete with each other within a Tymeac
Queue, with other task in CICS®, and with other processes in the
Box. Sometimes adding more tasks slows down overall processing because of resource
limits, (memory, cycle, network, locks, blocking, etc.)
Let's say you have an application that uses two (2) additional asynchronous tasks such
as the prior example.
In an n-tier application server you may have one hundred (100) of these applications
active at one time. That means that there are two hundred (200) tasks for these
applications competing with each other for resources.
Now the same application with Tymeac.
You set up a Tymeac Queue for each database access
component. For this example we set ten (10) as the maximum number of asynchronous
tasks for each Queue.
When one hundred (100) applications are active, the maximum number of
asynchronous tasks for these processes is twenty (20), not two hundred (200). That means
that there are one hundred and eighty (180) LESS asynchronous tasks competing with each
other for resources.
When no asynchronous task is immediately available to process a request, Tymeac
places the request in a prioritized wait list (your request designates the
priority). This assures that the "hot" request processes first. When
an asynchronous task finishes a request, it looks in the wait lists for more work.
Of course this means that requests "stack up". This is the balance: How many requests may stack up before it
is better to have another asynchronous task?
You have the option of specifying the maximum number of asynchronous tasks for
You have the option of specifying when a new asynchronous tasks becomes a
participant in processing through new task thresholds.
You have the option of specifying task creation time (at Tymeac
start up or when first needed) and task destruction (after an idle period or never.)
You have the option of timing requests.
You have the option of prioritizing requests.
You are in control, not chance.
Tymeac keeps detailed information about each Queue and
Function. Tymeac provides tools to monitor, alter, and log
these statistics dynamically and statically.
No, Tymeac is a process now
system. Delaying the processing is outside the scope of an asynchronous process
However, there are numerous middleware, message-queuing systems on the market. The
scope of these systems is that one sends a message, (this could be the parameters for
Tymeac), to a Queue with instructions to deliver the
message to another Queue at a later time.