This month’s focus is “legacy migrations,” and in the next few weeks we will have a number of migration stories by customers and consultants. Be sure to regularly check in and find out how they handled some of the challenges. As the first article of this month, I would like to share my own lessons learned.
Legacy migrations is one of those terms that we often hear, but seems to come and go in waves. These days a lot of customers are redesigning old applications with newer versions. The new technology is always feared and mistrusted and the legacy technology is suddenly the best that ever was (never mind the amount of problems it used to present). Today, framework development is on the rise and skeptically received by many z/OS DBAs. Not that COBOL and SQL are in the past, not by a long shot. Most big z/OS users are still running quite a bit (and often critical) workload using this COBOL and SQL, but new development is often done using newer technologies.
One of my customers started moving away from traditional COBOL workload and started using framework development using Hibernate to access the data. Before going into some of the points of which you might need to be aware of, I’ll start with the good news: production still runs and isn’t more stressed than before.
We did hit some bumps and bruises before we hit production, but who dares say that was never the case when using COBOL and embedded SQL.
The first thing a DBA should very well be aware of is that the developer probably has never seen the SQL the way it is executed in DB2. When developers are using Hibernate to access the database, they are using Hibernate Query Language (HQL).
HQL might look somewhat similar to SQL but don’t forget it is fully object oriented and understands notions like inheritance and association. HQL is also database independent, when directing it to a relational database, Hibernate will convert the HQL into the correct SQL “dialect” of the relation engine, in our case DB2 for z/OS. This sometimes causes frustration between DBA and developer. When a DBA sees a fully expanded query passing by and wants to report this to development, it might be a while before the corresponding HQL is found.
The second point to understand as a DBA is that when a from-clause is used in HQL, it refers to a class rather than a table. It is possible that by calling this entity, child entities might be retrieved at the same time.
For example, imagine an object Order, in DB2 this might be mapped to multiple tables. Let’s assume two tables, the first one being Order_tbl and second one being Orderline_tbl. Depending on the fetch strategy set in Hibernate a HQL retrieving values from Order might retrieve data from just the Order_tbl or from both tables. If the access strategy is “eager” then hibernate will opt to go and get all the data it might need, it will get all possible child information at the moment the parent is needed. If the access strategy is “lazy” Hibernate will only retrieve the child values when trying to access them. Which one is better? Well it depends on the size of the tables, what you are trying to do etc. As a DBA it’s good to know that although an overall strategy exists for a program, the “lazy” or “eager” attributes can be set by the developer for each separate HQL.
The third thing to understand as a DBA is that in HQL there is no obligation to write a SELECT.
String hql = "FROM Order";
Query query = session.createQuery(hql);
List results = query.list();
The above example will load the complete object Order. Many developers don’t have the experience of dealing with z/OS-size tables (nothing new here, how many SELECT * or SELECT full column list would be found going through the legacy statements). So retrieving all columns might not be an issue on their development environment, but it might impact production. We once were faced with a slow SQL running in DB2 (acceptance environment), the statement wasn’t immensely complex, index usage was good and the table didn’t have many rows. The reason was that no select was used in HQL and for every row that was returned a 2Gb LOB was brought over to the application and there nothing was done with it. Lesson learned: don’t be afraid of the “new” developers - organize a meeting of some basic development rules that are expected. Similar to how you’ve been explaining to legacy developers (I hope).
The fourth item to understand is pagination is possible in your new applications, much as you did in the legacy applications. It’s fairly simple using something like:
“setFirstResult(0).setMaxResults(100)” paging your result set a hundred results at the time. It prevents from reading the entire result in to the application to discover the user only needed the top results. Be careful, much like legacy code tools, if the query materializes, the entire result set might be built, similar to a “fetch first n rows” clause with an “order by” clause.
Finally, a good developer (legacy or new) takes pride in writing optimal code and will listen to the points you’re making. On the other hand listen to new ideas this developer has. The technology might change but with a good understanding between developer and DBA, you might find it’s not that difficult to successfully migrate legacy programs to new(er) technologies.
IDUG Content Committee