Guest Blogger: Mike Otey, Senior Technical Editor for System iNEWS magazine
The IBM i is a highly successfully and ultra-reliable computing platform that’s in use in all kinds of businesses world-wide from order-entry, human resources, and education through inventory and distribution systems. I’ve worked with the IBM i system since the days it was originally called the System/38. Over time the IBM i’s secure, robust and high performance architecture has proven to be an excellent platform for enterprise level applications. However, the vast majority of today’s IBM i applications are green screen applications that are not readily accepted in this age of graphical applications.
Users and management expect today’s applications to be graphical. You can’t expect a green screen application to gain acceptance in the enterprise today – no matter how practical and useful it is. Today management won’t buy an application that’s not graphical and users will balk at using one. That said, many IBM organizations still have a number of 5250 green screen applications. These applications fulfill vital business functions and most are highly customized to meet the needs of the business. They may be run in a graphical application like the IBM i Access 5250 emulator or even the older RUMBA 5250 emulator, but that doesn’t make them graphical. Most IBM i based business are looking for ways to move these 5250 based applications to a more modern graphical interface.
If you’re familiar with my work with the System iNetwork you’ll know that I specialize in IBM i and Windows integration. I did my share of straight-up RPG programming. I programmed on the platform for more than a decade and I certainly know the ins and outs of the platform. My work led me into the areas of integrating the AS/400, now the IBM i, with Windows systems in variety of different ways.
I find it surprising that , even today, most businesses using the IBM i don’t realize or take advantage of the powerful integration features that the IBM i has.
The i in IBM i stands for integration and the IBM i has powerful integration capabilities. One of those capabilities is the IBM i’s ability to function as an enterprise level relational database platform on the same level as Microsoft’s SQL Server or Oracle. Some businesses have taken advantage of the IBM i’s standalone data capabilities to attempt to convert their existing 5250 green screen application into graphical web or client server applications.
While the IBM i is certainly a capable platform, I’ve seen mixed results with these efforts. I’ve taken part in a number of different application modernization projects over the past decade and here are some of the most important points that I’ve taken away from these projects
1. Don’t Overdo the GUI – One of the most common mistakes I’ve seen – especially in new modernization projects – is to try to do too much with the GUI. Most IBM i green screen applications are packed with information from the top of the screen clear to the bottom. For green screens this was a great idea and it lent itself well to productive work. However, attempting to bring that same type of interface design to a true graphical interface usually results in an ugly unworkable mess. Users will complain that the new system is slower than the old program and not as easy to work with.
Don’t think you can successfully do a screen-for-screen map of a 5250 application to a new graphical application. When it comes to designing a new graphical user interface, it is best to start from a blank slate and work at separating distinct logical entities on to different windows. Don’t hold yourself to model where you think you must follow the 5250 screens. More often than not, that won’t work well in the new graphical interface.
2. Don’t Assume Your Existing Programs Will Work – One really tempting thought that really appeals to many IT managers, is that you can use existing RPG program logic. This is definitely possible, but how useful those existing RPG programs really are depends a great deal on how they are designed. If they have been designed with a clear separation of user interface and program logic, then they are definitely usable. However, this usually isn’t the case. More often these programs – or even more likely subroutines – have been tied directly to the 5250 programs that call them. This type of logic isn’t easy to use from web and client/server style programs.
It’s usually better to pull this logical out and put it into a new central repository, such as LANSA’s, that can be accessed by older RPG program, as well as by newer graphical applications. If you want to get GUI quickly, then there are third party products like aXes that allow you to quickly map or generate a graphical interface on top of your existing applications.
3. Build in Performance – Another way to put this is: don’t make the mistake of falling into the trap of thinking small. Many times new graphical program interfaces fail, because test projects are initially implemented using databases and numbers of users that are too small. Small test projects often work well in small scale test developments, but when you take that same program and attempt to scale it to hundreds of thousands of users and the database expands from a few hundred rows to hundreds of thousands or rows, the little application suddenly doesn’t provide the performance it did on a smaller scale.
Many of today’s development environments are focused on client side processing. This can work in a small environment, but it can be death for enterprise scale applications. When building your new graphical applications remember to take advantage of server side processing. Platforms like the IBM i excel at server side processing and you need to design your applications with an eye to taking advantage of these capabilities.
4. Security Matters – Another absolutely vital point to remember is that client/server and web application security use an entirely different security model than the security that’s used by the vast majority of 5250 applications. Most 5250 applications are built using menu based security. Menu based security no longer functions for web and client/server style applications. These types of application don’t employ a menu-based architecture and in fact they totally bypass this type of security. To secure web and client/server applications you need to be sure to employ the IBM i’s object level security. Object level security can secure all base tables from unauthorized access. One technique that I’ve seen successfully applied in a number of cases, is to utilize adopted authority where end users are only authorized to a library containing stored procedures or programs. The stored procedures/programs have access to the base tables, but the end users don’t need direct access to the base tables.
5. Plan for complete platform integration – Another problem that I’ve seen in many application modernization projects, is the failure to incorporate all of the platform management needs that the user requires into the application. Data access frameworks like ADO.NET provide great access into the data itself, but they don’t go beyond that into the ability to work with other important application aspects like the management of spool files. Requiring users to drop back into the 5250 green screens is usually seen as failure in the application. When you’re designing new graphical applications, be sure to build in ways to access all of the different application management features the IBM i offers. Data access frameworks like ADO.NET don’t allow this, but you can get this access using custom API applications or through third party middleware like LANSA Open for .NET.
6. Plan for the future – The future definitely isn’t in 5250 green screen applications. Windows and web applications comprise the bulk of today’s applications. However, in the future there is likely to be a need for building mobile application interfaces that can be accessed on the iPhone or Android platforms. If you’re going through the effort of modernizing your application, be sure to plan for the future platforms that may need to surface your data. One of the best ways of future proofing your applications is to have your application’s business logic stored in a central repository that can be served out to any type to client application.
When embarking on your application modernization projects remember the 5 Ps: Proper planning prevents poor performance.
