The DEFAULT Subschema Mapping defined in our DBTABLE is not setting the correct DBNAME when no DBNAME is explicitly set at runtime.
If I have no DBNAME set and get into OLQ specifying SIG SS=SSVDBMS1 I get error
OLQ 094062 08 Subschema contains areas which do not match to any areas in the DBNAME/DMCL combination in effect.
On the LOG we see
DB347004 Vnn Tnnn no SSVDBMS1 subschema areas map to DMCL using dbname DBSCHEMA
Based on the DBTABLE mapping it should have set DBNAME DBMSVSAM.
If I specify the correct DBNAME in the OLQ SIG statement (SIG SS=SSVDBMS1 DBNAME=DBMSVSAM) then I get no error.
Here is the DBTABLE Default SS mapping statements. As you can see, any SS that begins with letters SSV should set DBNAME DBMSVSAM.
SUBSCHEMA IDMSNWK? MAPS TO IDMSNWK? USING DBNAME SYSDICT
SUBSCHEMA IDMSCAT? MAPS TO IDMSCAT? USING DBNAME SYSDICT
SUBSCHEMA SS?????? MAPS TO SS?????? USING DBNAME DBSCHEMA
SUBSCHEMA SSV????? MAPS TO SSV????? USING DBNAME DBMSVSAM
SUBSCHEMA USDSUB00 MAPS TO USDSUB00 USING DBNAME DMLO
SUBSCHEMA SSKSUB00 MAPS TO SSKSUB00 USING DBNAME MASTRKEY
SUBSCHEMA EMPSS??? MAPS TO EMPSS??? USING DBNAME EMPDEMO
all IDMS environments
Client had his default DBTABLE Subschema Mappings in the wrong order. The Subschema he was using began with letters SSV.
In his Subschema Mappings he had SS?????? in front of SSV????? so that was the match we found and used that DBNAME.
From DATABASE ADMINISTRATION GUIDE in the USAGE section for DBTABLE STATEMENTS:
"Mapping Sequence Is Important if Using Wildcards
DBTABLE mappings are searched from top to bottom until a match is found on ssc-name-1. Therefore, you should list the most specific mapping first and the least specific mapping last."
Client modified the DBTABLE to reverse the order of the two Subschema mapping statements as directed and the correct DBNAME was set at runtime
DATABASE ADMINISTRATION GUIDE, chapter DBTABLE STATEMENTS, USAGE section.
Release: IDADSO00100-18.5-ADS-for CA-IDMS