This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
See this idea on ideas.ibm.com
When journaling is started on a library, you can created inheritance rules which will cause journaling to start on objects of type *file, *dtaara, and *dtaq. When indexes are created over tables the object gets journaled (type = *file) but not the access path for the object. There is no provision to allow us to automatically cause an access path to be journaled. This does not make sense. Journaling the object header for an index or logical file, while helpful, does not really do much for you. I would like IBM to provide the ability to allow us to specify that objects with access paths start journaling automatically as they are created.
Access Paths rebuild time is a key determinant in how long it will take to recover a system in the event of a failure. The system uses SMAPP to try to keep the access path recovery to 50 minutes, but this is not good enough. We are implementing PowerHA and would like to have all access paths journaled so that in the event of an unplanned switch we're as up to date as possible. Without the ability to have access path journaling started automatically, we are left to having to remember to do this, implement this in our change management system (not sure if this can be done), or write our own utility to program to review access paths and determine if they're journaled. It does not seem consistent that all files and indexes can be journaled, but not their access paths.
Idea priority | High |
By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.
IBM does not intend to provide a solution to this request at this time, so it is being closed. As mentioned earlier in the discussion, there are existing solutions for this request.
The CAAC has reviewed this requirement and recommends that IBM not implement this request. There are work-arounds as described in comments below.
Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.
For more information about CAAC, see www.common.org/caac
For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/
Nancy Uthke-Schmucki - CAAC Program Manager
50 minutes is the default for SMAPP, but you can reduce that time using CHGRCYAP.
It would typically not be a best practice to implicitly journal every index in a library.
For example, an index over a relatively small table that is used as a queue (such as some 3rd party applications do) is heavily updated, but the index is small so the recovery time will be trivial while journaling it will end up causing a lot of extra space in the journal.
If you are going to explicitly journal indexes at all, a much better practice is to perhaps explicitly journal only larger critical indexes but use SMAPP to journal all others.
Joe, if you implement Quick-EDD/HA - Tools, you will not have to worry about this.
https://www.syncsort.com/en/products/Data-Availability/Quick-EDD-HA