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.
firstname.lastname@example.org - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
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.
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).
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.
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
A R RECNAME PFILE(PF01)
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 R RECNAME PFILE(PF01)
A K FLD4
A K FLD5
A K FLD3
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.
Example of a program looping
Example of program execution result changing
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
This proposal is very important for IBM i, which emphasizes backward compatibility.