Recently, I completed a really large e-commerce site for one of my clients that taught me a few things I didn’t know about the AS/400. The challenge to my latest project was that I had to interface with a legacy system written in RPG III that has been around since the System/38. You know the kind of code. Just keep shoveling on functionality and never do a total rewrite. Not that that’s bad; in fact, it’s how we end up with fantastic legacy systems. Like fine scotch whiskey, legacy apps take time to fully mature into those killer applications. But did you know that all of the RPG III code is just as reusable as ILE C, RPG IV, and all these other highfalutin technologies that IBM has on the 400? Read on for the magic of stored procedures and how they saved my posterior.
The victim application is a distribution system that tracks inventory, lets people enter orders, and does accounting for a large company with 85 branch locations and a humongous warehouse. My job, like the prime directive in Star Trek, was noninterference with the native populace. In English, do no harm to the application layer, but place a Web interface for customers to reprint invoices, check stock status, order parts, and manage their accounts on top of that beast. Simple for SQL Dude, especially since the client had all of the source code, right?
Yes, to my amazement it was really simple, because the code and data was on the AS/400.
Why was it easy? First, a little background info. The systems architecture was probably like a lot of legacy 400 systems. The order entry program consisted of 25,000 lines of RPG III code with embedded presentation logic. However, the programmers had taken some of the application logic and put it into separate programs to make the application somewhat simpler and probably to gain some code reuse. For example, the code that calculated the price of a part for a specific customer was a separate RPG program that was called within the order entry program. Pass it the customer and part numbers and associated factors like the job number and phase of the moon and, whoosh, out comes the price for that customer at that moment in time. Thank goodness it was a separate program, as I have never seen a more Byzantine pricing program in my life. If I had to replicate the program logic myself, I would have been at the customer’s site till St. Swithun’s Day.
Another potential problem was all of the hairy tax calculations that are dependent on where a customer is and where the part is shipping from, especially if the customer is in a different country. Those RPG III guys saved my bacon, as the tax calculations were in a
separate program that was called with a parameter list and the tax charges returned in the list of parameters.
The system I created was built using Microsoft Internet Information Server (IIS) on an NT Server. It used Active Server Pages (ASPs) written in VBScript along with a few Component Object Model (COM) objects. When my ASP programs or COM objects needed a part price for a specific customer, I just called an AS/400 stored procedure that allowed me to use the RPG pricing program. Bam!
I didn’t have to rewrite the application logic; I got to reuse it in my Web pages. Again, when I was processing an order and needed to find out how much the Canadian government needed to be sent on behalf of my client, stored procedures allowed me to reuse the legacy code. Finally, when my order was processed and I needed to print a pick ticket, I just called the appropriate RPG III program via SQL and the ticket magically printed at the proper branch location.
The beauty of the whole approach is that I wrote only a single CREATE PROCEDURE statement for each RPG III program that I wanted to call. The CREATE PROCEDURE statement identifies the program I want to call, the parameters that are expected, and the language of the program. Once this statement is executed, and it is only executed once, the legacy program is available to me via an SQL CALL statement. And note that these programs I was calling are RPG III programs, not ILE C or RPG IV. I left the legacy code as it was and invoked its important logic from another platform to do my bidding. Again, I want to emphasize that there was no recompilation of the RPG III code, no complicated wrapper program, and no need for Java servlets or ILE service programs.
I just used the built-in facilities of the AS/400 and its amazing support for SQL standards. Now the application logic is available to any program on any platform that supports SQL. Yes, Virginia, there is a Santa Claus, and his name is AS/400.
Using stored procedures is the best way to leave the business logic where it belongs and let you place the presentation layer somewhere else. That somewhere else can be an RPG program with DDS, a VB program on a PC, or a Java servlet using WebSphere. You probably do not have to redesign and recode your legacy applications as much as you might think to make them Web available and presentation-layer independent. Some small redesign may be necessary, but overall, that would just make your code more reusable and less complicated from a management standpoint by separating the logical functions of the code into separate programs. I’m sure that if you take a look at your legacy code, you can find procedures waiting to be called.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online