This section provides DCL syntax for the UUID generator utility. Except where noted, DCL commands are equivalent to the universal command syntax documented in the Digital DCE Application Development Reference. See the reference documentation for a complete description of the universal command syntax interface to the UUID generator utility.

You can choose to use either the universal interface to the UUID generator utility or the DCL-style alternative.

NAME

• IDENTIFIER/TRANSLATE --- Translates a DECrpc Version 1 or 1.1 UUID to a DCE RPC UUID.

SYNOPSIS

• IDENTIFIER/TRANSLATE old-style-uuid [qualifier]...

QUALIFIERS

• /OUTPUT=filename
  /OUTPUT=SYS$OUTPUT (default)
  This qualifier, used with a filename, directs output to a file. If you do not specify a filename, the converted UUID goes to SYS$OUTPUT, generally your display terminal.

NAME

• IDENTIFIER/GENERATE --- Generates one or more DCE RPC UUIDs.

SYNOPSIS

• IDENTIFIER/GENERATE [qualifier]
  QUALIFIERS
  • /FORMAT=[option]
    Specify one of the following options.
    STRING (default)
    STRING Format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    This is a raw UUID in its readable form.
    IDL
    IDL Format:

    [ [uuid(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)] version(1.0) ] interface INTERFACENAME { }

    
    This is a UUID as it appears syntactically in an RPC interface definition.

STRUCT

• STRUCT Format: This is an initialized C structure declaration, which can be included in C code that is used with DCE RPC.

/COUNT=n

• This qualifier specifies the number of UUID strings to be generated. If you do not specify a number for n, the number 1 is used by default.

/OUTPUT=filename
/OUTPUT=SYS$OUTPUT (default)

• This qualifier, used with a filename, directs output to a file. If you do not specify a filename, the converted UUID goes to SYS$OUTPUT, generally your display terminal.

This chapter lists additional Interface Definition Language (IDL) compiler messages beyond those documented in the DCE Application Development Reference in Lidl_messages(7rpc). These compiler messages reflect the additional IDL compiler functionality provided with Digital DCE for OpenVMS VAX and OpenVMS Alpha. The messages are in alphabetical order by message text.

A [cs_rtag] parameter must precede any [out] [cs_char] data in a parameter list

• Explanation: A [cs_rtag] parameter must occur in an operation's parameter list before any [out] parameters containing types with the [cs_char] ACF attribute.
  User Action: Re-order the parameters to meet this requirement.

A [cs_stag] parameter must precede any [in] [cs_char] data in a parameter list

• Explanation: A [cs_stag] parameter must occur in an operation's parameter list before any [in] parameters containing types with the [cs_char] ACF attribute.
  User Action: Re-order the parameters to meet this requirement.

A [fault_status] parameter has no utility in this operation

• Explanation: A [fault_status] parameter is used in an operation where no fault can ever occur. An example is an encoding services operation, for example, one using [encode] or [decode]. There is no remote entity from which a fault might be received.
  User Action: Perhaps you meant to use a [comm_status] attribute. If not, the parameter can be removed from the operation or the [fault_status] attribute can be removed from the parameter.

A [first_is] variable must be a small, short, or long integer

• Explanation: The [first_is] attribute specifies a field or parameter that contains the lower data limit of a varying array. Array data limits must be integers which are not hyper.
  User Action: Change the data limit field or parameter referenced by the [first_is] clause to integer data type.

A [handle] binding parameter cannot contain a [name] type

• Explanation: A customized binding handle (a type with the [handle] attribute used as the first parameter in an operation) cannot include types with the indicated attribute.
  User Action: Do not use the indicated attribute with customized binding.

A [maybe] operation cannot have [out] parameters or a function result

• Explanation: The [maybe] attribute specifies that the operation's caller does not require and does not receive a response or fault indication. Do not use an [out] parameter or a function result in a [maybe] operation.
  User Action: Remove the [maybe] attribute from the operation, or remove all [out] parameters from the function and declare its result type as void.

A [min_is] parameter must have the [in] attribute

• Explanation: The [min_is] attribute specifies a parameter that contains the lower bound of a conformant array. This parameter must have an [in] attribute so the server stub code will allocate adequate space for the array.
  User Action: Change the lower bound parameter referenced by the [min_is] clause to have the [in] attribute.

A [min_is] variable must be a small, short, or long integer

