CA Tuesday Tips: Effects of doing Changes directly to NX_ROOT\bopcfg files

Discussion created by Sandra_Antunes on Sep 14, 2015
Latest reply on Sep 14, 2015 by Chris_Hackett

Hi dear community members


It is very usual that you hear from CA Support that "changes must not be done directly under NX_ROOT\bopcfg" files.


The reason for that is pretty obvious to older users of CA SDM: any fix and mainly Cumulative Fix installation will undo most of the changes - if not all - done to files under this structure. This speaking most specifically to forms and spel codes.


The configuration files are touched as well, but the main ones have a TPL (template) file which is used as reference to create the "hot" one which will be used by CA SDM.


But even following these proceedings and recommendations, it may be possible that you do some change that can cause a problem when using SDM.


Recently a customer was not being able to run the ldap functionalities in his pre-production environment and was able to do the same on the other environments; Test and Dev.


All the main files had the same content.

The pdm_ldap utilities were working on the other environments and not on Pre-prod - except for pdm_ldap_test.

The message received when importing a contact via LDAP Merge button (as well as pdm_ldap_import and sync), for example, was generating the following entry in stdlog:


AHD04013: internal error in method ldap (got_ldap_domset): AHD03053: INVALID WHERE CLAUSE:

Parse error at: "ldap_domain = ? AND userid = ?" (Attr not found or not atomic)


The reason for that was customer tried to add some customization to ldap mapping by modifying ldap.maj under NX_ROOT\bopcfg directly.

As this didn't work (for other reasons), he edited the file and removed the customization done.

All was working fine until he installed CF1 for SDM 12.9. This is when the problem started.


CF1 introduces a functionality to SDM 12.9 in the LDAP area which is ldap_domain attribute (at the object level), which allows SDM 12.9 ldap tools to work with multiple LDAPs (this has been incorporated to SDM 14.1).


We verified the ldap.maj from CF1 was not installed because the one under NX_ROOT\bopcfg was newer than the one from CF1 - yes, editing and saving the file changed it's timestamp.


Resolving the problem was easy - we copied the ldap.maj file from the CF1 package manually on top of the installed one -; but this is an example of the type of "defect" that can be introduced to your environment when doing changes directly to files under NX_ROOT\bopcfg.


Have all a great week!