FAQs: HostBridge Operation
The list is by no means exhaustive, so please feel free to mail us questions about any topics we fail to cover here.
Here are some of the topics covered in our FAQ.
- What is "screen scraping?"
- Does HostBridge do "screen scraping" under the covers?
- With HostBridge, how and when are field names "bound" to values?
- What does HostBridge provide that is not already in CICS TS 1.3?
- What does HostBridge use to generate its XML output?
- What does HostBridge's XML output look like?
- How can I route requests to HostBridge running in different regions?
- Does HostBridge execute in the CICS TOR or AOR?
- How does CICS user authentication work with HostBridge?
- What is the maximum number of sessions I can use with HostBridge?
- If I have CICS TS 1.3, how do I request a particular bridge facility for use with my CICS application?
- Can I use InterTest/CICS (from Computer Associates) or XPEDITER (from Compuware) to debug a transaction invoked through HostBridge?
- Can a CICS application programmer tell, in their application code, that a transaction has been invoked via HostBridge?
What is "screen scraping?"
"Screen scraping" involves the use of row/column coordinates within a program to create a relationship between (or "bind") data within a screen buffer to local program variables or events. If the location of a field or data on the screen changes, then the binding will be incorrect and the program that specifies the row/column coordinates will have to be changed.
The best way to determine if screen scraping is taking place "under the covers" in a particular product is to pose the following questions:
- What happens if you change the physical location of a field on the screen?
- What happens if you change the location of a literal value on the screen?
If a product relies upon screen scraping techniques, various definition changes will be required before the product will work with the modified screen.
Absolutely not! The whole idea behind HostBridge is to eliminate "screen scraping."
The data that HostBridge receives from the application (via 3270 Bridge) is not formatted for display on the screen. It is simply a data structure (called the ADS). The ADS contains no row/column coordinates. It contains only the contents, and certain attributes, of the variable fields on the screen. The ADS is the data structure that a program passes to CICS when it makes a BMS call, such as SEND MAP.
One fact that is often overlooked is that CICS applications that use BMS don't "think" in terms of rows and columns. That is an abstraction created by BMS. The application code thinks in terms of fields and values. By circumventing BMS and the 3270 data streams it generates/expects, and replacing it with an XML document that carries just field names and values, we allow the host application and the middle-tier application to "think" exactly the same way.
With HostBridge, how and when are field names "bound" to values?
The binding between field names and values occurs during a one-time, preparatory step. It occurs (automatically) when the map is reassembled using the BMS map generation utility in CICS TS. The map generation utility creates a binding between a field name in the map and a field value in the ADS. This binding is expressed in a new data structure called the ADS Descriptor (ADSD). The ADSD contains a list of field names and offsets -- the offsets indicate where within the ADS the data for a particular field can be found. The ADSD is stored in the same load module that contains the machine-readable version of the BMS map.
As you can see, HostBridge is actually uninvolved in the binding between field names and values. This occurs in a one-time process performed before HostBridge ever enters the picture. Furthermore, the binding between field names and values is not based upon row/column coordinates specified by the user. Rather, the binding is created by CICS based on the actual field name and value relationships defined by the user when they created the original BMS map.
What does HostBridge provide that is not already in CICS TS 1.3?
HostBridge XML-enables CICS terminal-oriented transactions and/or COMMAREA programs. CICS TS does not do this. Also, CICS TS does not allow you to send an HTTP request to CICS to invoke a COMMAREA program. The IBM solution would be to use CICS Transaction Gateway. Our customers asked us to add COMMAREA support to HostBridge because they did not want to use CTG. If all you are using CTG for is to allow a Java program to communicate with a CICS COMMAREA program, then HostBridge may offer you numerous advantages.
IBM provides a "template" facility which allows CICS transactions to be accessible via an HTML interface (not XML). Customers have had found it to be slow and buggy. Because HostBridge generates XML, our customers are fee to use any client or server-based GUI design tools to handle presentation-related matters.
What does HostBridge use to generate its XML output?
When a CICS transaction issues a BMS call (e.g., SEND MAP), it specifies the name of the map and the data to be displayed. CICS checks to see if the transaction is running under 3270 Bridge. If so, CICS uses the map name to retrieve the ADSD information out of the appropriate load module. CICS then passes control to the registered bridge exit (i.e., HostBridge), providing it with the ADS and the ADSD (as well as control/status information). HostBridge uses the ADSD to obtain the field names; it uses the offsets within the ADSD to extract the field values out of the ADS. HostBridge then expresses these field name/value pairs (as well as important control information) within an XML document.
Here is a sample of the XML document that HostBridge generates. Details have been omitted in order to highlight the basic information included:
When using HostBridge, routing can be accomplished in two ways. The first way is to route at the HTTP level (load balancing in HTTP terminology), or have the middle tier program use designated regions based on application or geographic location, or even based on an internal lookup table. The second approach is to use HostBridge's COMMAREA interface, which can be remotely executed across regions. The approach chosen will usually be dictated by your integration needs.
In CICS TS 1.3, the architecture of the 3270 Bridge interface is such that HostBridge (which uses the interface) must run in the same region as the application which issues the SEND/RECEIVE command (the Application Owning Region, or AOR). Thus, HostBridge would need to be installed/available in each AOR. Given HostBridge's minimal installation requirements, this should be a simple matter.
Note that CICS TS 2.2 changes the rules a bit with the introduction of the "Linkable Bridge Interface". This interface will allow a single copy of HostBridge to facility access to multiple AOR's. There is still some code running in each AOR to facilitate this, but it's provided with IBM as part of CICS TS 2.2.
How does CICS user authentication work with HostBridge?
How CICS user authentication works is determined by the transport mechanism used to exchange requests/responses with HostBridge. In all cases, however, user authentication is handled by CICS (not HostBridge). For example, the most common transport used by our customers is the CICS TS HTTP Listener, which is configured by the TCPIPSERVICE CSD entry. If you set the AUTHENTICATE parameter of the TCPIPSERVICE definition to BASIC, then then CICS expects the HTTP request to contain a basic authentication header that includes a valid userid and password. CICS invokes your external security manager (ESM) to make this determination (e.g., RACF, ACF2). If (and only if) the ESM validated access, CICS passes control to HostBridge to process the request. From that point on, CICS and HostBridge work together to insure that any STARTed transaction, or LINKed program, execute under the authenticated user's identity.
What is the maximum number of sessions I can use with HostBridge?
The maximum number of sessions is 46,656. Of course, to reach this number of concurrent sessions you would have to have adequate RAM and processing power. If you ever manage to reach this limit, we would like to hear about it!
If I have CICS 1.3, how do I request a particular bridge facility for use with my CICS application?
CICS-TS 1.3 does not provide a mechanism to HostBridge for setting or requesting a particular bridge facility. However, CICS-TS 1.3 is consistent about the names that it assigns to them. Naming starts at }AAA. Each subsequent facility name is incremented by one letter. For example, after }AAA, }AAB, and }AAC will be assigned. Once a HostBridge session ends, the associated facility is returned to the pool. The lowest "lettered" facility that is available in the pool will be used first. For instance, if }AAA, }AAB, and }AAC are being used by HostBridge, and the session that was using }AAA ends, }AAA will be used for next HostBridge session that is started.
If you have an application that requires that terminals be predefined to it, you could define a range of names that would cover the maximum number of sessions that you anticipate using at one time. For instance, if you don't expect to exceed 26 concurrent sessions, you could define }AAA thru }AAZ as terminals for your application.
HostBridge changes nothing about the CICS transaction or its execution. With HostBridge, the only thing different is how the transaction is invoked and the how it communicates to the outside world. The transaction itself is absolutely unchanged.
One of the key features of products like InterTest or Xpeditor is the ability to intercept and and moderate a transaction's interaction with a terminal user. Thus, if you are having problems with a particular transaction and want to debug it with one of these tools, then we suggest logging on to CICS and simply running the transaction from a terminal and use Intertest as you normally do.
Technically speaking, when a transaction is run from a real terminal, it runs under a "terminal facility" within CICS. However, when a transaction is run executed via HostBridge it runs under a "bridge facility". A CICS application can determine whether it is being run under a terminal facility or a bridge facility by issuing the following command:
This command returns the 4-character TRANSID of the bridge monitor transaction that started the user transaction. Blanks are returned if: (a) The user transaction was not started by a bridge monitor transaction, or (b) This command was issued by a program started by a distributed program link (DPL) request. Thus, your program can do the following:
1. Issue an EXEC CICS ASSIGN BRIDGE command.
2. If the returned TRANSID is blank, then the transaction was started from a terminal.
3. If the returned TRANSID is non-blank, then the transaction was started via a bridge monitor program, such as HostBridge.
4. If the returned TRANSID is 'HWBA', then the transaction was started via HostBridge (HWBA is the default TRANSID of HostBridge under TS 2.2; CWBA is the default TRANSID of HostBridge under TS 1.3).