Vignesh wrote: >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 >any chance?
As background, there are several HOD "servers." Here's a reasonably complete list: 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 servers. 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 example. 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 simple. 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. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
