Conference azur::mcc

    SET OFs and SEQUENCE OFs are handled differently by the PM. Since the
    set of is a set of a single data type we parse and encode each piece
    based on the specified data types.
    
    For the SEQUENCE OFs we find out what the sequence of data types
    are and the PM then parses each piece and encodes them using the
    data types specified; in the order specified.
    
    jill
    

re .1

Are you saying that elements of a SEQUENCE OF can have different data types ? 

The SRM (page 250) says that "All elements of a Sequence Of are of the same base 
type" (similar statement appears under the Set Of data type section) 

  The SRM correctly states that SET OF and SEQUENCE OF each have one base data
  type.  There essentially is no semantic difference between them and we
  considered dropping one of them at one point.  However, there is enough use
  of SET OF and SEQUENCE OF for that to be infeasible.

  SET OF and SEQUENCE OF each allow a series of elements of one data type.
  Note that only SET OF and SEQUENCE OF can have "repetitions" in that one
  data type is listed but there can be more than one value (of that data type)
  in the series.

  SET can have more than one data type specified.  The order of the elements
  is not significant and elements can be missing in the series.  This makes
  the parsing of this data type ambiguous on input.  Therefore, a SET will not
  be supported on input by the Console.

  SEQUENCE and RECORD are nearly identical, the difference being that a RECORD
  has a presentation name associated with each member of the RECORD and a
  SEQUENCE does not.  Other than that they are the same.  If you list four
  members of a RECORD or a SEQUENCE, then there must be four elements in the
  series (the ILV construction) in the order specified.  Each must be of the
  listed data type and there can be no repetitions.

  An ECO to the SRM will be written adding these details to the SRM to make
  things more clear.  The TRM is currently quite permissive about some of
  these semantics but this is the intent.

							- Dave

    sorry about that, I had meant sequence not sequence of. I am aware
    of sequence of going (hopefully) away.
    
    Thanks for the clarification Dave.
    

There certainly  *is*  a  semantic  difference between SET OF and SEQUENCE OF.
The  question of whether the order is significant is very important to the end
users  of  the  datatype (the manager and the entity being managed).  There is
probably  no  difference  as far as the code of any MCC component is concerned
but the two separate datatypes must be preserved.

Any MCC  component  could (if it wished!) completely reorder the elements of a
SET  OF.  Also, it should be illegal to have the same value present twice in a
SET  OF  (it is meaningless) -- either that or the PM should make sure it gets
rid  of  any duplicates (my agent code certainly gets rid of any duplicates in
CMIP  messages).   ADD  and  REMOVE are also meaningless for SEQUENCE OF (they
should only be permitted on SET and SET OF).  

In general  order  is  not  important and ADD and REMOVE are very useful.  For
these  reasons,  SET  OF  is much more commonly used than SEQUNCE OF.  However
there are legitimate reasons for wanting to use SEQUENCE OF.  For example, MOP
uses  SEQUENCE  OF to specify the file to use for a down-line load.  The files
are  looked  for  in  turn,  *in the order specified* (this is useful when the
files  live  on  remote  nodes).   This would not be possible to manage if the
datatype was SET OF (some component might re-order the set without telling the
manager).

Graham

  I did not mean to start any rumors.  I will try again:

  Graham, you're right, thanks.  That is exactly the reason why they are both
  in the SRM.  To allay any fears, the SET OF and SEQUENCE OF data types are
  in the SRM and will stay there. The statement about there being little
  difference between SET OF and SEQUENCE OF was from a DECmcc PM viewpoint.
  (Sorry, folks, I usually try not to make component-specific statements about
  data types.)  The PM does not do any reordering of the elements of a
  construction, so there is little difference from the standpoint of displaying
  those elements.  As Graham pointed out, there are semantic differences among
  the data types which should be taken into account when choosing which data
  type to use.
							- Dave

RE: .0
	>Is the ordering the sole responsibility of the entity's
	>agent or do PM's, FM's, and AM's handle the two types differently ?

       Well from MCC alarms perspective, whenever we decide to handle these
       data types, the inequality operations and the ordering properties
       will certainly handled appropriately for the SET OF and the SEQUENCE
       OF data type.

       if say A and B belongs the data type SET OF, operation like IS A > B
       will not be permitted under Alarms RULE, where as A = B or A <> will
       be permitted.

       In short Alarms FM will certainly react differently to different
       Data Types.

       - Anil Navkal


Phil

Thanks for the previous replies.  SET OF and SEQUENCE OF are now clear to me.
However, I now have a couple of questions about SEQUENCE:

