0
astradyne 
370 pts. | Jun 16 2005 5:16AM GMT
When you create the logical file the qualified name of the physical file (i.e. file name and library) are stored in the LF definition.
If you create the logical file in a different library to the physical, you don’t have to have the physical file’s library in the library list to pick up the data as the logical file knows where to get it from.
That said, I have to agree wholeheartedly with the previous response that it is not good practice to have logicals and physicals in different libraries because:
a) it can lead to confusion and make maintenance difficult.
b) some change control systems don’t handle it.
c) potential locking issues during backups.
d) just because 
All the best
Jonathan
jaicee 0 pts. | Jun 16 2005 9:14AM GMT
For the reasons already mentioned, it’s best to keep logicals (LF) in the same library as the physical (PF).
It also makes restoring files much easier because the system will do all the work of sequencing the restore. If you put them in seperate libraries you have to ensure that you restore the PF first, then LFs based on the PF, then LFs based on LFs. It can get really messy!
Another thing to consider is Testing. If you create a LF in a test library over a PF in a production library and forget about it (which isn’t hard to do), you’ll have a big problem later on when you realize people have been modifying live data when testing.
We have a package written by a vendor who likes to break all of the iSeries “rules” and they’ve caused an incredible amount of problems. So we’ve created our own “rule”: A PF and all of its dependent files are considered as a group. So if we are changing or adding anything in or to the group, the whole group has to move between test and production (not just the object being changed or added).
You may want to read up on this stuff in the iSeriesBackup and Recovery Version 5 (SC41-5304-07).
JoAnnB 0 pts. | Jun 16 2005 3:20PM GMT
And as usual my company is the exception to the rules. We have some logicals in a LOGLIB and the physicals in another library. I don’t know who started that here but it was in place long before I arrived. It doesn’t get too confusing but there definitely is a learning curve. We also have a completely seperate Test machine so we don’t usually have a problem with testing. However, when we do need to change what library we want to get the file from we’ll create a test cl with overrides to the test library.
ljpaque 0 pts. | Jun 17 2005 7:25AM GMT
Another reason to try to keep the logical file in the same library as the physical file is the CRTDUPOBJ command.
If you CRTDUPOBJ a LF when they are in the same library then the LF will be attached to the PF in the destination library automatically.
cpujbl 0 pts. | Jun 17 2005 9:32AM GMT
The question isn’t really can you or can’t you put the logical into another file but why would you want to? The benefits to doing so have to be greater than the risks. Our clients have the ability to change their library lists and we have to be extremely careful about what data they are seeing so all the logicals have to be in the same library as the physical files. We have had problems where somebody accidentally compiled the logical into the wrong library and this caused problems for our clients. If the library with your logical is in the wrong position within the library list and data is being updated you could be changing the wrong data. If the library with the logical is only going to be in the liblist with the library of the physical file then why have it in a seperate library to begin with? Yes, you can compile a logical into any library you want but then you need to make sure your maintence procedures are in place like JoannB’s shop.
rigger 0 pts. | Jun 17 2005 10:03AM GMT
There is also a very large issue of restoring files should you need to. When the logicals reside in a different library than the physicals, the logicals cannot be restored unless the physical have been restored first. Could be a nightmare when you’re under pressure to get your system right.
tbfleet 0 pts. | Jun 21 2005 3:44PM GMT
All of the previous posts have been good considerations.
While our policy is to place the LF in the same library as the PF, we do have a few LF that join files over multiple libraries. These are always headaches when we need to do restores, as they must be manually created or the restore needs to be carefully monitored to be sure all the needed PF are on the system.
Good Luck
TomLiotta 7580 pts. | Oct 26 2009 6:22AM GMT
One reason to place a LF in a different library is that the LF presents a view of a subset of fields from the PF. The remaining fields cannot be accessed through the LF.
Then grant *EXCLUDE authority to the PF library. At that point, you have a secured subset of fields with no access to the secured fields.
This is an old technique that is nearly obsoleted with column-level SQL security.
Tom
