The general problem is that the TSSA sppserver and/or blasadmin utility are unable to correctly retrieve or update the appserver's settings in the database.
This results in some confusing behavior which can include, but is not limited to, the following symptoms:

1. Running blasadmin -s <instance> show all results in blank values returned

2. Running blasadmin -s <instance> show all results in values that differ when compared to the same settings shown as the running configuration in the Infrastructure Manager.  e.g. MaxWorkItemThreads is configured to 50 in the blasadmin output but the appserver overview in Infrastructure Manager for this instance shows its running 100.

3. Running blasadmin -s <instance> set <category> <setting> <value> and then blasadmin -s <instance> show <category> <setting> does not show the updated value

4. The appserver fails to start because it cannot resolve a configuration setting needed during startup.  A blasadmin show on the setting may or may not return a value

5. The appserver fails to start due to errors replacing files in the NSH/br/deployments directory (it's trying to create a new deployment for an instance that already exists)

Background to how the TSSA blasadmin utility stories and retrieves values:

In BSA version 8.6 a significant change was made to how the appserver configuration (blasadmin) values are stored. 
In 8.5 and below these settings were stored on the file system in the NSH/br/deployments/<deployment> directory for the appserver instance. 
In 8.6 and later, while these directories and xml files still exist, the xml files instruct blasadmin and the appserver to look into the database to retrieve the values for various settings. 
To retrieve the values blasadmin and the appserver will do a lookup in the database based on the derived hostname of the system.  If the hostname doesn't match or is otherwise not present in the database then a variety of the above symptoms may be observed.

Diagnostics:

Diagnostic actions should be performed to determine if there is a mismatch between the database and appserver os and then remediation will be performed under the guidance of BMC Support.

1. Copy the attached GetHostName.class to a temporary location on the appserver

2. Open a shell or command window on the appserver in the temporary location where you copied the GetHostName.class file

3. Run the GetHostName call using the appserver's JRE:

Linux:
<AppserverInstallDir>/NSH/br/java/bin/java -cp .: GetHostName

Windows:
<AppserverInstallDir>\NSH\jre\bin\java -cp .; GetHostName

The output should look something like:
InetAddress.getLocalHost().getHostName() = blapp89.example.com

4. Note down the exact output.

5.  Run the following queries as the BladeLogic database user against the BladeLogic database.
select * from application_server_deployments;
select application_server_id,host_name,app_server_name,display_name from application_server;
select * from application_server_model;

6. Record the output of each query.

7. Look at the contents of the <appserver install>/NSH/br/deployments/_launcher/app-server-launcher.properties file and look for the value of the Hostname setting and record the value.

8. Open a ticket with BMC Support and include the output returned by the GetHostName call, the two database queries, and the HostName from app-server-launcher.properties.

TSSA Defect DRBLG-112543 has been created to improve the logging/error messages that are displayed when this problem arises.  The defect is fixed in TSSA 20.02.001 release.