| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
The list of supported datatypes for T1.0.0 are listed below. The last 2
columns indicate whether the datatype is supported on input and output
respectively. By "supported datatype", we mean accepting or displaying the
proper format. All unsupported OUTPUT datatypes will be displayed as if it is
an Octet String.
Input Output
----- ------
Integer8 Yes Yes
Integer16 Yes Yes
Integer32 Yes Yes
Integer64 Yes Yes
Unsigned8 Yes Yes
Unsigned16 Yes Yes
Unsigned32 Yes Yes
Unsigned64 Yes Yes
Counter16 Yes Yes
Counter32 Yes Yes
Counter48 Yes Yes
Counter64 Yes Yes
LCounter16 Yes Yes
LCounter32 Yes Yes
Boolean Yes Yes
Enumeration Yes Yes
Component N/A Yes
Phase4Address Yes Yes
MCC Error N/A Yes
VMS Error N/A Yes
Octet Yes Yes
OctetString Yes Yes
HexString Yes Yes
Latin1String Yes Yes
Bitset No Yes
SimpleName Yes Yes
FullName No Yes
FileSpec Yes Yes
DirectorySpec Yes Yes
Version Yes Yes
BinAbsTim Yes Yes
BinRelTim Yes Yes
CharAbsTim No No
CharRelTim No No
UID No No
NSCTS No No
ID802 Yes Yes
Phase4Name Yes Yes
DTEAddress Yes No
NSAP No No
NET No No
Area Address No No
AddressPrefix No No
TSEL Address Yes Yes
Set N/A Yes
Set Of Yes Yes
Sequence Yes Yes
Sequence Of Yes Yes
Record Yes Yes
Variant Record No Yes
Subrange Yes Yes
Range Yes Yes
Implementation N/A No
FullEntity Yes Yes
LocalEntity No No
EntityClass No No
Towerset No No
EndUserSpec No No
SimpleExpression Yes Yes
MCC Reply N/A No
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 9.1 | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Fri Nov 10 1989 10:33 | 5 | |
I don't understand the N/A fields in the input column. Surely all values which can be output have to be able to be input to allow for entity filters (the NCL WITH clause). Isn't that the case? Graham | |||||
| 9.2 | INFO- clarification | GOSTE::CALLANDER | Tue Nov 14 1989 11:41 | 16 | |
Sorry for any confusion that the list might have caused. For the
T1.0 release we were unable to complete support of all the data
types specified by the System Reference Manual. For this reason
we prioritized the data types and attempted to complete those that
we felt would be used most frequently. So that all commands could
at least get data back via a reply we always print the data, even
if we have to dump it in hex.
The chart shows which data types are supported on input and output.
With the release of the field test update almost all data types
are supported. The exceptions are those data types that require
DNS support, these will not be available until the internal field
test end user kit scheduled for release in mid december.
| |||||
| 9.3 | INFO - not all data types support an input BNF | GOSTE::CALLANDER | Wed Nov 15 1989 16:03 | 10 | |
In rereading 9.1 I noticed that 9.2 doesn't really answer the question.
Certain data types, like MCCReply, do not support an input mechanism.
To see which data types do not support the use of the data type
for the input of attribute/argument values please refer to the Data
Types chapter (9) in the SRM. If an input BNF is not supplied then
there is no mechanism for using the data type on an input argument.
| |||||
| 9.4 | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Fri Nov 17 1989 19:33 | 4 | |
I don't have my copy of the SRM to hand but I would have thought that Implementation and Component had to be enterable for filters. Graham | |||||
| 9.5 | CLARIFICATION | GOSTE::CALLANDER | Mon Nov 20 1989 17:22 | 24 | |
I see the confusion with my choice of examples. Within the MCCReply
data type there are many fields, two of them being the implementation
and component information. These fields in the MCCReply have to
do with the component that diagnosed the problem and created the
MCCReply that is being returned.
The implementation and component fields are not settable using the
MCCReply, but if defined in the components management specification as
settable attributes they can be entered using the SET directive, in
which case they will be encoded using the data type defined for the
attribute. As far as the use of the component and implementation as
filters, this can be done only if the component name and implementation
are defined in the management specification as attributes, if they are
then a filter can be defined using the WITH clause on the input command
line.
As it stands right now the MCCReply is a specialized record format
with predefined fields that have specific encoding and decoding
rules and meanings. This data type was defined for output of certain
types of error conditions within MCC, it was not designed for input
usage.
| |||||