Here are some of the topics covered in our FAQ.
Absolutely. Remember that HostBridge requires no changes
to your existing CICS applications: no changes, no recompiling,
nothing. As a result, CICS applications can be used from
real 3270 terminals, PC’s with emulators, and HostBridge
simultaneously. The application will never know the difference.
While we would like to take credit for this feat we really
can’t. This is just how the CICS 3270 Bridge feature
works. If you care to know why, read on…
A transaction is started under CICS when a program issues
a START request specifying the name of the transaction.
When you access CICS from a 3270 terminal (real or emulated),
your session is being managed by special program within
CICS (we will refer to it as the “terminal handler”).
It is the terminal handler that interacts with you at
the terminal and allows you to specify the name of the
transaction in the upper left corner of the screen. The
terminal handler receives the information from the terminal
and issues the START request to invoke the transaction.
When using HostBridge, the process is similar except that
the CICS terminal handler program is not used. Instead,
HostBridge receives a request to execute a transaction
via HTTP (or possibly ECI). Upon receiving a request,
HostBridge issues the START command to invoke the specified
transaction.
When IBM added the 3270 Bridge feature to CICS, they added
a new parameter to the START command. This command allows
the issuer to specify the name of a “bridge exit”
that is to receive control whenever the transaction issues
a BMS or terminal control operation (e.g., SEND MAP).
This process of CICS passing control to a bridge exit
(i.e., HostBridge) is totally transparent to the CICS
application.
Yes, and without forcing customers to use proprietary scripting
languages. A more detailed answer follows.
While HostBridge changes the way a CICS BMS transaction
communicates (XML instead of 3270), it does not change
the way a CICS application is organized internally (that
would require changing the application). Stated differently,
HostBridge changes the way a CICS application “speaks”,
but not the way it “thinks”
Various factors guide a CICS application developer in how
transactions are organized (e.g., workflow, processing
efficiency, display screen capacity and ease of programming).
Transactions are usually designed to be either “conversational”
or “pseudo-conversational”. Once started, a
conversational transaction interacts with the end user
multiple times before it terminates. Because they can
run for an extended period of time, conversational transactions
are usually discouraged for reasons of processing efficiency.
Pseudo-conversational transactions appear to the end
user to behave like a conversational transaction. However,
the application has been designed such that each interaction
with the user is a separate transaction.
Regardless of which technique is used, applications are
frequently designed such that multiple interactions/transactions
are required to complete a specific work process. And,
if this is true without HostBridge, it is also true with
HostBridge: multiple interactions between HostBridge and the CICS application (via HostBridge)
are still required. It is this situation that raises
the question as to how HostBridge can be used to automate,
or “script”, these multiple interactions.
If a customer wants to perform transaction/process automation
on the host, we suggest that they use the standard scripting
languages and process automation tools such as those
supported by HostBridge Extended.
However, if a customer wants to perform process automation
from the middle-tier, they are free to use whatever application
development environment they already use (provided it
supports HTTP and XML). Alternatively, customers could
use a product that specializes in XML-based process automation,
such as eXtend from Novell Software. (Please refer
to the FAQ question “Can HostBridge be used with
Novell eXtend?”)