• Explanation: The [min_is] attribute specifies a field or parameter that contains the lower bound of a conformant array. Array bounds must be integers that are not hyper.
  User Action: Change the lower bound field or parameter referenced by the [min_is] clause so that it is a small, short, or long integer.

A [name1] parameter must have the [name2] attribute

• Explanation: A parameter with the first attribute must also have the second attribute.
  User Action: Add the second attribute to the parameter declaration.

A nonencapsulated union cannot have a [represent_as] type

• Explanation: A nonencapsulated union type cannot be defined to have a local representation type, since there is no defined way to communicate the union discriminator to/from [represent_as] data translation routines.
  User Action: Use an encapsulated union, or reconsider the need for a different local representation type for the union.

A nonencapsulated union cannot have a [transmit_as] type

• Explanation: A nonencapsulated union type cannot be defined to have a transmissible type, since there is no defined way to communicate the union discriminator to/from [transmit_as] data translation routines.
  User Action: Use an encapsulated union, or reconsider the need for a different transmissible type for the union.

A nonencapsulated union declaration must have a [switch_is] attribute

• Explanation: A [switch_is] attribute is required on an instance of a nonencapsulated union type to identify the union discriminator variable.
  User Action: Provide a [switch_is] clause that specifies a field or parameter that is the union discriminator, or use an encapsulated union, where the union discriminator variable is encapsulated as a field within the union type.

A nonencapsulated union type must have a [switch_type] attribute

• Explanation: A [switch_type] attribute is required on a definition of a nonencapsulated union type to identify the data type of the union discriminator.
  User Action: Provide a [switch_type] clause that specifies a valid union discriminator data type.

A [represent_as] type cannot be a nonencapsulated union

• Explanation: A type referenced in a [represent_as] clause cannot be a nonencapsulated union, since there is no defined way to communicate the union discriminator to/from [represent_as] data translation routines.
  User Action: Use an encapsulated union for the local representation type.

A size attribute variable must not have a [represent_as] type

• Explanation: The parameter or field referenced in a [min_is], [max_is], [size_is], [first_is], [last_is], or [length_is] clause must not be of a data type that is declared to have a [represent_as] type.
  User Action: Change either the referenced parameter or field data type, or the data type definition itself.

A size attribute variable must not have a [transmit_as] type

• Explanation: The parameter or field referenced in a [min_is], [max_is], [size_is], [first_is], [last_is], or [length_is] clause must not be of a data type that is declared to have a [transmit_as] type.
  User Action: Change either the referenced parameter or field data type, or the data type definition itself.

A [size_is] or [max_is] attribute cannot be applied to a pointer to a [cs_char] type

• Explanation: The [cs_char] ACF attribute cannot be applied to a type which is the target of a pointer with the [size_is] or [max_is] attribute.
  User Action: Use an array of [cs_char] instead of a pointer to an array of [cs_char], or use a pointer to a structure which contains a conformant array of [cs_char].

A [switch_is] attribute is valid only on a nonencapsulated union

• Explanation: A [switch_is] attribute is used on a union type to identify the union discriminator variable. It is not valid on a nonunion type. It is also not valid on an encapsulated union type, where the union discriminator variable is encapsulated as a field within the union type.
  User Action: Use the [switch_is] attribute only on instances of nonencapsulated union types.

A [switch_is] variable must not have a [represent_as] type

• Explanation: The parameter or field referenced in a [switch_is] clause must not be of a data type that has been declared to have a [represent_as] type.
  User Action: Change the referenced parameter or field data type, or the data type definition itself.

A [switch_is] variable must not have a [transmit_as] type

• Explanation: The parameter or field referenced in a [switch_is] clause must not be of a data type that has been declared to have a [transmit_as] type.
  User Action: Change the referenced parameter or field data type, or the data type definition itself.

A [switch_type] attribute is only valid on a nonencapsulated union type

• Explanation: A [switch_type] attribute is used on a union type to identify the union discriminator type. It is not valid on a nonunion type. It is also not valid on an encapsulated union type, where the union discriminator type and variable must be specified in a switch clause.
  User Action: Use the [switch_type] attribute only on definitions of nonencapsulated union types.

A [transmit_as] transmitted type cannot contain a [name] type

