Digital DCE for OpenVMS VAX and OpenVMS Alpha
Reference Guide

Name name differs from a previous name only in case

• Explanation: The target language selected is not case-sensitive with respect to identifiers; that is, any two identifiers that differ only in case are considered to be identical. The IDL source contains two distinct identifiers that differ only in case, but they conflict with each other in the generated language header file.
  User Action: Edit the IDL source code to remove the conflict.

Nonscalar function result converted to trailing [out] parameter

• Explanation: The target language selected does not allow the function result argument of a routine to be a nonscalar type. The IDL compiler converts such a construct to a trailing [out] parameter.
  User Action: No action is required. You might want to edit your IDL source and change the declaration from a function result to an [out] parameter in order to map naturally to the target language.

Operation with [cs_tag_rtn] contains no codeset tag parameters

• Explanation: The [cs_tag_rtn] attribute normally appears on an operation only if it has least one parameter with a [cs_stag], [cs_drtag], or [cs_rtag] attribute.
  User Action: Make sure the ACF declaration for the operation has one or more of the above tags applied to parameter(s) in the operation.

Operation with [decode] has [in]-only parameter name

• Explanation: The client stub for an operation with the [decode] attribute decodes encoded data into operation parameters with the [out] attribute. Parameters with only the [in] attribute are ignored.
  User Action: If any client will encode the data by applying the [encode] attribute to the operation, the operation must contain all [in,out] parameters except for the binding handle parameter.

Operation with [decode] must have at least one [out] or [in,out] parameter

• Explanation: The client stub for an operation with the [decode] ACF attribute decodes a data stream into the operation's [out] and [in,out] parameters. The [decode] attribute is not meaningful on an operation with only [in] parameters.
  User Action: Perhaps you meant to use the [encode] attribute on the operation. If not, either remove the [decode] attribute or add the [out] attribute to one or more parameters.

Operation with [encode] has [out]-only parameter name

• Explanation: The client stub for an operation with the [encode] attribute encodes all of the operation parameters with the [in] attribute. Parameters with only the [out] attribute are ignored.
  User Action: If any client will decode the encoded information by applying the [decode] attribute to the operation, the operation must contain all [in,out] parameters except for the binding handle parameter.

Operation with [encode] must have at least one [in] or [in,out] parameter

• Explanation: The client stub for an operation with the [encode] ACF attribute encodes the operation's [in] and [in,out] parameters into a data stream. The [encode] attribute is not meaningful on an operation with only [out] parameters (excluding the binding handle parameter).
  User Action: Perhaps you meant to use the [decode] attribute on the operation. If not, either remove the [encode] attribute or add the [in] attribute to one or more parameters.

Operation with [encode] or [decode] may not contain pipe parameters

• Explanation: The IDL encoding services do not support pipes.
  User Action: Use arrays to represent the data, or utilize multiple procedure calls to encode or decode the data.

Operation with [encode] or [decode] must use explicit binding

• Explanation: An operation with either of the [encode] or [decode] attributes may not use automatic, customized, or implicit binding.
  User Action: Edit the IDL operation definition to have an item of type handle_t as its first argument, or edit the ACF operation declaration to include the [explicit_handle] attribute.

Operation with [encode,decode] must have all [in,out] parameters

• Explanation: The client stub for an operation with the [encode,decode] attributes can encode the operation's parameters into a data stream and subsequently decode the data back into parameters. This makes sense only if the decoded data agrees with the originally encoded [in] parameters.
  User Action: The operation must contain all [in,out] parameters except for the binding handle parameter.

Operation with [in] [cs_char] data requires [cs_stag] parameter

• Explanation: If any [in] parameter, or part of an [in] parameter, has a [cs_char] type, there must be a parameter in the same operation to which [cs_stag] is applied.
  User Action: Make sure the ACF declaration for the operation has the [cs_stag] attribute applied to one of the parameters in the operation.

Operation with [out] [cs_char] data requires [cs_rtag] parameter

• Explanation: If any [out] parameter, or part of an [out] parameter, has a [cs_char] type, there must be a parameter in the same operation to which [cs_rtag] is applied.
  User Action: Make sure the ACF declaration for the operation has the [cs_rtag] attribute applied to one of the parameters in the operation.

