The instructions for an install indicate that for the GJUPGRAD parameter, the client should specify 'YES' to do an upgrade configuration; & should specify 'NO' to do a complete base configuration. They also indicate that this variable must be NO for an Add-on install. This means that an Add-On install will generate many steps which are redundant for shops that have already installed the base product.
In this situation, the messages indicated are a very common situation to be in, and many shops get this when running an upgrade or add-on install. Basically, you can ignore these messages. A more complete description of the process from our Install group follows:
"When a client does an UPGRADE install, we attempt to update a subset of the definitions that would be done during a full base install. Some of the things that we update are the protocols (DLODPROT), the pf key definitions (DLODPFK), and the CA-ADS definitions (ADSRECDS). We expect that when we attempt to do these that we will get a number of warnings because we set the 'DEFAULT ON' parameter in the IDMSDDDL jobs, which will change ADDS to MODIFIES if the entities already exist. These warnings would generate a return code of 4 for the jobs, which is what we expect.
What we also expect is that we will be able to update these entities and that they should still be IDD OWNED. We do not expect that these record definitions are no longer IDD OWNED. If they have been used somewhere else (in a map for example) then they would be owned by another of the compilers and you would get an ERROR instead of a warning."