• Explanation: The indicated attribute cannot be applied to any type which is used as the transmitted type used in a [transmit_as] attribute or any type which is used in the definition of the transmitted type used in a [transmit_as] attribute.
  User Action: Do not use the attribute on the transmitted type specified in the [transmit_as(transmitted_type)] attribute or any other type that is contained within that transmitted type.

A [transmit_as] type cannot be a nonencapsulated union

• Explanation: A type referenced in a [transmit_as] clause cannot be a nonencapsulated union, since there is no defined way to communicate the union discriminator to/from [transmit_as] data translation routines.
  User Action: Use an encapsulated union for the transmissible type.

A [unique] function result is not valid

• Explanation: Unlike [out] parameters, there is never any preexisting storage in the caller for pointer-valued function results. The pointer always points to new storage. This is the capability provided only by full pointers, not by [unique] pointers.
  User Action: Remove the [unique] attribute from the type definition of the data type for the function result.

ACF attribute [cxx_lookup] is valid only for (-lang cxx)

• Explanation: The ACF [cxx_lookup] interface attribute pertains only 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, edit the interface-name.acf file, and remove the [cxx_lookup] attribute.

ACF attribute [cxx_new] is valid only for (-lang cxx)

• Explanation: The ACF [cxx_new] operation attribute pertains only 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, edit the nterface-name.acf file, and remove any uses of the [cxx_new] attribute.

An arm of a union cannot be or contain a [unique] pointer

• Explanation: IDL-generated server stub code must allocate storage for objects pointed to by [unique] pointers. IDL does not allow a [unique] pointer within a union because the valid arm of the union, and therefore the object for which storage is allocated, is not known at compile time.
  User Action: Change the pointer within the union declaration to a full pointer.

An array with [name] base type cannot have the [ptr] or [unique] attributes

• Explanation: If an array parameter has a base type with the indicated attribute, it cannot have [ptr] or [unique] as parameter attributes. Remove the [ptr] or [unique] attribute. This implies that the parameter cannot have the value NULL.
  User Action: It must always point to valid array storage.

An encapsulated union member cannot have the [attribute] attribute

• Explanation: The attribute used is valid only on nonencapsulated unions, but was used on an encapsulated union.
  User Action: Remove the attribute. Consult the documentation for the differences between encapsulated and nonencapsulated unions.

An [in] or [in,out] union must have an [in] discriminator

• Explanation: A nonencapsulated union parameter that has the [in] attribute must have a discriminator, specified in a [switch_is] clause, that also has the [in] attribute, since the client stub code must know which member of the union to send to the server.
  User Action: Modify the parameter referenced in the [switch_is] clause to have the [in] attribute.

An [in,out] or [out] union must have an [out] discriminator

• Explanation: A nonencapsulated union parameter that has the [out] attribute must have a discriminator, specified in a [switch_is] clause, that also has the [out] attribute, since the server stub code must know which member of the union to send to the client.
  User Action: Modify the parameter referenced in the [switch_is] clause to have the [out] attribute.

An [out] parameter or operation result cannot contain [unique] pointers

• Explanation: Operation results and parameters that are [out] only cannot have [unique] pointers. Unique pointers may be NULL, but there is no way to express the NULL value to the server unless the pointer is part of an [in] parameter.
  User Action: Change your type declarations so no types contained in the parameter have the [unique] attribute, or, if the pointer is part of a parameter, add the [in] attribute to the parameter.

An [out,ptr] parameter is not valid

• Explanation: The [ptr] parameter attribute implies that the value of the pointer may be NULL. It is invalid on an [out] only parameter, since the possible NULL-ness is not shipped to the server (for example, in the [in] direction).
  User Action: If the pointer cannot be NULL, remove the [ptr] attribute. Otherwise, make the parameter an [in,out,ptr] parameter.

Array attribute variable cannot be used for both [cs_char] and non-[cs_char] arrays

• Explanation: In a structure or parameter list, any variable which specifies the [size_is] or [length_is] for a [cs_char] array must not be referenced in any attribute of a non-[cs_char] array.
  User Action: Use separate structure fields or operation parameters to specify array attributes for the non-[cs_char] array.

Array size information required for identifier

• Explanation: The IDL code uses an array with bounds that are not fixed and does not specify the appropriate size attributes.
  User Action: Modify the array declaration to include the appropriate [min_is], [max_is], or [size_is] attribute. If the array is a parameter, use an additional parameter to specify the missing size information. If the array is a field in a structure, use an additional field to specify the missing size information.

