Error updating Spectrum Global Collection - The dynamicCriteriaXML attribute does not exist for the model

Products

• CA Spectrum

Issue/Introduction

An error is seen when trying to edit a Global Collection:

<Global Collection Name>: The dynamicCriteriaXML attribute does not exist for the model. An Event is generated: SPC-OCC-11818: Model Write Failed: The dynamicCriteriaXML attribute does not exist for the model.

Environment

Any version of Spectrum
 

Cause

This may be caused by a potential corruption between a Global Collection and the associated landscape(s). It may also be caused by hostname mismatch. 

Resolution

Option 1: Remove and reassociate landscapes

From the OneClick console (GUI): 

1. Right click on the affected Global Collection

2. Locate and click "Edit Global Collection..."

3. Click the "Landscapes..." button

4. Associate another landscape with the Global Collection

5. Remove the "correctly associated" landscape from the Global Collection. This will remove the model and association from that landscape

6. Click OK

7. Click the "Landscapes..." button

8. Re-associate the correct landscape with the Global Collection and remove the landscape you don't need

9. Click OK

10. Click the "Search Options..." button

11. Add your search criteria

12. Click OK when done. The search settings should be saved without an error and the Global Collection should update

13. Modify the search criteria and validate again that the settings are saved and that the Global Collection is updated accordingly

14. Modify one last time with the settings that you require. The Global Collection search options should save and the Global Collection will be updated accordingly

If the above steps fail to solve the issue, then proceed to option 2.

Option 2: Check hostname resolution and .hostrc for proper configuration

1. Review the .hostrc file for each SpectroSERVER landscape and OneClick server 

- <SPECROOT>/.hostrc

- Each .hostrc file should look the same / be consistent. Each .hostrc for each landscape should appear identical.

- If using hostnames in .hostrc, then each .hostrc should contain ALL hostnames (landscape and OneClick servers included)

- If using the catch-all "+" in the .hostrc, then no hostnames should be used and all .hostrc should have a "+"

- Remember to be consistent - if using "+", then only use "+". if using hostnames, then include all hostnames in all .hostrc files

2. Review the /etc/hosts files (if in use)

- Similarly, the etc/hosts on each server should also be consistent / be identical / contain all server hostnames

NOTE: If using third party file synchronization utilities to propagate .hostrc and /etc/hosts changes across the network to the servers, check to make sure the third party app is not adding any formatting to the files which may prevent SpectroSERVER landscapes from reading the files properly.

If the above steps do not solve the issue, it may be possible the landscape itself is corrupted. In this case, you may proceed to Option 3

Option 3: Reload last known good backup database

1. First determine which landscape(s) ​ is causing the error

- Using the steps from Option 1 above, isolate the landscapes associated with the Global Collection one at a time and see which landscape associated with the Global Collection causes the error

2. Once the corrupted landscape has been determined, log into that server landscape and use Spectrum Control Panel to load the Last Good Backup from the time prior to when the error started occurring. 
 

Option 4: Initialize to the legacy database and do a models only load of the current database.

1. First determine which landscape(s) ​ is causing the error

- Using the steps from Option 1 above, isolate the landscapes associated with the Global Collection one at a time and see which landscape associated with the Global Collection causes the error

2. Once the corrupted landscape has been determined, Login to that SpectroSERVER and bring up a bash shell.

3. Navigate to the $SPECROOT/SS directory.

4. Run the following command: ../SS-Tools/SSdbload -il legacy.SSdb

5. Run the following command with the last known good database: ../SS-Tools/SSdbload -m <database save>

Additional Information

If none of the above options helps to resolve the error, then we would suggest to open a Support case for further investigation and troubleshooting.