Follow these rules when you name your variables:

• Use the usual naming conventions of the SAS System.

• Variable names are not more than 32 characters.

• When you create latent variable names, make sure that they are not used in the input data set that is being analyzed.

• For the LINEQS model, error or disturbance variables must start with 'E', 'e', 'D', or 'd'.

• For the LINEQS model, non-error-type latent variables (that is, factors) must start with 'F' or 'f'.

• For modeling languages other than LINEQS, names for errors or disturbances are not needed. As a result, you do not need to distinguish latent factors from errors or disturbances by using particular prefixes. Variable names that are not referenced in the analyzed data set are supposed to be latent factors.

• You should not use Intercept (case-insensitive) as a variable name in your data set or as a latent variable name in your model.

Follow these rules when you name your parameters:

• Use the usual naming conventions of the SAS System.

• Parameter names are not more than 32 characters.

• Use a prefix-name when you want to generate new parameter names automatically. A prefix-name contains a short string of characters called a "root," followed by double underscores '__'. Each occurrence of such a prefix-name generates a new parameter name by replacing the two trailing underscores with a unique integer. For example, occurrences of Gen__ generate Gen1, Gen2, and so on.

• A special prefix-name is the one without a root—that is, it contains only double underscores '__'. Occurrences of '__' generate _Parm1, _Parm2, and so on.

• PROC CALIS generates parameter names for default parameters to safeguard ill-defined models. These generated parameter names start with the _Add prefix and unique integer suffixes. For example, _Add1, _Add2, and so on.

• Avoid using parameter names that start with either _, _Add, or _Parm. These names might get confused with the names generated by PROC CALIS. The confusion might lead to unintended constraints to your model if the parameter names that you use match those generated by PROC CALIS.

• Avoid using parameter names that are roots of prefix-names. For example, you should not use Gen as a parameter name if Gen__ is also used in the same model specification. Although violation of this rule might not distort the model specification, it might cause ambiguities and confusion.

Finally, parameter names and variable names in PROC CALIS are not distinguished by explicit declarations. That is, a valid SAS name can be used as a parameter name or a variable name in any model that is supported by PROC CALIS. Whether a name in a model specification is for a parameter or a variable is determined by the syntactic structure. For example, consider the following path specification:

proc calis;
   path 
      a ---> b    = c;
   run;

PROC CALIS parses the path specification according to the syntactic structure of the PATH statement and determines that a and b are variable names and c is a parameter name. Consider another specification as follows:

proc calis;
   path 
      a ---> b    = b;
   run;

This is a syntactically correct specification. Variables a and b are defined in a path relationship with a path coefficient parameter also named b. While such a name conflict between parameter and variable names would not confuse PROC CALIS in terms of model specification and fitting, it would create unnecessary confusion in programming and result interpretations. Hence, using parameter names that match variable names exactly is a bad practice and should be avoided.