The mysterious Eval Mainframe writes: >I just want some honesty and details from >the field. I want to be ready for what things can bite as part of the >switchover. White papers and vendor promo are just part of the story. >Currently linux/dell with lots of racks.
We're all intrigued about your identity since anonymous guests aren't too common around here. Forgive the hazing ritual. :-) Hopefully you'll emerge soon to reveal all. :-) I work for the Blue Place, so I'm familiar with quite a few migrations of multi-tier J2EE applications to the mainframe. Here are some suggestions about how to anticipate and prevent "things that can bite," in no particular order: 1. IT people of any stripe tend to get possessive and parochial unless well managed. In particular, you don't want to have a "my system" / "your system" dynamic at work, or a "loss of control" issue. For example, I'm a strong advocate of providing ready, easy access to at least one test/development LPAR to the application development team -- and for backing that up with a cooperative, understanding operations person eager to help them. Developers need this to do their jobs, on any platform, so you don't want to skimp on that. IBM's pricing terms are quite good, I think, for supporting that concept. 2. In multi-tier applications where there is split responsibility, e.g. database administrators and application developers, it's very common to have "it's your fault"/"no, it's your fault" contention. Pulling everything into a single tier (mainframe) does tend to help soothe those issues since it can be easier to identify exactly where bottlenecks and problems are within all those tiers. I would take that further and recommend good end-to-end monitoring. Most mainframes have at least something, but I'd review that to make sure it's going to encompass the J2EE tier as well. ITCAM is one example product if you don't have one. 3. Code introspection and profiling is really important. It's likely that your development tool (e.g. Rational Application Developer) has profiling, but are the developers using it? Do they know how to use it? You'll want something analogous on the server side, e.g. ITCAM. 4. It can be a little bit surprising to new developers that, in such a highly virtualized environment, the mainframe team will actually measure things like CPU and memory and look at code efficiency. That's how you get scalable, high performance systems. You can certainly run piggish code, but the ops people are going to (rightly) demand at least a certain amount of professionalism and excellence in what gets delivered. The first time you go through this you'll probably want to have a good person from IBM to take a preliminary look at your code and suggest ways to tune. I've yet to run into an application that didn't benefit from that, and usually substantially. It benefits every platform, but it particularly benefits the thoroughly virtualized one (i.e. the mainframe) because any CPU cycle you can return to the pool is a cycle that someone else can use. The mainframe will contain the pig, just like bouncers at a nightclub, but it's still a good idea to be polite. After a tuning round or two the developers even get enthusiastic about this concept, believe it or not. I've heard of places that actually pay bonuses to developers for code efficiency. Believe it or not you can also de-tier the stress testing servers if you've got those. Rational Performance Tester for z/OS is available, an HTTP(S) Web stress testing tool. A mainframe can stress test itself, believe it or not, and generate predictable, reliable measurements. (The wonders of LPARs and PR/SM.) The tool can also stress test distributed servers since OSA Express is an incredibly efficient and potent IP traffic generator. 5. Don't even think about running non-trivial J2EE workload without a zAAP (assuming z/OS here, which is IMHO the way to go now that zAAPs are available). Throw as much zAAP as you can configure on the machine until your zAAPs soak up as much workload as z/OS will give them. Before you get the zAAP z/OS (1.6 and above; and prior with a downloadable tool) can tell you how much zAAP benefit you can get. 6. Run with at least two servants at least in production for anything you care about. You've got the world's most highly available and reliable J2EE machine, so don't turn off that wonderful high availability capability. Test the failure of a servant (simulating an abend) and the automatic servant restart process. 7. DB2 DBAs won't be thrilled about dynamic SQL if that's what your developers use (probably). Whatever. It's a fact of life. Try to give them some help to manage those incoming database requests, like SQL performance analysis and query monitoring tools, if they don't have it. The developers, over time, should look at static SQL (SQLJ) -- it's actually very easy to program. Regardless, ask your developers to pass some data through the accounting strings on the JDBC connections. (There are some methods defined to pass data over the connection -- you can pass things like server name, end user ID, application name, application version, etc.) If this information gets passed it'll help the DBAs understand what's going on in "their" database and make them a whole lot more helpful and useful in supporting the application development team. Most standard DB2 monitoring products should be able to pick up these strings. 8. Initially you'll probably find out that your security architecture (if you have one) in your multi-tier application is terrible. :-) And then you'll decide it's probably a good idea to improve it over time. For example, WebSphere and DB2 have been able to cooperate much better for the past couple years, so now you don't have to make the whole WebSphere application (or server) a fully trusted entity to DB2, with a single access profile. You can now have DB2 handle authorization while the WebSphere layer handles the authentication, or DB2 can do both (re-authenticate and authorize), for each and every database access and update. This is a really good idea, so keep heading in that direction. You'll also want to try to fold back into a single directory, i.e. your mainframe security system, e.g. the z/OS Security Server, over time. 9. You may wish to decouple the WebSphere upgrade schedule from upgrades to other LPAR components (z/OS, CICS, DB2, etc.) The Java developers tend to have a different pace at which they want things like WebSphere patches, point releases, etc. -- a higher velocity. Make sure your system programmers know that and are prepared to deal with that, especially early on as they gain experience. Some places even use separate "WebSphere LPARs," occasionally even with a completely different level of z/OS as other z/OS LPARs, in order to provide a different service velocity. There are distinct technical advantages to running WebSphere in the same LPAR as DB2, CICS, IMS, MQ, etc. if your applications are accessing those resources, so there are pros and cons to this. I've seen both, even within the same company. 10. Keep well on top of IBM's patches and upgrades for WebSphere and Java, including "PSP buckets." Things move fast in the Java world. 11. HTTP session persistence becomes rather more practical on z/OS same-LPAR, IMHO. Consider turning that on selectively, if you need it. It's a nice feature. This feature means that any application or servant abend will not cause any interruption to users. If they're five Web pages deep into an ordering application, WebSphere and DB2 will cooperate to maintain that user's state and transfer state to a surviving servant for continuing processing onto page six. Very cool stuff, especially for high availability call centers. It requires a bit of system processing power to keep it going, but it's worth it for certain applications. 12. Take advantage of IBM. A lot. For example, WBSR6 and WSW06 (course codes) are free classes IBM offers fairly often. When they're scheduled, put a couple people on a plane to go. Also, build some lab contacts over time between your technical people and IBM. They're quite valuable. 13. Use the JDBC Type 2 driver if you can. 14. This stuff really does work. You can move an EAR file from the WebSphere Test Environment right up to WebSphere Application Server for z/OS and it runs. Hope that helps. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
