Journals are what allow for commitment control on the AS/400 platform. Many legacy applications that come from the System 36 were not written to use journaling and have never been rewritten to take advantage of commitment control. Also, journaling takes disk resources and can impact system performance if an AS/400 is already running near IO capacity, so a lot of shops will not allow journaling to be added to their physical files.
In the SQL world—which is also the Web world, as SQL is the most prevalent way of talking to databases from Web applications—commitment control is expected. Most Web application designers would balk at not having commitment control. Well, guess what: Designing Web applications that talk to legacy nonjournaled physical files require special consideration. Let’s review commitment control and take a look at a technique to minimize exposure to potential problems.
A Review for the Uncommitted
For those who may not be familiar with commitment control, let me review. If you have a physical file on the AS/400 and associate the physical file with a journal, you can now design applications that use commitment control. If an application uses commitment control, it means all entries/changes/deletions written to any journaled files will have the changes first recorded in the journal and then in the physical file. In order to make the changes permanent, the programmer calls commit. Commit causes the changes to the physical file to be considered complete. If, during processing of a program, the programmer decides to undo his changes to the physical file(s), he can issue a rollback. The rollback is like a big AS/400 undo button that will back out all changes to the physical files up until the last commit or rollback. In addition, if an application under commitment control abends, any changes that the programmer had not explicitly committed will be removed automatically from the physical files. Commitment control is like quality assurance for your data. A properly designed system with commitment control will never have half-entered invoices or dangling parent-child relationships because of program or system failure.
Most RPG and COBOL AS/400 legacy applications were written with the idea that the code could not fail. This belief is the result of the AS/400 being such a robust platform, the fact that those systems are all hosted on a single, integrated platform, and the fact that multiple database writes from terminal emulation sessions are usually batched during a single program process. The terminal data was probably good, because the programmer wrote code to ensure that any parts added to orders existed in the parts table, that quantities were positive numbers, etc. The programmer also had a lot of control over the order in which operations were performed. He could ensure that the user performed step A, then B, and finally C.
It’s a Web Wide World
In the Web world, you do not have control over the order of operations that the client initiates. Also, clients can bookmark pages and jump past steps you might want them to perform. In addition, you are now running from multiple platforms and adding points of failure to your system. What happens if the TCP/IP link goes down during a transaction? What if the Web server crashes during order posting? These were not questions you had to answer when writing legacy applications, but they are things that you have to deal with under the Web and client/server models. What do you do?
Designing for No Commitment Control
For those who can’t have commitment control, all is not lost, as you can design your interfaces to your legacy system to minimize the fact that you have no commitment control. It takes a little forethought, but the process is not that hard. I just interfaced with a system where commitment control was not an option. In this article, I will review the design, discuss the failure points, and then show you how to minimize them.
My victim application is a legacy warehouse/distribution application that has over 1,000 physical and logical files and 2 million lines of RPG III code. I was tasked to write a Web-based order entry program. I’m concerned with the following files: order header, order detail, and warehouse item master. There is batch-oriented code for updating the accounting and other tables, but some quantity information must be adjusted at the time an order is placed into the system. The legacy terminal application allows a user to define an order, add items to the order, and then post the order. During posting, the order header is written, and then each item on the order is posted to the order detail table. As each detail item is posted, certain quantity values in the warehouse item master table are debited and credited.
When designing Web interfaces, you face a lot of problems. Web applications are usually multiplatform. The Web app may be running on a Linux box, Windows 2000, or AIX while the data is on the AS/400. Even if the Web app is on the AS/400, it is not immune to failure. The Web application may be running in Java or using technology such as Active Server Pages (ASP) and communicating via SQL or record-level access. There can be inadvertent bugs in the application code that cause the app to crash, unexpected record locking issues that cause it to halt, or communication link failures that cause a half order to be written. These are all bad news. Remember that these Web apps are new and not time-tested like the legacy system. You are putting more moving parts between your data and your user. More moving parts create more points of failure. Alas, if you had commitment control, these dangers would be slightly less of an issue. But that is a perfect world, and this is not.
The First Design of the Web App
The first design of the Web order entry system that interfaces with the legacy system stores the parts a user is selecting in a physical file on the AS/400. Because Web applications have no inherent state; items that a user selects must be written in a physical file. As the user selects items and specifies quantities, the items are written to the table under that user’s
ID, but no quantity adjustments are made, (just like the legacy system). When the user finally is finished playing with his order, either today or next week, he presses a button to initiate order processing. The Web code validates each part price and ensures that the part is still available. It then writes the order header record to the target physical file. The code proceeds to write each item detail to its respective file and adjusts the warehouse item master quantities via SQL statements. The Web app then deletes all of the parts from the physical file used to keep order state, as those parts are now part of an order. If this code completes, I have a good order posted to the host system and am ready for the user to do another.
However, if there is a failure at any time during this critical processing, there is no way to undo the order. What if the router goes down during the writing of the detail records? What if the server runs out of memory and halts? What if the order is posted but the state table is not cleaned up and the user processes the order again? I have no control in this situation and am relying on the byte gods to ensure that the data gets where it is supposed to go. This is bad design. This is the critical area of processing that has multiple modes of failure waiting to swoop down and wreck my evening.
To protect yourself in your application design, you need to identify these critical failure portions of your Web application. Then you have to look at how to minimize the communications required to perform the operations. What you want to do is have one point of call to process the order so that, once that call is made, you are sure that either the order is posted completely or nothing happens at all.
Minimizing Failure
Here is an outline of the approach I used to minimizing failure within the posting process. The biggest point of failure is the writing of the order records to the physical files and updating the quantities. The approach I took was to write to empty copies of the physical files in QTEMP and then call a stored procedure for final processing. I made these QTEMP targets using the Copy File (CPYF) command. It doesn’t matter if you are using Java Database Connectivity (JDBC), ODBC, or ActiveX Data Object (ADO): You can always execute any AS/400 command as if it were a stored procedure. By executing the following command I cause an empty copy of the order header file to be written to QTEMP.
CPYF FROMFILE(ORDMST/ORDHDR) +
TOFILE(QTEMP/ORDHDR) +
CRTFILE(*YES)
This command would be followed by more commands that create empty copies of the order detail file and other targets of insert operations in QTEMP. After making the empty copies, the Web application posts the order header and detail records to the QTEMP copies using the same INSERT statements it would have used to write to the target physical files. Finally, the Web application program calls a stored procedure on the AS/400. This stored procedure could be written in CL, RPG, or COBOL. In my application, it is in CL but the CL program also calls an RPG program. The RPG program updates the quantities on hand in the master warehouse item table by reading the quantities ordered from the files in QTEMP. Because the stored procedure runs in the same job as the Web program, it can see all QTEMP files that the caller may have created. Then the RPG program calls the legacy program to retrieve an order number and updates the QTEMP records to have that order number. Control returns to the CL program which then uses CPYF to copy the data from the QTEMP physical files into the target physical files in the production system. Finally, the CL program calls another RPG program that removes the state records from the state table so that the user is in a clean, new order. Once the procedure is finished, it returns the order number that was issued to the calling program.
The beauty of this approach is that the only point of critical failure now resides on the AS/400. Using this method, it doesn’t matter if my application fails during the writing
of the temporary files. The AS/400 will automatically delete the temporary files because they are in QTEMP. Suppose the application call writes all of the temporary files and calls the stored procedure but fails before the procedure completes and returns control to the calling program. Big whoops! The procedure will complete and then attempt to return data to the calling program. The data return will fail, but the results of the procedure are still complete.
Living without commitment control is like living without coffee or Jolt cola. It can be done; it just takes some adjustments to your mode of thinking.
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