The DEFAULT subschema mapping defined in the DBTABLE is not setting the correct DBNAME when no DBNAME is explicitly set at runtime.
If there is no DBNAME set and in OLQ specifying SIG SS=SSVDBMS1, then this error occurs:
OLQ 094062 08 Subschema contains areas which do not match to any areas in the DBNAME/DMCL combination in effect.
On the log:
DB347004 Vnn Tnnn no SSVDBMS1 subschema areas map to DMCL using dbname DBSCHEMA
(error-status 1492)
Based on the DBTABLE mapping, it should have set DBNAME DBMSVSAM.
If the correct DBNAME is specified in the OLQ SIG statement (SIG SS=SSVDBMS1 DBNAME=DBMSVSAM) then there is no error.
Here is the DBTABLE Default SS mapping statements. 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
Release: All supported releases.
The default DBTABLE subschema mappings were in the wrong order. The subschema name began with letters SSV.
In the subschema mappings, SS?????? was in front of SSV????? so that was the match that IDMS found and so used that DBNAME.
From 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."
Modify the DBTABLE to reverse the order of the two subschema mapping statements as directed and the correct DBNAME was set at runtime.