Operation with [reflect_deletions] has no [in] or [in,out] full pointers

• Explanation: Reflection of node deletions from server to client is only applicable to operations that have [in] or [in,out] full ([ptr]) pointers. The attribute thus has no effect on the indicated operation.
  User Action: Remove the [reflect_deletions] attribute from the operation to avoid this warning message.

Pipes not supported for target language

• Explanation: The data structures necessary to manage IDL pipes do not have a source representation in the target language selected.
  User Action: Pipe objects will have no corresponding definition in the generated language header file. Application code for operations with pipes should be written in another programming language.

Pointer attributes are ignored on an interface reference

• Explanation: Interface references are not managed in the same way as other pointers and references in IDL. Thus, the pointer attributes [ref], [unique], and [ptr] are not meaningful on an interface reference.
  User Action: No action is required, since the pointer attribute is ignored and the IDL compiler continues processing. To eliminate the warning message, remove the pointer attribute from the declaration.

Static property or ACF attribute [cxx_static] is ignored except for -lang cxx

• Explanation: The IDL static keyword on an operation, as well as the ACF [cxx_static] attribute on an operation, only pertain to interfaces that are compiled with the -lang cxx IDL compiler option.
  User Action: If your application code is written in C++, then you must use the -lang cxx option to the IDL compiler in order to enable generation of C++ header file and stub files. Otherwise, no action is required, since the static property is ignored, and the IDL compiler continues processing. To eliminate the warning message, remove the static property from the declaration.

Structures with [transmit_as] or [represent_as] cannot be conformant

• Explanation: IDL does not support a conformant structure with the [transmit_as] or [represent_as] attribute.
  User Action: Either change the declaration so the structure fields are of a fixed size and have none of the conformant array attributes [min_is], [max_is], or [size_is], or remove the [transmit_as] or [represent_as] attribute.

Tag parameters must have type unsigned long int passed by value or reference

• Explanation: Parameters to which tag attributes ([cs_stag], [cs_drtag], or [cs_rtag]) are attached must be either unsigned long integer values or unsigned long integers passed by reference.
  User Action: Change the parameter types as required.

Target language supports maximum of number array dimensions

• Explanation: The target language selected does not support arrays with more than the indicated number of dimensions.
  User Action: Such arrays will have no corresponding declaration in the generated language header file. Application code using such arrays should be written in another programming language.

The attribute [min_is] cannot be applied to dimension n; lower bound is not dynamic

• Explanation: A [min_is] variable is valid only for array dimensions that have a lower bound that is not fixed.
  User Action: If the array is multidimensional, you may have specified the [min_is] variable for the wrong dimension. See the documentation for the proper syntax. If the array has only one dimension, the [min_is] clause is invalid, since the array's lower bound is fixed. The [first_is] clause is valid for single dimension arrays. See the documentation for the distinctions between conformant and varying arrays and their attributes.

The attribute [min_is] is required

• Explanation: An array with a lower bound that is not fixed is used as a field of a structure or as a parameter of an operation. You must specify a field or parameter that determines the lower bound of the array at runtime.
  User Action: Use a [min_is] attribute to specify the field or parameter that contains the lower bound.

The attribute [name] is not valid on an operation with pipes

• Explanation: An operation with the indicated attribute cannot have any pipe parameters.
  User Action: Remove either the attribute or any pipe parameters.

The attribute [name1] cannot occur with [name2] or [name3]

• Explanation: The attribute [name1] cannot occur in the same declaration containing either of the other two attributes. Generally this means that two IDL language features cannot be used together because they conflict with one another in some way.
  User Action: Remove one of the conflicting attributes.

The attribute [unique] is invalid on a binding handle parameter

• Explanation: The first parameter in an operation is a handle parameter, which is either of type handle_t or a type with the [handle] attribute. A binding handle parameter cannot have the [unique] attribute because it cannot be NULL.
  User Action: Remove the [unique] attribute from the parameter.

The base type of a pipe cannot be or contain a [name] type

• Explanation: The indicated attribute cannot be applied to the base type of a pipe, or a type used in constructing the base type of a pipe.
  User Action: Do not use the indicated attribute with pipes.

The [name] attribute cannot be duplicated in the same parameter list