1. 	Is the MSL syntax for the "SEQUENCE" datatype correct the way it is 
	defined in the SRM ? The reason I ask, you say that "SEQUENCE" can
	consist of different data types and the MSL syntax for "SEQUENCE"
        says that <sequence-construct>:== "SEQUENCE"<base-type>
         
	I do not see from the above how the specific (and possibly different) 
        data types are specified in the sequence (and, based that, parsed).


2.	Let us suppose that the data types are somehow defined for 
        a SEQUENCE of Latin1String, Unsigned8, and SimpleName. Does the PM 
        allow the user to skip an element by enclosing its position with commas?

	e.g.: will both of these two commands be accepted by the TRM

			("jones", 5, apple)

				and

			("jones", , apple)


 

    
    Some of the area around set/sequence/set of/sequence of needs to
    be better clarified. Dave Moore is the owner of that chapter of
    the SRM. I believe that he can best clarify the difference. 
    
    What I can tell you, is that there is no way to "default" or omit
    and element from a constructed data type. This means, for example,
    if you define a record of 5 elements, the user must enter all 5
    every time. You can set a default for the entire record but not
    for specific elements within the record.
    
    (Also note that the definition in the SRM of sequence and sequence
    of are identical in everything except their name.)
    
    

Re .7:

Currently in the Entity Model and NETMAN we have defined the operators < and >
on a type which is defined as a SET OF foo to mean proper subset and superset
respectively. (See Entity Model T1.0.0 section 8.36). It would seem that MCC
ought to support those operators on SET OF constructed types as well.

Re .8:

I think you are confusing MSL type definitions with ASN.1 type definitions. In
ASN.1, you can in fact define a SEQUENCE {  Integer, PrintableString, Boolen}
type.  In MSL you cannot. The closest thing to an ASN.1 SEQUENCE is an
MSL RECORD data type (which will form an ASN.1 SEQUENECE when encoded as ASN.1
but conceptually is a different type).

MSL has nothing like an ASN.1 SET { Integer PrintableString, Boolean}.

MSL's SEQUNCE OF and SET OF are however the same as ASN.1's SEQUENCE OF and 
SET OF type constructors.  They have only one base type.

So the bottom line is.... You can't define the type you used in youre example.

				Mark

Re .10

My first question in .8 was in response to the fourth paragraph in .3 by Dave
Moore which stated that RECORD and SEQUENCE are essentialy the same except for
the field name at the user interface. Well, I think Dave was talking about the 
MSL not ASN.1 therefore I could not see how to define a sequence (SEQUENCE) of 
different data types when the MSL syntax is: "SEQUENCE" <base-type>.

Anyways, I think that RECORD is more useful to me but the restriction of 
requiring all fields, at input,  everytime the user wants to update any is very
user-unfriendly to say the least. So far, I have not heard any explanation
for the restriction let alone acknowledgements that it is a restriction.
 
Cheers,
Phil

Ah, the restriction that you could not modify individual fields in a record
was intentional. If you need to modify fields, then make each field an
attribute in its own right. If you need to refer to them as a unit, make
the unit an attribute group.

The model is that an attribute is a single atomic value that is
manipulated as a whole unit. The SET ADD and REMOVE operations all treat
the attribute as a single unit. They are incapable of "sub addressing" 
individual fields in a record.

    The TRM does enforce this rule, to modify a record you must supply
    all fields. This means values must be supplied ,,, isn't excepted.
    

    Is it possible to have a SET OF type, where type is a RECORD? 
    
    How could  an ASN1 "SET OF SEQUENCE { x, y, z}"  (where x,y,z are of
    different types)   be defined in MSL?
    Carol

    Yes, SET OF will support RECORD as a base type.
    
    Christine
    

    
    well....Actually the EFT kit has a bug in it such that set_of records
    can not be parsed. sorry about that but the kit about to come out
    does fix the problem.
    
    As to how to enter the sequence_of, I read some where there was
    a bug in the msl translator that caused an error on entering a real
    sequence of (more than one base type). I will ask the PL for that
    group the current status, and an example if it works now.
    
    

    Re .14:
    
    SEQUENCE {x, y, z} isn't the same as the SEQUENCE OF (even though ASN.1
    gives them the same universal tag, sigh). The closest MSL type is
    RECORD. The only difference is that RECORD assigns a context tag to
    each field, while the bare ASN.1 SEQUENCE depends on their order
    (if each field is required) or depends on the definer being "very
    smart" and defining distinguishable tags for each field. The RECORD
    type constructor simply regularizes all those complex rules to a simple
    rule that always allows the fields to be distinguished. I expect that
    we'll have to support a "raw SEQUENCE" type constructor in ASN.1
    eventually.