Top HATS tricks you can’t live without (pun intended)

For those who have just discovered HATS and are getting started with it, I thought I’d share some tips. These are my top 10 rules of thumb with HATS, and in no way is this all the tips I have.

1. Be a lazy developer. Don’t try to transform every screen. Rather, use global rules and default rendering sets to control 80% of your screens. Global rules simply tell the HATS runtime to render an area of the screen a certain way whenever it sees a common text string. For example: always render 6 digit fields preceded by the words “Birth Date” with a calendar popup. Another example: Render single character fields for gender (M or F) as radio buttons. These rules will then apply to multiple screens.
2. If you have to do a customization/transformation, use “Insert Default Rendering” to control those fields that should render using global rules, and use host components for the fields that don’t behave by default rendering (such as odd ball subfiles).
3. Setup version control ASAP. A version control system synchronizes your source code and keeps every revision. This is great insurance for CYA. If you’ve only ever worked in PDM, this will sound very foreign. In HATS the source code is on your local PC, not the server. Therefore, if your hard drive crashes, your screwed. If you have installed HATS on top of WDSC Advanced, then you have a client liscense to Rational ClearCase LT. If not, you try the open source (and highly recommended) Subversion (http://subversion.tigris.org).
4. Publish early and often. This is really not specific to HATS, but rather to programing in general. What I mean by this is don’t spend 6 months customizing screens before you release it. Rather, HATS works out of the box. Get it to your user community within a week or two of creating your first project. Then, let your users define what screens they need customized. Take those requests, prioritize them, and release changes on a regularly scheduled interval. If you can’t get all the requests completed in time, let those requests fall over to the next iteration. Remember this fact: users remember missed deadlines, they don’t remember missed requirements (MS Vista was how late to market? Anyone know what requirements got missed in it?).
5. Download and install the latest fix pack immediately. If you have not released your project into production yet, install the latest fixpack (link is available on this blog). This fixes quite a few issues in HATS 7.0.0.0. If you are running HATS 6, upgrade…now. The upgraded table component alone is worth it.
6. You need a test server. Yes, HATS runs on WebSphere Application server, which in turn runs on System i or z. You don’t want to use it as your test and production system. Use it for production only. WAS runs on multiple platforms, and a test system is very cheap. You can even run it on Linux in a VMWare partition if you are short on space and cash, but you need a test server. Use this test server so other developers and the application owner can review it and approve it before you publish to production.
7. Don’t starve your production server! Let’s face it. WAS is a pig. It eats memory like Michael Moore inhales twinkies. Don’t treat it like another interactive user. WAS on a 64 bit system even more so. This is because a 64 bit system requires 64 bit memory registers (twice that of 32 bit registers). If you put WAS on your production iSeries box, and you only have 2GB of RAM in your shared memory pool, you will FAIL. If WAS is on a System i, it needs 4GB to itself (maybe in its own memory pool), and if on an LPAR it needs at least a half CPU assigned to it for even small apps. If you can’t handle this, then put WAS on a Windows or Linux machine with at least 2GB of RAM (more preferrably, this is a minimum). If you feed WAS the memory it needs, it will stand up and roar, and you will be happy. Starve it, and your users will stone you.
8. Don’t use the default templates. They suck. They’ve been the same since version 5. Create your own template using the wizards and brand your new app. Oh, and don’t use the monospace font, unless you want your browser to look like a graphical mainframe.
9. Publish/Restart App. It may happen to you that when edit the project properties file (such as if you are changing the default rendering or adding global rules), that application will crash and stop working. Don’t sweat it. Turn off automatic publishing. Then when you edit and safe this file and are ready to test your new global rule, simply publish the application, then right click on the application under your server in the ‘Servers’ tab, and restart the EAR (i.e HATS_EAR61). The application will crank right up.
10. Go to training. The best way to get proficient at HATS is to go to a HATS training course. IBM has some hosted at their facilities. If you are looking for on-site training where a trainer comes to your company and trains a group of you then well… I’m your huckleberry. Yes…this last tip is an advertisement for my services, but I do consulting for a living and HATS training is one of my offerings. I have a full curriculum with canned labs and presentations. The course includes 4 days of lecture and labs and one day of custom development with your screens so you get familiar with how HATS relates to what your environment is like rather than the IBM demo servers. If you are interested, visit my company website at www.strongbackconsulting.com for my contact information. If you are just looking at the product and are interested in purchasing, I am a registered IBM Business Partner and will be happy to give you a quote. Ok. end of the ad. Also, check back on this blog, as I frequently post messages about common issues, fixes, bugs, and news about HATS.