05
Tue, Nov
7 New Articles

The Remote Journal Function

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

For many industries, 24-hour, 7-day system availability is a must. They can’t afford to have downtime or system failure of any kind. In this environment, it is difficult to have a secondary system that can assume the load should something happen to the primary system. In addition, if there is a primary system failure and a secondary system does take over, it is increasingly difficult to switch back to the primary system when necessary. With V4R2, IBM has introduced an effective and efficient way to implement a hot-backup

environment that will meet the critical demands of your shop. Come find out what it is and how it works.

Remember when backup and recovery meant restoring last night’s data from reel- to-reel tape or a magazine of 8 1/2-inch diskettes and asking the department whose data was lost to re-key everything for that day? The term hot backup was used back then, but it described the temperament of the manager and the direction of productivity, not data replication.

Later, the ability to journal data was introduced. A journal entry was written to a journal receiver for every database change made. This feature allowed data to be locally replicated. If a database file required restoring, it could be restored, and journal entries applied from the time of the last backup to the last journal entry for that database file. This method cut down on the re-keying, but what happened when the system went down?

It didn’t matter that the data was journalized; it couldn’t be accessed. This situation is one in which the more appropriate, and less emotional, meaning for hot backup would apply. Journal entries could be asynchronously applied to a remote AS/400 by receiving them on the primary system, sending them to a secondary system, and then applying them to a database file on the secondary system. In that way, if the primary system went down, the data would reside on a secondary system. Although this method decreased the risk of losing data, it didn’t completely remove it. Today, with the introduction of the remote journal function, the risk of losing data approaches zero.

The remote journal function, available withV4R2, allows you to add journals and journal receivers on a remote AS/400 that are associated with specific journals and journal

receivers on a local AS/400. This function enables you to automatically replicate data from the local system to the remote system. Those familiar with Distributed Data Management (DDM) might recognize the basic concepts behind the remote journal function. When a DDM file or data queue is created on a remote system and the local file or data queue denoted in the DDM version is modified, the modification is also represented on the remote system. This is accomplished by the operating system. No user intervention is necessary once the relationship has been established. The remote journal function does not work exactly as DDM does, but, in general, the underlying concepts are the same.

Once remote journal and journal receivers have been associated to journal and journal receivers on the local system, they are kept in sync by the operating system. Prior to V4R2, you could have implemented a hot-backup site by using the Receive Journal Entry (RCVJRNE) command (see Figure 1). In that example, the RCVJRNE program receives journal entries from the local journal and then sends the journal entries to the remote system. All of this processing occurs asynchronously to the initial operation that is causing the journal entry. If the primary system goes down before all of the journal entries are received by the remote system, the entries not received are lost.

Replacing this method with the remote journal function solves this problem by allowing replication to occur synchronously to the initial operation causing the journal entry (see Figure 2). In other words, while the database file is being updated, the journal entries are simultaneously posted locally and remotely. If that isn’t enough, the work done by the remote journal function takes place at the licensed internal code layer as opposed to the application code layer, as is the case in Figure 1. Doing the work at this lower layer improves overall system performance and journal entry replication performance.

Most of the features and benefits of remote journals are not visible in the form of new application software or new user commands; rather, they are located inside the operating system. However, to use the remote journal function, there are some new concepts, terms, and API calls with which to become acquainted.

The terms asynchronously maintained and synchronously maintained have already have been introduced but not explained. They describe the mode of journal delivery for the remote journal function. If a journal is asynchronously (*ASYNC) maintained, it passes control back to the application that initiated the journal entry on the source system without waiting for replication to take place on the remote system. An asynchronously maintained remote journal may contain several fewer journal entries than the journal on the source system, which, in turn, could cause database changes to be lost in the case of a system failure. If a journal is synchronously (*SYNC) maintained, it continues with the replication process on the remote system before returning control back to the application. This method increases the likelihood that the two journals are in sync by not buffering the journal entries before transferring them.

Journals themselves have matured with the release of V4R2. They can now be created as local (*LOCAL) or remote (*REMOTE). Local journals are the types that existed prior to the release of V4R2. The remote journal is new in town and is always associated with a journal on another system—similar to a DDM file. However, whereas a DDM object never contains actual data (it merely points to the data on another system), a remote journal contains actual journal entries received from its associated journal on another system. V4R2 introduced three new APIs that allow you to take advantage of the remote journal function:

• QjoAddRemoteJournal This API associates a remote journal on the target system with a local journal on the source system. The journal on the source system may be either a local journal or another remote journal.

A maximum of 255 remote journals may be associated with a single journal on the source system.

• QjoRemoveRemoteJournal This API removes the relationship between a journal on the source system and a journal on the target system. The journal and journal receivers on the target system are not deleted, their association with the source system is simply eliminated.

• QjoChangeJournalState This API changes the state of a local or remote journal on the source system. The state can be changed from *ACTIVE to *INACTIVE or visa versa. *ACTIVE journals allow for the deposit of journal entries into their attached receivers; *INACTIVE journals do not.

IBM figured they would give you a little taste of API calling before providing commands to perform the same functions. So, with the release of V4R3, the Add Remote Journal (ADDRMTJRN), Remove Remote Journal (RMVRMTJRN), and Change Remote Journal (CHGRMTJRN) commands were added to perform the same functions as their respective API counterparts.

Two new journal configuration methods were also introduced with V4R2: broadcast and cascade. A broadcast configuration consists of a journal that replicates entries to one or more remote journals. A journal on the source system can broadcast journal entries to up to 255 remote target systems. A cascade configuration allows a remote journal to replicate its journal entries to another remote journal. This cascading can continue to include an unlimited number of additional remote journals. IBM recommends that, if you choose to broadcast journal entries, you should do so from a target system, after the first level of cascading, so as to not impact performance on the primary system.

Once you have determined that your environment qualifies for the implementation of remote journals, you can use the three aforementioned commands or API calls to start the remote journal process. To associate a connection between a source and a target journal, use the ADDRMTJRN command or call the QjoAddRemoteJournal API. Once the relationship is established, use the CHGRMTJRN command, the previously existing CHGJRN command, or call the QjoChangeJournalState API to start the transfer of journal entries from the source system to the target system or systems.

Figures 1 and 2 show the differences between data replication prior to V4R2 and the current data replication environment. A hot-backup environment using the remote journal function is not much different than the illustration in Figure 2.

In a hot-backup environment, a remote journal is also established on the local system and associated with the local journal on the remote system (see Figure 3). If the local system fails, the remote system can assume the role of primary system and journal entries can be written to the local journal on the remote system. When the local system regains control, the remote journal on the local system becomes active and receives all of the journal entries since the failure. During normal processing (that is, when the local system is the primary system), the remote journal that is defined on the local system is not active. When it is not active, it is not receiving journal entries from the local journal on the remote system. That way, you don’t have journal entries transferring from the local system to the remote system and back again.

Any environment requiring high system availability is a prime candidate for the remote journal function. For example, in Las Vegas, many hotels and casinos use the AS/400 to run all aspects of their businesses. They cannot afford to have downtime or system failure of any kind. For this reason, they implement complex backup, recovery, and disaster plans to ensure that they are up and running all the time.

With the remote journal function used to create a hot-backup site, some of the complexity of data replication and system interchangeability goes away. The synchronous transfer of journal entries greatly diminishes the chance of losing data. Moving the receiving of journal entries to the remote systems decreases some of the workload on the primary system, while transferring the rest of the load from the application layer to the licensed internal code layer reduces the CPU cycles used for the journal process even more. In addition, the ability to create remote journals on the primary system and create local journals on the remote systems allows the ability to easily swap back to the primary system once it’s ready to assume its duties again.

You now can see how the improvements to the journal process provided by the remote journal function can increase the performance and reliability of your hot-backup site while reducing CPU cycles on the primary system. If these benefits sound appealing, you

may want to investigate your environment to see if it is ready for the remote journal function.

References AS/400 System API Reference V4R2 (SC41-5801-01, QB3AMA01) OS/400 Backup and Recovery V4R2 (SC41-5304-01, QB3ALE01) OS/400 CL Reference V4R3 (SC41-5722-02, QBAUP02) OS/400 Journal and Commit APIs V4R3 (SC41-5882-02, QB3APE02)

Journal Monitor Job

RCVJRNE exit program receives entries and sends to backup system Journal Receivers

Local AS/400 (Primary) Remote AS/400 (Backup)

Figure 1: Example of data replication to a remote system prior to V4R2

Data Comm

Machine Interface (MI)

Application Programs

Add, update, and delete operations

Database Files

Target job

Receives entries from primary system and stores them temporarily

Entries stored

Storage object

(File, data queue, data space, etc.)

Apply job

Retrieves entries and applies them to database files

Database add, update, and delete operations

Database Files

RCVJRNE requests Entries retrieved

Journal entries returned

Journaling

Local AS/400 (Primary) Remote AS/400 (Backup)

Figure 2: Example of data replication to a remote system using the remote journal function

Receiver

RCVLIB1/RCV1 File 1 File 2 File 3

Remote Journal

JRNLIB2/JRN




Application Programs

Machine Interface (MI)

Add, update, and delete operations Entries retrieved

Journaling Data

Comm



The_Remote_Journal_Function05-00.png 129x125

Application Programs




Receive and Apply Job

RCVJRNE exit program receives entries and applies them to database files



The_Remote_Journal_Function05-10.png 127x129

Receive and Apply Job

RCVJRNE exit program receives entries and applies them to database files

Database add, update, and delete operations




Files Database Files

Database Files



The_Remote_Journal_Function05-01.png 129x125




Journal Receivers Journal Receivers



The_Remote_Journal_Function05-09.png 129x125

Journal Receivers





The_Remote_Journal_Function05-11.png 129x125





The_Remote_Journal_Function05-14.png 129x125

Database

Local AS/400 (Primary)

1) Files are journaled on the primary system
4) In the event of a primary system failure, the backup system takes over as primary. This remote journal will be used to replay the changes back to the original database.

Remote AS/400 (Backup)

Figure 3: Example of complete hot-backup environment using the remote journal function





The_Remote_Journal_Function05-02.png 129x77

Transport Transport




Receiver

RCVLIB2/RCV2 File 1 File 2 File 3

Local Journal

JRNLIB1/JRN



The_Remote_Journal_Function05-12.png 129x77

Receiver

RCVLIB2/RCV2




Local Journal

JRNLIB1/JRN Receiver

RCVLIB2/RCV2 Remote Journal

JRNLIB2/JRN Receiver

RCVLIB1/RCV2



The_Remote_Journal_Function05-03.png 129x81

Local Journal

JRNLIB1/JRN

2) Journal entries from the remote journal are applied to the replica database on the backup system
3) Replica database files are journaled on the backup system

This path is only active after a primary system failure during which the backup system took over as primary, and the primary system is back up again.





The_Remote_Journal_Function05-15.png 129x81





The_Remote_Journal_Function05-04.png 60x58





The_Remote_Journal_Function05-05.png 60x58





The_Remote_Journal_Function05-06.png 60x58





The_Remote_Journal_Function05-13.png 60x58





The_Remote_Journal_Function05-16.png 60x58





The_Remote_Journal_Function05-17.png 60x58





The_Remote_Journal_Function05-07.png 129x81





The_Remote_Journal_Function05-18.png 129x81





The_Remote_Journal_Function05-08.png 129x81





The_Remote_Journal_Function05-19.png 129x81
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: