Skip to Main Content
IBM Power 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:

Post your ideas

Start by posting ideas and requests to this portal to enhance a Power product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas and add comments to ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The Power teams will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notification on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.


Specific link you will want to bookmark for future use

IBM Unified Ideas Portal - https://ideas.ibm.com/ - Use this site to create or search for existing Ideas across all IBM products that are outside of Power, and track all of your personal interactions with all 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: https://www.ibm.com/docs/en/i/7.5?topic=files-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.


    【Overview】

    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.


    【Detail】

    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.


    Ex.

    <PF01 Description(Source)>

    A UNIQUE

    A R RECNAME

    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 R RECNAME PFILE(PF01)

    A*

    A K FLD4

    A K FLD5

    A*


    <【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 R RECNAME PFILE(PF01)

    A*

    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.

    Thanks,

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