• Explanation: The named attribute cannot be applied twice in the same parameter list.
  User Action: Make sure that only one parameter in the operation's parameter list has the attribute applied to it. The attribute is specified either in the source IDL or source ACF file.

The [name] attribute cannot occur with an execution semantic attribute

• Explanation: The indicated operation attribute is not valid on an operation with one of the operation execution semantic attributes, [broadcast], [maybe], or [idempotent]. Generally this means the attribute implies or requires the normal "at-most-once" execution semantics for RPC operations.
  User Action: Remove one of the conflicting attributes.

The union switch variable name cannot be a [ptr] or [unique] pointer

• Explanation: A [switch_is] attribute clause in the source IDL specifies its value by dereferencing a pointer field or parameter. This is invalid if the pointer variable has either of the [ptr] or [unique] attributes, since both allow the pointer to be NULL. If the pointer were NULL, there would be no way to determine the union discriminator.
  User Action: Either redeclare the [switch_is] variable to be a scalar rather than a pointer, or change the [switch_is] variable to be a [ref] pointer.

Type with [name] must resolve to byte or structure containing only byte fields

• Explanation: A type with the indicated attribute must be defined as an IDL type that resolves to byte or to a structure type in which all of the fields have types which resolve to byte.
  User Action: Change the type definition, or remove the attribute if it is not needed.

Type with [name1] cannot be or contain type with [name2]

• Explanation: A type with the first attribute cannot also have the second attribute, nor can it contain any type which has the second attribute.
  User Action: The two features cannot interact on a single type. Consider alternate ways to achieve the desired result.

Types with the [name] attribute cannot be nested

• Explanation: A type with the indicated attribute cannot include another type with the same attribute.
  User Action: Do not nest types with the attribute.

[unique] pointers to context handles are not allowed

• Explanation: IDL does not allow [unique] pointers to context handles.
  User Action: If the declaration has the [unique] attribute, either explicitly or by default, change it to a [ref] pointer. However, if the declaration is an operation result, it cannot be a [ref] pointer and an operation resulting in a pointer to a context handle is not valid.

Use of a nonencapsulated union requires option

• Explanation: A nonencapsulated union is not portable to all implementations of DCE.
  User Action: Use an encapsulated union instead or specify the extended standard option on the compiler command.

Use of C preprocessor directive requires command-option

• Explanation: The IDL compiler detected a C preprocessor directive in a source IDL or ACF file. C preprocessor directives begin in the first column of a source line and start with the "#" character. Either you have specified an IDL command option to disable C preprocessing, or IDL does not invoke the C preprocessor by default on the platform on which you are running.
  User Action: Add the indicated command option to your idl command so that the IDL compiler will invoke the C preprocessor to preprocess source IDL and ACF files before they are parsed.

Use of anonymous type may not be portable across C compilers

• Explanation: The source IDL contains an IDL language construct, such as an enum, declared as an unnamed type within another definition. The generated stub code will compile cleanly under some C compilers, but generate errors from others. The potential errors are due to differences in the scoping of identifiers across C compilers.
  User Action: Use a typedef statement to define the base type as a named type, then use the type name in any subsequent declarations in place of an anonymous definition.

Use of [name] attribute requires option

• Explanation: The indicated attribute is not supported by DCE Version 1.0, and thus should not be used if interoperability with implementations of DCE Version 1.0 is required.
  User Action: Do not use the feature if interoperability with DCE Version 1.0 is required. Otherwise, specify the extended standard option on the compiler command to suppress the warning.

Use of nonzero array lower bound requires option

• Explanation: A nonzero array lower bound is not portable to all implementations of DCE Version 1.0.
  User Action: Use an array with lower bound zero instead or specify the extended standard option on the compiler command.

Use of [unique] pointers requires option

• Explanation: A [unique] pointer is not portable to all implementations of DCE Version 1.0.
  User Action: Use a [ref] or [ptr] pointer instead or specify the extended standard option on the compiler command.

Use of user-defined exceptions requires option

• Explanation: Use of user-defined exceptions is not interoperable with implementations of DCE Version 1.0.
  User Action: Do not use the feature if interoperability with DCE Version 1.0 is required. Otherwise, specify the extended standard option on the compiler command to suppress the warning.