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

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.

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.

【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

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

  • http://www63.tok2.com/home2/jd4/ImplicitlySharedAccessPaths.html#Incident1

• Example of program execution result changing

  • http://www63.tok2.com/home2/jd4/ImplicitlySharedAccessPaths2.html

Thanks,

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

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