No place like HOD

IBM’s Host On Demand (HOD) application is a fantastic solution, providing access to IBM mainframe servers through a browser. It’s basically a Terminal emulation client written in java, allowing it to be embedded into the browser, and allowing it to be published on a company’s external website via technologies like UAG’s SSL-VPN publishing.

Back in the days of IAG, HOD was quite popular, and so IAG had a special template for it. When UAG was being developed, the need for HOD was on the decline, and so the template for it was removed. This doesn’t mean, though, that it cannot be used! On the contrary…with the proper configuration, it can be used with ease!

The trick is to realize that HOD is what we, in the UAG world, like to call ‘a browser embedded application’. A B.E.A. is a fancy term for an application that is not web-based (i.e., not communicating with its server using the HTTP or HTTPS protocols), but it’s launched from within an HTTP or HTTPS session. Many JAVA, Flash, Silver light and Active-X based applications are like that, and so is HOD. There are even some executable apps that are like that too!

The way a B.E.A. application works is by being offered to the user via a web page. The user visits the page, which has an embedded “call” for the application. When the page loads in the browser, it instructs the computer to launch the application using its framework, and then the application needs to communicate with its server using some non-HTTP or HTTPS communication channel. That framework would typically be installed on the client’s computer, somehow. Active-X, for example, is already baked into every version of windows out there. Flash, Silver light and Java would typically require the user to install those frameworks (The Flash player from Adobe’s website, Java from Oracle’s site, and Silver light from Microsoft’s).

Just the fact that there’s a flash, Silver light, active-X or Java application on the page doesn’t mean it’s a B.E.A. application. Such an application may be able to communicate with its server using HTTP or HTTPS, and if so, may work using any regular web-based template in UAG. However, some apps use other protocols. For example, another B.E.A. is Citrix, which communicates with its backend server using their own protocol on ports 1494, 2598 and 3389.

When a B.E.A. application is published on UAG, it is configured to launch an SSL-VPN tunnel, and then launch the client from the browser. The client can then use the SSL-VPN tunnel to communicate with its backend server. To publish a B.E.A. application on UAG, all you have to do is figure out the names of the servers it is supposed to communicate with, and the ports it needs to use. Then, run the UAG application wizard, and from the application template menu, select “Generic Browser-Embedded Application (Multiple Servers)”:


On step 5 of the wizard, you need to configure the properties of the WEB server. This is the server which hosts the web page with the links to the application. Often, there would be only one web server that hosts both the web page, and the actual application, but it’s not always the case. Keep in mind, though, that the HTTP PORTS are only for the web page, so this would be usually either HTTP or HTTPS. This is not where you would specify the higher ports!

Step 7 of the wizard is where the magic happens. The servers and ports listed there define, for the SSL-VPN tunnel, to which servers on the inside traffic needs to be forwarded. Here you might specify one or more servers, and one or more ports (separated by commas). As the administrator, you may not always be aware of ALL the servers that are involved, so make sure you do your research with the application’s owner. It’s sensitive – missing a single server or port could ruin the party. Keep in mind, though, that the HOD Config may differ from server to server, and that you can always go back and add something, if you forgot or got it wrong:


Once done and activated, launching the new application is supposed to launch the UAG SSL-VPN tunnel on the client, and display the notice “Ready to launch application”. At this point, you are supposed to see the SSL-VPN blue-yellow arrows on your client’s systray, and the HOD application should launch inside the Java window on the browser. If the SSL-VPN tunnel is not opening at all, then it means there’s something wrong with the client components on this specific client, so the 1st step would be to check another client, preferably a “clean” one (without older versions of the components, or a computer that hasn’t been tortured too-much). If the tunnel is launching, but the HOD app doesn’t launch, troubleshoot your Java installation. There are multiple versions of the Java client, and some are known to be more challenging to get working than others. If the HOD app is launching, but unable to connect to its server, then it means the tunnel is not permitting access to the appropriate server or port. This may be tricky to troubleshoot, but a 1st step would be to use something like Network Monitor on a regular, internal client, and see if the application may be using other ports, or calling other server names.

Post written by Ben Ari

Cheers to Thomas O. for your help with this!

Skip to main content