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

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.

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

Processing your response...

Discuss This Question: 8 &nbspReplies

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

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

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

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

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.

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.

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

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

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

Processing your reply...

Ask a Question

Free Guide: Managing storage for virtual environments

Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!

Share this item with your network:

To follow this tag...

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