Arrays of [name] type can only use the [size_is] and [length_is] array attributes

• Explanation: The indicated attribute cannot be applied to a type if there is an array which has this type as base type and any of the attributes [min_is], [max_is], [first_is], [last_is], or [string] has been applied to the array.
  User Action: Use only the [size_is] and/or [length_is] attributes in relevant array declarations, or specify a different base type for the array that has the indicated attribute.

Arrays of [name] type cannot be multidimensional

• Explanation: The indicated attribute cannot be applied to a type if there is an array which has this type as base type and the array has more than one dimension.
  User Action: Specify a different base type for the array which has more than one dimension.

Arrays of nonencapsulated unions are not allowed

• Explanation: IDL does not allow arrays of nonencapsulated unions since there is no way to apply a different discriminator to each element.
  User Action: Use an array of encapsulated unions.

Cannot have more than one level of indirection to a nonencapsulated union

• Explanation: IDL allows only a single level of pointer to a nonencapsulated union type.
  User Action: Remove the extra levels of indirection, or use an encapsulated union type instead.

Character doesn't map to target language

• Explanation: A character in an IDL character or string constant does not have a source representation in the target language selected.
  User Action: The character will be translated to a "?" in the generated language header file. Edit the file manually as necessary.

Conformant strings not supported in target language

• Explanation: An IDL conformant string does not have a source representation in the target language selected.
  User Action: The IDL conformant array will be declared as a one-element array in the generated language header file. Your application code might be able to use the address of this array to access other array elements, depending on the target language. Alternatives are to write application code that uses the construct in another programming language, or to change the IDL source to use a construct that is supported by the target language.

Conformant structures not supported in target language

• Explanation: An IDL conformant structure does not have a source representation in the target language selected.
  User Action: The IDL conformant array will be declared as a one-element array in the generated language header file. Your application code might be able to use the address of this array to access other array elements, depending on the target language. Alternatives are to write application code that uses the construct in another programming language, or to change the IDL source to use a construct that is supported by the target language.

Data type name must be defined in file

• Explanation: You used a feature that requires a predefined data type that is normally present by default, but the data type was not found. An example is a [comm_status] or [fault_status] parameter, which requires the data type error_status_t.
  User Action: The compiler expected to find the type in the indicated file (usually nbase.idl, which is automatically imported by IDL). Check that you are using the proper header files that were installed with DCE.

Exception name name referenced in ACF is not defined

• Explanation: An exception name is referenced in an Attribute Configuration File (ACF) but is not defined in the corresponding IDL file. Exceptions are not imported, so in order to reference an exception name in the ACF for a particular interface it must be defined in the IDL file for that same interface.
  User Action: Check for typographical errors in both the IDL and ACF files. If necessary, add the exception name to the source IDL file using the [exceptions] interface attribute, or move the ACF reference to the ACF file corresponding to the interface in which the exception name is defined.

FORTRAN INTEGER*4 used for IDL unsigned long

• Explanation: FORTRAN does not support unsigned integers. IDL maps unsigned long to INTEGER*4 in the generated FORTRAN header file.
  User Action: If the application needs to store large unsigned integer values, special care might be necessary in the FORTRAN application code.

FORTRAN INTEGER*n used for IDL pointer type

• Explanation: FORTRAN does not have a generic explicit pointer type. IDL maps pointer references to INTEGER*n in the generated FORTRAN header file.
  User Action: It is up to the FORTRAN application code to correctly manage the generated INTEGER*n object as a pointer.

Interface reference name allowed only as target of a * or & pointer

• Explanation: When an IDL interface is compiled with -lang cxx, the interface name also implicitly defines a type, similar to a C++ class. Pointers to or references to this interface type may be used elsewhere in the interface. Any other uses of this type are not valid.
  User Action: Change the declaration to use a * or &, or change the type used in the declaration.

Maximum identifier length for interface name is number characters

• Explanation: The IDL compiler constructs new identifier names that are referenced by generated stub code from the interface name. Therefore, the number of characters allowed in an interface name is less than for other identifiers.
  User Action: Shorten the interface name.

Maximum identifier length for pointed-to type is number characters

• Explanation: The IDL compiler constructs new identifier names that are referenced by generated stub code from the names of any pointed-to data types. Therefore, the number of characters allowed in such a data type is less than for other identifiers.
  User Action: Shorten the data type name.