| RE: .0
> DIRECTIVE CREATE = 12 :
> DIRECTIVE-TYPE = ACTION,
> DISPLAY = TRUE,
>
> REQUEST
> ARGUMENT Attribute Values = 1 : Attrib_List
> ECHO = TRUE,
> DISPLAY = TRUE,
> REQUIRED = TRUE,
> DEFAULT = NO DEFAULT,
> SYMBOL = PABX_CREATE_REQ_ARG1
> END ARGUMENT Attribute Values;
> END REQUEST;
The Create Directive does not take an Attribute List as an Argument.
You should make all new, seperate arguments for this directive.
Then, your AM must convert the argument codes to attribute codes
to store in your MIR.
This is what the Alarms FM must do on the Create Directive.
Also - When you issue the create directive:
>> CREATE PABX .Pabx_Utrecht LAT Port Name = "LTA158"
^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
| |
| |
This is the Instance Identifier. On a normal Create directive,
According to your MSL, it can be This is an argument to the
1 of 2 attributes: directive. But you're trying
o Pabx Name to make an attribute out of it.
o LAT Port Name but you can't.
I think you're Identifiers are Ok
The Create Request argument need to be fixed - to list two arguments.
Based on the Id code of the Instance Identifier (.Pabx_Utrecht from
above), you can determine if the arguments passed are valid (ie, you
can't give 'Pabx Name' as the instance Identifier *AND* an argument).
Once you validate the the input argument are Ok, you can write your
data to the MIR.
Am I helping?
/keith
|
| Keith, thanks for your reply,
.1> On a normal Create directive, This is an argument to the directive.
But you're trying to make an attribute out of it. But you can't.
We can of course (with DECmcc everything is possible ?):
We have defined our argument in the following way:
DIRECTIVE CREATE = 12 :
DIRECTIVE-TYPE = ACTION,
DISPLAY = TRUE,
REQUEST
ARGUMENT LAT Port Name = 1 : Latin1String
ECHO = TRUE,
DISPLAY = TRUE,
REQUIRED = TRUE,
DEFAULT = NO DEFAULT,
SYMBOL = PABX_CREATE_REQ_ARG1
END ARGUMENT LAT Port Name;
END REQUEST;
On the Create directive:
MCC> create pabx .pabx_utrecht LAT Port Name = "LTA158"
- we read the passed class and instance pair (in in_entity) and place
this instance in the private MIR (primary identifier).
- we read the passed argument (in in_p) and place that value as a
secondary identifier in the private MIR.
In the MIR we have now Pabx Name (FullName) and LAT Port Name (Latin1String) as
two identifiers for every instance that is created.
We built this Create directive and it works now.
The Create directive is restricted in this way that you must specify always:
MCC> create pabx <Pabx Name> Lat Port Name = "<LAT Port Name>"
It is not possible to exchange <Pabx Name> and <LAT Port Name>, but this
is ok for us.
But now the next question :
If we change the Create Request to list two arguments, in the following way:
DIRECTIVE CREATE = 12 :
DIRECTIVE-TYPE = ACTION,
DISPLAY = TRUE,
REQUEST
ARGUMENT Pabx Name = 1 : Latin1String
ECHO = TRUE,
DISPLAY = TRUE,
REQUIRED = FALSE,
DEFAULT = NO DEFAULT,
SYMBOL = PABX_CREATE_REQ_ARG1
END ARGUMENT Pabx Name;
ARGUMENT LAT Port Name = 2 : Latin1String
ECHO = TRUE,
DISPLAY = TRUE,
REQUIRED = FALSE,
DEFAULT = NO DEFAULT,
SYMBOL = PABX_CREATE_REQ_ARG1
END ARGUMENT LAT Port Name;
END REQUEST;
( Note that Required must be false because one of the arguments must be passed.)
In theory we are now able to issue the following directives:
MCC> create pabx .pabx_utrecht LAT Port Name = LTA158
MCC> create pabx LTA158 Pabx Name = .pabx_utrecht
This would be very nice, but now another problem :
In (another theory) it is also possible to issue the following directives:
MCC> create pabx LTA158 LAT Port Name = .pabx_utrecht
MCC> create pabx .pabx_utrecht Pabx Name = LTA158
if we issue the following show directives :
MCC> show pabx .pabx_utrecht all ident
MCC> show pabx LTA158 all ident
what datatype for the instance does the PM pass ?, does it transform it to
the primary name (by default) ?, does it check for the '.' ? Or is this all
PM dependent and are we in a danger zone ?
Regards Paul and Henk
|
| After some reading and internal discussions we found the following:
SRM (V1.1) Page 127 :
>> The user-visible representations of the data types of any identifier must be
>> distinguishable from the types of all other identifiers for an entity class.
For identifiers Latin1String and FullName this is not the case.
In note 653 is stated (to my understanding) that if the entity-definition in
the MS is constructed in this way:
GLOBAL ENTITY ...
....
IDENTIFIER = ( <FullName-identifier>, <Latin1String-identifier> )
....
END ENTITY ...
that the instance specified in the SHOW-directive will always be passed (to the
Access Module) as being a FullName (because the PM cannot distinguish the data
type, it passes the identifier as the FullName).
Is this true for every PM or is this (to our opinion) PM dependent ?
What happens if the entity-definition in the MS is constructed in this way:
GLOBAL ENTITY ...
....
IDENTIFIER = ( <FullName-identifier> )
....
<identifier-description FullName-identifier>
<identifier-description Latin1String-identifier>
....
END ENTITY ...
- Does the MSL-translator crash on this ?
- On a Show Ident directive: must the AM supply both identifiers or
only the FullName identifier (does the PM display both or only the
FullName identifier ?) ?
Regards Paul and Henk
|
| FCL parses the instance name in the order of the identifiers listed
in the MSL. Since you list fullname first, it will try to match the
identifier as a fullname. Unfortunately, in your case, the
latin1string identifier will match as a fullname, as you've noticed.
Christine
|