What are the steps needs to be followed while removing Key Fields from PF.

695 pts.
Tags:
AS/400 DB2
AS400 physical file
DB2/400
Physical File
Hi, i have got a requirement to remove the Key Fields from the PF. Can anybody please suggest what are all the sequence of steps i shd follow to incorporate this changes to avoid any issues in Production after change. As per my knowledge below are the steps i am planning to follow, please confirm. please note we are using IMPLEMENTER as Change Management Tool. 1. Checkout the PF from Production to Dev Library 2. Edit the DDS of the PF and Remove the Key Fields. 3. Find the dependent programs and make this file non keyed in F Spec 4. Promote the PF and Programs to production. Please advice if any mistake in the above process. Thanks, Mohan

Answer Wiki

Thanks. We'll let you know when a new response is added.

Steps for removing the key fields on a physical looks fine.
But, The approach will be difficult and it may need lot of effort if we proceed as per these steps.
And, this complexity is based the number of programs the file is using. Because, You will need to change all these programs(not just changing the F spec and Recompiling).

You can have a look at the process suggested by “Yorkshireman”

You can Rename the physical file and modify it by removing Key fields, and have a Logical File with the name of initial PF.
and then, Find out all the programs which are using the File.
There maybe no need to change the F – Spec, it just Requires Recompilation of all the Related programs for having the File Identifier of LF.

I suggest, not to have Key fields for Physical File.
You can have LF with the required Key fields.
The advantage of having this approach is, In future if we get a new program which needs to use the same file but with different Key fields combination, There will be need of re-compiling all the programs associated with that PF.

Pradeep.

Discuss This Question: 8  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    3. Find the dependent programs and make this file non keyed in F Spec The steps are fine except that this step needs a lot of added work. If the program's are currently accessing it as a keyed file, you won't be able to recompile after changing the F-spec. You will also have to change any I/O statements that reference keys and change all of the logic that relies on keyed access. That might take a lot of work. Is there a reason for removing key fields? That doesn't seem like a very good idea to begin with. Tom
    125,585 pointsBadges:
    report
  • Yorkshireman
    Thinking aloud.. Couldn't you define an access path with the name of the keyed physical and rename the real physical to something else. Would the file levels remain the same? I'd have to spend a bit more time than I have to look at how to 'fool' the system
    5,580 pointsBadges:
    report
  • WoodEngineer
    What is your goal for this change? If you want to be able to process the file without keyed access, the file can be declared in the F-spec with out the "K". The file can then be processed in arrival sequence and or course by RRN.
    6,765 pointsBadges:
    report
  • PGMBOB
    There is an approach that teaches that the Physical file should not be keyed for design reasons. Naming standards in some installations might be impacted if the access is moved to a logical file. Define a logical (if not already defined) with the keys of the physical. Search for each program using the physical and replace with the Logical. Check CLP and copy and backup commands. When your satisfied that nothing references the original Physical you may CHGPF with the DDS source with no Keys defined.
    1,150 pointsBadges:
    report
  • TomLiotta
    If the file wasn't being accessed by key, there wouldn't have been any reason to specify 'K'eyed access on the F-spec in the first place. But it's possible that original programmers declared it as a keyed file without doing keyed access (other than simple sequential-by-key I/O). So, I suppose there is a possibility of being lucky. Even so, there are few files that I wouldn't assign a primary key to nowadays. The key doesn't have to be used, but it's sure nice to have when a need comes up. It'd still be useful to know the purpose of removing a key in case an alternative can be suggested. Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    There is an approach that teaches that the Physical file should not be keyed for design reasons. Trying to remember way back -- many versions/releases back, you couldn't create logical files that didn't have keys. At that time, if the PF was keyed and the index received damage, it was very difficult to recover records by using a tool such as CPYF to copy records purely by record number. So, PFs were generally created without keys in order to have a reliable arrival-sequence access path. When non-keyed LFs became available, there was no longer a big reason to leave keys off of the PF. A simple LF provided non-keyed access. Besides, damage to database files also started to be rare events which removed most issues anyway. There are files that have no need for keys. Naturally, 'flat' text database files are examples. I suppose examples could be given for a couple other types. Tom
    125,585 pointsBadges:
    report
  • Mohan K
    [...] What are the steps for removing key fields from physical files [...]
    0 pointsBadges:
    report
  • Mohan K
    Hi All, Thanks for your suggestions....
    695 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following