Post by Sankaranarayanan, Vignesh
Say there are 'n' servers that have HOD installed, and all
of them are under a load balancer, so there's a single target.
Would it work if the product was just installed and setup in
1 server, and then cloned 'n-1' times?
Let's say the 'servers' are Windows VMs. Would this be an
acceptable approach if it were a different server OS, by
As background, there are several HOD "servers." Here's a reasonably
1. The HTTP/HTTPS server (Web server) that delivers the Host On-Demand
applets to the user, at least in the first instance and for subsequent HOD
release updates. In principle, the HTTP/HTTPS server for HOD can be
*anything* -- it's just a set of files. Just for fun, I once tried hosting
HOD on an Apple Macintosh Quadra 700 running Linux and the Apache HTTP
Server. It worked, although that wasn't the speediest HTTP server. (It
doesn't have to be particularly speedy, though, as long as you're using the
so-called HOD "cached client.") IBM publishes a list of tested HTTP/HTTPS
2A. The Host On-Demand Service Manager, a.k.a. Host On-Demand Configuration
Server. In principle, the HOD SM/CS can run on any machine with a JVM of at
least relatively recent vintage. IBM publishes a list of tested HOD SM/CS
platforms, and for certain platforms (e.g. Windows) IBM includes an
installation program that installs an IBM-supplied JVM and sets up the HOD
SM/CS on it.
2B. The HOD Configuration Servlet, which can only be used in conjunction
with #2A. The HOD Configuration Servlet is not relevant on its own. This
servlet can, in principle, run on any application server with Java servlet
support. IBM WebSphere Application Server is an excellent choice.
3A. The target "server" system to which you're establishing a HOD terminal
emulation session or file transfer session. This target system can be
anything that supports TN3270, TN3270E, TN5250, TN5250E, Telnet, SSH, FTP,
etc., etc. Target systems span everything from z/OS mainframes to embedded
"Internet of Things" devices, and just about everything in between.
3B. HOD can connect to target systems via a proxy server. Supported proxy
server protocols include HTTP, HTTPS, SOCKS4, and SOCKS5.
4. The Host Access Client Package (HACP) Extended Edition server, recently
introduced. HACP EE provides a subset of HOD end-user functionality without
any Java on the client. HACP EE should be compatible with Apple iPads, for
Now here's the really interesting fact: *all* of these HOD servers except
#3A are optional, although I'd argue that #1 is important (but not strictly
mandatory). As general "best practices" advice, you shouldn't use the HOD
servers that you don't actually need -- shouldn't even bother with them.
Moreover, when you do run particular HOD servers, the "best" place to
install/run them is generally on the same system as #3A. In particular, if
you're primarily or exclusively connecting to z/OS, then the preferred/best
place to run HOD servers, such as #1 (notably), is right on z/OS itself.
"Keep it simple" for robustness, and yet-another-distributed-server ain't
I believe your question refers primarily or entirely to #2A, the Host
On-Demand Service Manager (a.k.a. Configuration Server). If my assumption
is correct, and with that background information, here are the two answers
to your questions:
A1: Don't run the HOD SM/CS at all. If you don't run the HOD SM/CS, then
you don't have to move it, and HOD clients will store their
settings/preferences in user home directories. Those user home directories
can be on shared network drives, if desired -- and if you'd like to support
"roaming users" just as you do for other desktop/laptop applications, for
example. The HOD documentation refers to this mode of operations as the
"HTML-based model," meaning that the initial session information (default
sessions, initial keyboard layouts, etc.) is defined within the HTML
startup file(s) delivered to the client rather than fetched from the HOD
SM/CS over a separate connection. Please note that "HTML-based model" is
not the same thing as HACP EE (#4 above). In fact, the HOD HTML-based model
is the very first HOD deployment mode, tracing its roots all the way back
to the first version of HOD.
The "HTML-based model" is still my favorite way to run HOD in most
environments, as it happens. To configure the HTML-based model, use the
Deployment Wizard to generate the correct HOD startup file(s) (HTML, for
Java Web Start). Deploy that startup fileset to the HOD HTTP/HTTPS server.
Then access that Web URL from the client, and away you go.
While it's not necessarily recommended to copy the HOD directory -- the
directory that your HTTP/HTTPS server can deliver to clients -- it is
*possible* to do that, even across platforms. If you're using a z/OS
HTTP/HTTPS server then just be a little extra careful to get the
EBCDIC/ASCII configuration settings in the Web server correct, per the HOD
documentation. Or, if you don't know what you're doing, install HOD on z/OS
(without starting up the HOD SM/CS), then put the Deployment Wizard output
on z/OS in the appropriate HOD directory.
One reason why you might want to be careful about just copying stuff
without knowing what you're doing is to make sure you can still apply
service updates and version upgrades.
A2: You can probably move HOD SM/CS contents from machine to machine (and
even from OS to OS), but you have to be a little careful about that, just
as with A1.
If you only have one instance of the HOD SM/CS running, and if HOD clients
are expecting it to be available, then that's probably not going to work
well in terms of availability characteristics. Consider A1 (above), or
alternatively the "combined model" discussed in the HOD planning
documentation. The "combined model" requires access to the HOD SM/CS for a
new HOD user, once, but thereafter the HOD SM/CS can be offline without end
user service impact -- as long as you get Deployment Wizard settings
correct, that is. In particular, I believe you still have to throw a switch
(in the Deployment Wizard) to turn off HOD user startup counts, since that
counting is handled at the HOD SM/CS.
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN