Filtering capabilities, automatic restart, and more!
IBM i 7.1, officially released last April 23, provides enhancements that help ensure System i will be a robust and reliable platform for many years to come. One of the greatest features of IBM i 7.1 is its capability of journaling and remote journaling, the cornerstones of many high availability (HA) solutions currently available on the market. This article examines the IBM i 7.1 enhancements to journal and remote journal and includes practical examples.
Journal Enhancement: Object Name Filtering for Automatic Journaling
On this new release, when you're journaling libraries using the Start Journal Library (STRJRNLIB) command, you can now select or omit objects to automatically start journaling based on the name of the object (name filter). This allows you to automatically start journaling new production files in the library (but not journal temporary work files if they are named uniquely).
The name filter support is available via the INHRULES parameter for the STRJRNLIB and Change Journaled Object (CHGJRNOBJ) commands. You may specify both include and omit filters. The order in which the filters are implemented matters: the last filter defined for the object is the one applied. The name filter rules apply to objects that are created, moved, or restored to the specified library. Renaming an existing object after the filter rule is implemented will cause journaling to not start for this object.
The following code will start journaling for all objects added to the library except files whose names start with WRK or TMP.
STRJRNLIB LIB(MYLIBD) JRN(MYLIBA/JRN)
INHRULES((*ALL *ALLOPR *INCLUDE *OBJDFT *OBJDFT *OBJDFT *ALL)
(*FILE *ALLOPR *OMIT *OBJDFT *OBJDFT *OBJDFT WRK*)
(*FILE *ALLOPR *OMIT *OBJDFT *OBJDFT *OBJDFT TMP*))
Remote Journal Enhancement: Automatic Restart Capability with Remote Journaling
Remote journaling is dependent on communication networks, which occasionally have problems. When communication problems are encountered, remote journaling ends. New on IBM i 7.1 is the capability to have remote journaling automatically restart when it ends because of a recoverable error (CPF70D5 or CPF70C5 messages).
On this new release, the operating system will attempt to restart the remote journal after a recoverable error. You can specify the number of attempts to be made and the time delay between them (in seconds) using the Change Remote Journal (CHGRMTJRN) command or the Change Journal State (QjoChangeJournalState) API. The restarts will happen in the QSYSWRK subsystem under jobs named QJORESTART. If restarts happen, message CPI7027 will be sent to the journal message queue for each attempt; if all restart attempts fail, message CPI7028 will be sent to the journal message queue.
The following code will attempt a restart 20 times, every 60 seconds.
CHGRMTJRN RDB(MYSYS) SRCJRN(MYLIB/JRN) TGTJRN(MYLIBT/JRN) JRNSTATE(*ACTIVE)
DELIVERY(*ASYNC) RESTART(20 60)
You can verify the maximum restart attempts associated with a remote journal by entering the following command and selecting PF16 and then option 5=Display remote journal details.
WRKJRNA JRN(SSCABRAL/JRN)
Figure 1: Verify restart attempts. (Click images to enlarge.)
Another important addition in this release is the capability to verify the total retransmissions associated with a particular remote journal. None of the previous operating system releases had an easy way to do this.
From the above screen, page down twice to the following screen:
Figure 2: Verify total retransmissions.
Remote Journal Enhancement: Filtering Capabilities
Historically, a remote journal receiver has been a duplicate of the journal receiver associated with the local journal. New on IBM i 7.1 is the ability to filter entries for a remote journal connection. Filtering out journal entries that are not absolutely needed on the target system can decrease the amount of data sent across the communication line.
Important notes about remote journal filtering:
- A journal may have different remote journal connections with different filtering criteria.
- You can have a new journal receiver generated when new remote journaling criteria is added.
- You can have a different journal receiver's library on the remote system for each remote journal filter criteria created.
- Remote journaling filtering is valid only for asynchronous remote journals.
- Remote journaling filtering requires the licensed, chargeable option HA Journal Performance (5770SS1 option 42, feature 5117) to be installed.
Remote Journaling Filtering Criteria
- Before images—for files and data areas, even before images in R/DL (Record deleted in the physical file member) and R/DR (Record deleted for rollback operation) entries
- Individual objects—files, data areas, data queues
- Program names—with qjoChangeJournalState API only
Before Images
This remote journaling filtering criteria will allow before image journal entries to not be sent to the remote journal. This is especially useful when the local journal has applications using commitment control, which require before images to exist on the source system for rollback operations. On the target system, the before image journal entries may not be of any application, so implementing this filtering option should enhance the throughput between source and target systems.
CHGRMTJRN RDB(HERA1A) SRCJRN(TEAM77/JRN) TGTJRN(TEAM77A/JRN)
JRNSTATE(*ACTIVE) DELIVERY(*ASYNC) FTRIMAGES(*BEFORE)
Note: You cannot use a before image filtered receiver for the RMVJRNCHG command because it needs the before images to roll back the changes.
The remote journaling filtering rules can be verified by using the following command and selecting PF18.
WRKJRNA JRN(TEAM77A/JRN)
Figure 3: Verify remote journaling filtering rules (no filtering by object, filter before images).
Individual Objects
This remote journaling filtering criteria indicates which journal entries associated with a given object are not to be sent to the remote journal. The default is off (i.e., by default, all entries associated with a journaled object will be sent to the remote journal). The object attribute indicates that journal entries for it should be filtered with remote journaling. The object filtering criteria can be implemented via CHGJRNOBJ or the INHRULES on STRJRNLIB commands.
CHGJRNOBJ OBJ((LIBA/WRKFILE *FILE)) ATR(*RMTJRNFTR) RMTJRNFTR(*YES)
CHGRMTJRN RDB(CHICAGO) SRCJRN(LCLLIB/JOURNAL1) TGTJRN(RMTLIB/JOURNAL1)
JRNSTATE(*ACTIVE) FTROBJ(*YES)
The remote journaling filtering rules can be verified by using the following command and then PF18.
WRKJRNA JRN(TEAM77B/JRN)
Figure 4: Verify remote journaling filtering rules (filtering by object, no filter images).
Program Names
This remote journaling filtering criteria indicates which journal entries deposited on behalf of any program(s) should not be sent to the remote journal. It is implemented via the qjoChangeJournalState API using the format CJST0500 (find information about the qjoChangeJournalState API in the Infocenter).
You cannot use a filtered receiver for APYJRNCHG when journal receiver entries were filtered by object or program, but before-image filtering is allowed.
Remote Journaling Latency
Replicating a journal entry asynchronously means that the journal entry is replicated to the target system after control is returned to the application depositing the journal entry on the source system.
Journal entry latency might occur when remote journals are asynchronously maintained (Remote Journal Delivery Mode = *ASYNC). Journal entry latency is the difference between journal entries existing in the remote journal on the target system and those residing in the journal on the source system. From a recovery standpoint, the source system might be some number of journal entries ahead of the journal entries on the target system.
In this new release, active asynchronous remote journaling on the target system will now report an estimate of how many hundredths of a second it is behind, the maximum time behind since the connection was started, and when that maximum time behind occurred.
Use the following command:
WRKJRNA JRN(TEAM77B/JRN)
Figure 5: Determine how far behind the target system is.
Easier and Faster!
As you can see, the IBM i 7.1 journal enhancements will allow better use of the System i resources—communications and storage—and will also make journal management much easier and quicker.
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