Skip to Main Content
IBM Power Ideas Portal

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 (

Shape the future of IBM!

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:

Search existing ideas

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 your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Workspace IBM i
Categories Db2 for i
Created by Guest
Created on Jun 7, 2022

Implementation of restore function that does not change the state of the access path

We would like you to implement the restore function that does not change the state of the access path by implicitly shared access paths. Our customers are having trouble getting their program to do something unexpected by save and restore. We would appreciate it if you could change the specifications of the link below. Example: Implicitly shared access paths:
Idea priority Medium
  • Guest
    Jul 30, 2022
    IBM does not intend to provide a solution to this request at this time, so it is being closed.

    While it would be possible to invest in a high level switch to disable access path sharing at restore time, for most clients, the current behavior is highly beneficial.
    Since the current behavior is well documented, and there is a user controlled remediation for the situation documented in this idea, we are choosing to focus our development resource on topics that have no alternative approach.
  • Guest
    Jul 29, 2022

    While waiting for IBM's solution, you can turn off access path sharing by using the FIFO or LIFO file level keyword in the source of the logical file. In your example, change LF01 to include the FIFO or LIFO file level keyword, then when the access path is created (or restored), it won't share LF02's access path (unless LF02 also has the FIFO or LIFO keyword).

  • Guest
    Jun 27, 2022

    An example is shown below.


    A few months ago, We updated (replaced) the PowerSystem from an old machine to a new one.

    When we used a backup tape taken on an old machine and restored it on a new machine using RSTLIB, the description of the access path for a particular LF changed and the RPG application malfunctioned.

    To improve IBM i performance and save storage space, when creating an LF using the RSTLIB or CRTLF command, the access path is implicitly (automatically) shared. We understand that it is an IBM i specification.

    However, as shown below (an example of a real accident), an access path different from the definition of LF may be applied automatically, which is a problem for us.


    The details are as follows.

    When LF01 was restored with the RSTLIB SAVLIB (* ALLUSR) command, the access path was not shared before the migration, but was implicitly shared after the migration. In LF01, the access path of LF02 was shared (automatically applied) by the restore operation, and a numerical item called FLD3 was added to the access path.

    One RPG application used the FLD4 and FLD5 composite keys to handle the migrated LF01 "READE". The RPG application included the process of adding and updating FLD3 (numeric field) values for records. This process moved the record to the bottom row when it was updated. This application is designed to delete records until EOF is reached in the second and subsequent "READE" processes.

    As a result, all records that were "READE" in the FLD4 and FLD5 composite keys have been deleted. (The record in the first row that should not be deleted has also been deleted)

    For recovery, we deleted LF01 and recreated it with CRTLF, but stopped using LF01 because of the same access path sharing.

    [Improvement request / addition]

    For the RSTOBJ command, I would like you to add a function (command parameter) that does not change the access path when restoring LF.

    For the CRTLF command, I would like you to add a function (command parameter) that does not share the access path.

    We know that DB design and application design of us have some drawbacks, but we want to take advantage of wide backward compatibility and continue to use PowerSystem for a long time. Therefore, I especially want to prevent problems when updating (replacement) the PowerSystem.

    In our LF migration, we used DSPDBR information and DSPFD information before and after the migration to check the shared status of the access path based on various information on the Internet, and restored the LF in the order of LF creation for each PF.

    However, it failed because the extraction of the LF reconstruction target failed partially (because the target was partially leaked).

    If it is difficult to meet this improvement request, we would appreciate it if you could provide a tool that can make a reliable transition.

    If we replace the use of LF with the use of SQL, the possibility of failure will decrease, but the assets in the past are enormous and it will be a difficult initiative.


    <PF01 Description(Source)>



    A FLD1 15A

    A FLD2 30A

    A FLD3 5P 0

    A FLD4 15A

    A FLD5 30A

    A FLD6 15A

    A K FLD1

    A K FLD2

    <LF01 Description(Source)>



    A K FLD4

    A K FLD5


    <【After migration】LF01 Description(DSPFD LF01)>



    Implicit access path sharing. . . . . . :YES(It was NO before the migration)



    Access path owned file. . . . . . :LIB/LF02

    Member. . . . . . . . . . . . . . . :LF02

    Shared access path attributes. . . . . . . :

    Maintenance. . . . . . . . . . . . . . . . :*IMMED

    <LF02 Description (Source)>



    A K FLD4

    A K FLD5

    A K FLD3

  • Guest
    Jun 27, 2022

    Thank you for your response. There is not a related IBM Support case.

    In Japan, the implicitly shared access paths cause the program to loop or the execution result of the program to change.

    I'm sorry for the Japanese web page, but the following problems occur.


  • Guest
    Jun 25, 2022
    The IBM Db2 for i development team needs additional details about this enhancement request. Is there a related IBM Support case?

    We ask that you provide a detailed explanation of the problem or difficulty being encountered. This information is needed for us to understand and evaluate the request.

    Db2 for i development team
    IBM Power Systems Development
  • Guest
    Jun 8, 2022

    This proposal is very important for IBM i, which emphasizes backward compatibility.