Changing a logical file, need to recompile the physical?
Hi, I work on a Cobol As400 system. I am changing a lf to make it unique instead on non-unique. Do I need recompile the pf or just the lf and any programs that access it? I have changed the lf and the i/o module that accesses it, tested it, and so far so good. However the process here is to recompile the pf and and all logicals and all programs that reference them in order to be absolutley certain to avoid problems.
Software/Hardware used:
AS400
Software/Hardware used:
AS400
ASKED:
March 12, 2012 1:19 PM
UPDATED:
March 20, 2012 10:36 AM
RELATED QUESTIONS
- Creation of logical file
- I have saved library with access path yes, however after restoring data file and index , the index path again takes time to create why?
- Do we need to compile LF when its PF changes
- AS/400: concept of Unique key
- AS400 comparing large database files, cobol code taking too long
Answer Wiki:
You only need to recompile the Logical and any programs using it.
The PF is not changing so not need to redo.
To see all answers submitted to the Answer Wiki: View Answer History.
Thanks for the help Charlie
Hi Charlie,
I have been looking at the programs that call the i/o modules. Basically, they pass linkage to the i/o module stating such things as what type of access, what file, and of course data etc. Part of the linkage is defined in working storage using COPY DDS-ALL-FORMATS OF the logical. When I look at this in the compile listing it is just seems to be defining the fields in the PF. I am not sure why it doesn’t COPY DDS-ALL-FORMATS OF the physical… but this is how all the calling programs do it.
I still don’t think I need to recompile all the calling programs, just wondering if you have any thoughts on it?
Sleepzone, I’m not really up on COBOL, but I would think it does file level checking the same as RPG/RPGLE. If you can, try recompiling the logical in a test library then running one of the dependent programs – if it blows up you’ll have your answer.
You might not need to compile anything but the LF if the format level ID didn’t change. You can probably use DSPPGMREF against any programs to see what level ID they expect and compare that against the (format) level ID of the new LF. If they match, then a recompile of the program shouldn’t make any difference.
The program doesn’t enforce unique keys. DB2 does that, and the compilation of the LF took care of that part.
Tom
Here is a quick test you can do.
Create you new Logical of the PF, but put it in a test library.
Have that library as the first one in your libl and call one of the progrms that file.
If you get a level check error on that file, you know you will need to recompile all.
If not, before you assum all is well, verify that the program did use that file.
Additionally, the compile of the logical will fail if the current data conflicts with the new rule.
I did a DSPPGMREF on all objects and confirmed that only the i/o module program references it – so all good there. I tested it using a version in a new library – all good there too. The level check on the new and old version of the lf are different, but all good since I recompiled the i/o module an it references the new level id.
Thanks for the help everyone
The level check on the new and old version of the lf are different…
A simple change from non-unique to unique should not change the format level ID. (It can definitely change file and member level IDs.)
Are you sure that’s all you changed?
There are circumstances where format level IDs can change incorrectly. If that’s the case, then you might not be finished.
Tom
Hi TomLiotta,
I had a look at this again and you are right – the Format Level Identifier did NOT change. The File level identifier / Member level identifier did change.
TomLiotta,
I’ve just read a previous post of yours regarding “File Level identifier Vs. Record Format Level Identifier vs. Member level identifier”. That explains the difference between them… Perfect. Many thanks.