Think of journal management as a tape recording of everything that happens to your data. These moment-by-moment changes to the database, whether by one user or by twenty, represent an almost bullet-proof audit trail. With journal management, you can actually rewind this tape to any particular point in time and replay the transactions, one by one. Even if the database file itself is lost, the journal management process can actually re-create the file's contents from the recorded transactions. For this reason alone, journal management is often considered the premier recovery strategy for the AS/400: The database can be resurrected to any point in time from the journal entries.
Journaling is also commonly discussed in the context of commitment control. Commitment control is one journal function extension that allows you to define and process multiple database transactions as a single unit, providing an application the ability to synchronize complex transactions. For example, let's say a user enters a complex order in which customer information, billing information, order information, and order line information are entered and numerous files are updated. What if the user wants to back out an order? A significant amount of programming would be required to back out the multiple transactions and synchronize the database. Commitment control greatly simplifies this effort. It's the creme de la creme of journal management utility. Consequently, after you've become familiar with the larger topic of journal management, you'll probably want to learn more about commitment control. The purpose of this article is to introduce you to the full functionality of journal management. In a subsequent article, I'll show you how to use journaling with a hands-on example of commitment control programming.
Why spend so much time with journal management?
It's surprising how few AS/400 shops actually implement journaling. Even shops with transaction-logging requirements frequently miss out on the capabilities of journaling. Sometimes these shops spend months writing custom code to perform a limited set of the same transaction auditing facilities that journal management provides free. If these same shops spent just a little bit of time looking at journaling, they could save their companies months of programming time.
I'll explain how journaling works and discuss all the various underlying capabilities that this feature of OS/400 enables. When I'm done, you ought to be able to revisit the topic of journal management with a better appreciation of how to make this powerful function work for you.
Journaling is a built-in OS/400 process. Anytime a user sends an instruction to change an object, OS/400 is watching. If you've set up journal management for the object, a notification is sent to a journal-a special kind of OS/400 object-and a journal entry is created. The journal entry is a picture of the event that OS/400 is monitoring. The entry is then written to a specifically designed, unalterable object called a journal receiver.
The journal receiver-the container into which OS/400 writes its journal entries-is a true audit trail: no one on the system can manually modify its contents, so there's never any question about its accuracy. You can, however, display the contents of the journal receiver anytime. Inside, you'll discover a surprising number of different types of entries, including a time stamp, a user ID, a job ID, and (if the journaled object is a database file) a picture of the actual record after it was changed. You can also configure the journal receiver to maintain a picture of the record before the record is changed.
Journal receivers are the keys to the functionality of journal management. Within a journal receiver, OS/400 can store the transaction logs of multiple database files that are intimately related-for instance, all A/R detail and master modifications. Displaying the journal receivers for these files would show you every action affecting these files: who, what, where, when, and how.
But more importantly-beyond merely showing-the journal receiver contains the actual transactions themselves, in a strict sequential order. These transactions are like recorded "keystrokes" in a compressed format that you can display but not alter. Most significantly, you can replay these key-strokes to re-create events when necessary.
Why would anyone want to record the moment-by-moment life of a database file? Who, besides an auditor, would really want to be a database voyeur?
Many basic, highly functional OS/400 features are facilitated by the capabilities of journaling. Some features use journaling in a very transparent manner-allowing OS/400 itself to manage the journaling process. Others-depending on Rochester's integration of journaling-require you to set up and maintain the journaling process. Here's a list of the functions facilitated by journaling.
Save While Active: The Save While Active function allows you to back up a database file even while your users are still pounding it to death with new transactions. Save While Active uses a journal receiver to capture all the keystrokes and commands sent to the file being saved. While those keystrokes are being captured, however, the actual database file is locked by the system and being saved into a Save File. When the system finishes the save, the journal receiver reattaches to the file, and the system applies the journal entries, updating the file.
SMAPP: The System Managed Access Path Protection function of V3R1 is also facilitated by journaling. SMAPP cuts down on how long it takes to IPL after an abnormal power down by automatically maintaining a journal receiver of the most highly volatile access paths. Instead of rebuilding all the access paths that were in transition when the lights went out, SMAPP plays back the transactions from a system-maintained journal receiver. This function can significantly cut IPL time and get your users back on the system quickly.
Backup and Recovery Strategies: Most often, journaling and journal management are the keystones of well-constructed backup and recovery strategies for critical data. Journal receivers are created for files that are critical to the organization's work flow and then are saved at specific intervals. When a catastrophe strikes-due to natural or man-made causes-you can count on the saved journal receivers to contain the accurate play-by-play recording of the most important data. At any time, you can apply the journal receivers to the most recent backup to make the company's database current. And, since you can maintain multiple journal receivers simultaneously in two separate auxiliary storage pools (ASPs), the potential for a hardware corruption of the data is substantially decreased.
Commitment Control: Journaling makes possible one of the AS/400's most powerful database orchestration tools: commitment control. Commitment control allows the programmer to modify records across multiple files-on multiple AS/400s-with the most complete control of any operating system of any midrange system. If the process of updating any individual record fails-because of hardware problems, a communications error, or just plain operator blunder-the programmer can halt the multifaceted transaction and actually "back out" the modifications to the affected files. Journaling facilitates this finely tuned and highly robust capability by acting as the auditor of each transaction. If the programmer doesn't like how a complicated set of transactions is progressing, journaling and commitment control allow him to change his mind midstream.
Setting up journal management involves three basic technical steps:
1. Using the Create Journal Receiver (CRT-JRNRCV) command to create the journal receiver object to hold the journal entries.
2. Using the Create Journal (CRTJRN) command to create the journal object that controls the journaling process to the journal receiver.
3. Using the Start Journal Physical File (STRJRNPF) command to identify the database files to be journaled.
Following these steps creates a process by which OS/400 updates files, as shown in 1. In this figure, two programs update physical files A and B through the journaling process. OS/400 sends the updated data first to the journal, which writes an entry to the journal receiver, and then back to the file. There are both good and bad implications to this structure.
Following these steps creates a process by which OS/400 updates files, as shown in Figure 1. In this figure, two programs update physical files A and B through the journaling process. OS/400 sends the updated data first to the journal, which writes an entry to the journal receiver, and then back to the file. There are both good and bad implications to this structure.
First, the good news: there's absolutely no physical way that a journaled file (such as File A in the figure) can be changed without writing an entry to the journal receiver. This includes any change by any program, even if that program is a PC program running through the network. The journal receiver can even contain an entry for every time a file is opened for update. This removes the need to continually maintain and track all the potential programs and utilities that access the files. It also means there's no opportunity for an incomplete update of the audit trail.
The bad news is exactly the same as the good news, however. If a journal receiver eats up all the DASD assigned to it, there's absolutely no way for any program to update the files that are being journaled. This means that journaling requires management, planning, and-when journal receivers become filled-operator intervention.
To cope with some of the inherent management requirements, V3R1 has now significantly enhanced OS/400's ability to automatically manage the journaling process. For instance, you can set the journal receiver to automatically inform OS/400 when a threshold of journal entries has been exceeded. OS/400 can then automatically detach the journal receiver and create a new one to hold the next group of entries. The process can remain transparent to the system operator, or you can configure it to send a message to the operator telling him to load a tape and save the filled journal receiver. These management enhancements allow journaling to become part of the regular work flow of the system operator.
Beyond the logistics of managing the journal receivers, programmers have larger questions to answer-most importantly, which files should be considered for journaling.
Generally, you can use the following criteria to identify files that are potential candidates for journaling:
o Files that receive a high volume of transactions between save operations.
o Files that would be difficult to reconstruct if lost.
o Files that are critical to the operation of the application, such as master files.
o Files with complicated or entrenched interrelationships, such as order entry/sales/accounts receivable/inventory relationships.
By the same token, you should analyze the situation carefully when considering journaling for the following:
o Files that use triggers or referential constraints. IBM wisely chose to alter the manner by which triggers and referential constraints function during the journal entry reapplication. You wouldn't want triggers automatically firing off during a recovery, nor would you want the recovery halted by referential constraint violations. IBM's implementations of these functions during journaling are still fully supported (indeed, journaling enhances their functionality), but there are some detailed differences in the steps by which they achieve their objectives. You may want to look at the IBM DB2/400 Redbook Database 2/400 Advanced Database Functions to bone up on the differences.
o Database source files. Programs like SEU, which replace the entire source member when an edit is completed, create journal entries for every record-even those that have not been modified. This activity could quickly push the journal receiver to its threshold or-if no threshold has been configured-consume all available DASD on the journal receiver's assigned ASP.
There are other management concerns as well:
o Should you journal objects that the system does not journal, such as a data queue or a data area? OS/400 doesn't provide a built-in means of writing journal entries for these unique OS/400 objects, but that doesn't mean they're not important. To accomplish this function, you'd have to write your own program to create the journal entry, and then use the journaling API to send that entry into the journal receiver.
o Should you use access path journaling? This could save you a lot of IPL time after an abnormal shutdown, but the downside is that you must also journal the associated physical files. Also, only those access paths related to keyed physical files can take advantage of journaling. (SMAPP, however, doesn't have the same constraints, and you might want to check it out as a specific feature.)
o How should files be assigned to journals? You could have one journal receiver handle all the journal entries for all of your files. Alternatively, you could create multiple journal receivers to spread the load for the entire system. There are advantages and disadvantages to both approaches. A single journal is simple to maintain but could create a performance bottleneck. Look again at 1. The journal receiver gets updated before the database file. Now, imagine the performance hit your system would experience if all of your updates were passing through a single journal. On the other hand, the multiple journals for separate files could seriously complicate your recovery strategy, especially if two separate journals were logging out transactions for two separate-but intimately linked-database processes.
o How should files be assigned to journals? You could have one journal receiver handle all the journal entries for all of your files. Alternatively, you could create multiple journal receivers to spread the load for the entire system. There are advantages and disadvantages to both approaches. A single journal is simple to maintain but could create a performance bottleneck. Look again at Figure 1. The journal receiver gets updated before the database file. Now, imagine the performance hit your system would experience if all of your updates were passing through a single journal. On the other hand, the multiple journals for separate files could seriously complicate your recovery strategy, especially if two separate journals were logging out transactions for two separate-but intimately linked-database processes.
o Should you journal before-images? You can take snapshots of a transaction both before and after the updating, but it doubles the DASD required.
o Should you use dual receivers? This option allows a journal to write the same journal entry to two synchronized journal receivers.The advantage is that you can shove one journal receiver onto one ASP and keep the other completely separate. If you lose a disk drive or if one of the journal receivers gets damaged, you have a second shot at recovering your data. The disadvantage is, simply, it doubles the DASD required.
o Should your journal receivers be in a user ASP? The journals themselves must reside in the same ASP as the database file, but the journal receivers can reside in a separate ASP. This can be both a performance and a safety advantage. By slipping the journal receiver into a nonlibrary ASP, the I/O associated with a record update is spread across multiple disk's arms, eliminating performance bottlenecks.
In a word, yes! AS/400 shops that don't use journal management are simply not using OS/400's unique architecture to its fullest. Journal management is essential for a well-rounded backup and recovery plan, and-at the very least-it's a significant change management tool for those who have the intelligence and wisdom to use it. It can increase system availability to your users by making certain every transaction is captured and recoverable. It can monitor the access to your system without making you write a single lick of code. But, most importantly, it's not some add-in conceived and implemented in a moment of security panic. It's a real, live, powerful, robust, systemwide implementation of a magnificent database function. And it comes to us free, compliments of OS/400. Thanks IBM! Here's one you really got right.
Thomas M. Stockwell is a senior technical editor for Midrange Computing. He can be reached by E-mail at
REFERENCE
Database 2/400 Advanced Database Functions (GG24-4249, CD-ROM GG244249).
Journal Management on the AS/400
Figure 1: Processing Files with Journaling
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