The Quantum specification
Writing a Quantum specification to analyze data, or to generate a Quanvert database, is a complex and time-consuming task. Using the MDSC capability of Quantum DSC (sometimes called mrQtSpecDsc) to create a basic Quantum specification can reduce the time it takes and the likelihood of errors, because it sets up axis and tab statements for the questions and variables in the questionnaire definition. Quantum DSC bases the specification on the card, column, and punch layout defined in the questionnaire definition.
The Quantum specification is created in a number of separate files, which have been designed to be easy for the Quantum specwriter to modify in order to create the precise analysis that is required. The following files are created:
Filename.run
Contains an edit section, struct and a statements, and include statements that reference the .qax, .tab, and .ban files.
Filename.qax
Contains l statements that creates a Quantum axis for each variable that is defined as visible (see below).
Filename.tab
Contains a tab statement for each axis against a banner (which is defined in the .ban file).
Filename.ban
Defines the banner, which consists simply of an n10 base element.
Filename.n10
Defines an n10 base element, which is used in all axes.
NumericGrid.i
An include file is created for each numeric grid. The names of these files are based on the axis names.
Filename is the name of the file defined for the export. Typically, a filename of no more than eight characters is used, in order to conform to the Borland 8.3 filename requirement.
Because the names of the numeric grid include files are based on the axis names, exporting Quantum specifications for more than one project into the same folder will overwrite any numeric grid include files that already exist in that folder with the same name. It is therefore generally preferable to use a different folder for each questionnaire definition file.
Which axes are visible?
Variables are defined as visible if the QTVisible custom property is set to True. If this custom property has been set on any of the variables, Quantum DSC does not change the settings. However, if the custom property has not been defined on any variables (because, for example, you have not created a Quantum specification for the data set before) Quantum DSC sets the custom propery on the variables as follows:
1. The QTVisible custom property is set to False on:
▪The serial number variable.
▪All variables of data type Date, Level, or Object.
▪All multiplier and source file variables.
▪All Quanvert Extra variables (helper variables named .Ex).
2. The QTVisible custom property is set to True on all of the remaining variables, or when the variable contains an empty value.
Quantum DSC creates only a comment in the .qax file and no entry in the .tab file for text variables and Quanvert Extra variables.
User-definable limits
Quantum includes a number of internal parameters that limit the size of your jobs. When these limits are exceeded, Quantum issues an error message. Most Quantum limits cannot be changed.
Exceptions and parameters used to change the limits
axes
The maximum number of axes per run. When calculating the number of axes in a run, Quantum counts each grid axis as two axes. The default limit is 500. When this parameter is exceeded, Quantum issues the message ‘Limit of number of axes in run exceeded’.
elms
The maximum number of elements per axis. The default is 500. When this parameter is exceeded, Quantum issues the message ‘Too many elements in axis’ or ‘Too many p fields’.
heap
The maximum number of characters per axis. The default is 20,000. When this parameter is exceeded, Quantum issues the message ‘Too many chars in axis text heap’.
incs
The maximum number of different inc= per run. The default is 600. When this parameter is exceeded, Quantum issues the message ‘Too many inc=’s specified’. When you increase this parameter, Quantum automatically increases the namevars parameter by an equivalent amount because each inc=also contributes to the total number of named variables.
incheap
The number of characters reserved for storing the names of inc= variables. The default is 12,000. When this parameter is exceeded, Quantum issues the message ‘inc=’s names too long in total’.
textdefs
The maximum number of different text symbolic parameters per run. The default is 15 different text symbolic parameters, but one of these is always used internally so the usable number is, in fact, 14.
namevars
The maximum number of named variables and inc= per run. The default is 900, but since 33 of these are used internally, the true default is 867.
inlistheap
The limit on the complexity of a definelist. The default is 1000.
edheap
The limit on the complexity of an edit statement. The default is 500. If the limit controlled by either edheap or inlistheap is exceeded, Quantum issues the error ‘Logical expression too long’.
manipheap
The maximum size of the items allowed per axis in element-manipulation expressions. The default is 500. If this limit is exceeded, Quantum issues the message ‘Reverse polish stack full’. This parameter applies only to axis manipulation, and not to table manipulation using the ex statement.
lexchars
The maximum size of long text strings; that is text enclosed in $’s (for example in a definelist). The default is 1024. When this limit is exceeded, Quantum issues the message ‘Sum of characters within $’s exceeds limit’.
Overriding default values
The file maxima.qt allows you to override certain Quantum default values. You can add lines to maxima.qt. For example:
elms=5000
axes=5000
You can define limits in several ways, depending on whether they apply to the installation as a whole, to a particular job, or to an individual user. To define installation-wide limits, edit or create a file containing the following lines with the new limits you want to implement:
axes=max_axes
elms=max_elms
heap=max_chars
incs=max_incs
incheap=max_ichars
textdefs=max_params
namevars=max_vars
edheap=max_vars
inlistheap=max_env_vars
manipheap=max_manip_exp
lexchars=max_exp_length
You need enter only those lines whose values you want to change; if you want to retain the default maximum for axes per run, for instance, omit the corresponding entry from the file.
Axis names
By default, the axis names are based on the full names of the variables on which they are based, with non-alphanumeric characters replaced by underscores (_). For example, the axis for the DataCollection.Status system variable is called DataCollection_Status.
However, you can optionally request short names using the UseShortNames custom property. The full names of the variables are then shortened, when necessary, to eight characters. Quantum DSC does this by dividing the full names into sections separated by uppercase letters and non-alphanumeric characters, removing any non-alphanumeric characters, truncating each section so that the overall size is no larger than eight characters, and replacing the last character(s) with a numeric counter when necessary to avoid duplicates. For example, when this option is used, the axis for the DataCollection.Status system variable is typically called DataCoSt.
Note that in UNICOM Intelligence Data Model 2.8 and later, Metadata Model to Quantum uses Quantum DSC to create the Quantum specification. The axis names are then based on the abbreviated version of the full names (which are displayed in the first column of the Metadata Model to Quantum window) rather than the full names themselves. This can sometimes mean that the axis names created using Metadata Model to Quantum may be slightly different to those created by Quantum DSC using a script. However, if the .mdd file is saved in Metadata Model to Quantum, the abbreviated names are saved in the ShortName custom properties and Quantum DSC bases the axis names on them when creating a Quantum specification in the future. So this discrepancy should be encountered only if you create a specification using a script and later create one using Metadata Model to Quantum, if you have duplicate copies of the same file, or other similar situations.
Error messages
The following table lists the possible errors that can occur when using Quantum DSC to generate a Quantum specification.
DSC_E_DATA_SOURCE_MISSING
Hexadecimal value: &HC0021503
Data Source property missing. The MDM Document must contain a valid Data Source for the Quantum DSC.
QTSPEC_E_CARDCOL_ERRORS
Hexadecimal value: &HC0021901
At least one card, column or punch allocation is invalid. There must be valid card, column and punch definitions for all variables and categories in the MDM Document.
QTSPEC_E_UNKNOWN_TYPE
Hexadecimal value: &HC0021900
The data type is unknown. Only MDM Array, Compound, Class, and Grid, and Variables of data type Double, Long, Categorical, and Text are supported. Variables of type Date or None are ignored. Any other object or data type will give this error.
QTSPEC_E_GRID_HAS_NO_ELEMENTINSTANCES
Hexadecimal value: &HC0021900
Grid has no ElementInstances. This error occurs if the first variable in a grid has no element instances.
QTSPEC_E_INTERNAL
Hexadecimal value: &HC0021902
Internal error. This error should not occur.
Example
For an example of creating a Quantum specification using Quantum DSC in a script, see
Creating an Quantum specification using a script.
See also