delete system code

I've been experiencing the same thing. I think what is happening is that CTPs have been installing code for BR even though we don't use it. We've been ignoring it.

Hi Ben! We'd like to ignore it as well, but we're running appmetadiff -s in order to clean up the metadata before copying the product line. THe utility keeps failing because it can't find BR120 or BRIP. We've cleared out the brmeta directory hoping to allow the utility to replace all metadata, but it keeps going back, wanting to reference BR programs we don't have, in order to replace the metadata. For example, on the failures linked to BR120 - we had the BR120 code in the brsrc, but no BR120 defined in pgmdef. It's almost as if the CTP or patch didn't apply it correctly/completely. So our decision was to remove the BR system code, but that's proving difficult as well. If you have any ideas, that would be great!

To delete the system code, you do first have to delete all of the tables defined for the system code, using dbdef. You also need to remove references to them in security classes as well as table relations to those tables. I think you also need to remove libdef's and workdef's assigned to the BR system code (I don't remember if delsys does this or not, so you can try skipping this step and see if it does delete them...). You can then delete the system code, and run blddbdict/dbreorg.

Finally, make sure you delete brsrc, metadata/brmeta, metadata/databasemeta (for the tables you deleted--notice that some BR tables start with AC!), and run appmetadiff. Otherwise you will end up with the system code being re-created when you run appmetadiff later.

This whole mess drove me nuts and I finally did some research to figure out what I think causes it. My findings were:

1) that lawappinstall, when installing an MSP or CTP, looks at the XXsrc directories to determine which system codes to install (not sure why it can't look at the license file which presumably would be more accurate), and

2) if you created the product line using sysload, it creates empty XXsrc directories for all system codes.

I originally discovered this phenomenon when installing patches that included new versions of TPxxx programs, but the customer didn't have that system code, and the srgen would fail.