Conference azur::mcc

Let me refine my question. I find that once a specific <open> character is used
in specifying attribute that it MUST be be specified throughout.

Case in point, the following ARE accepted:

set node 0 disk $5$dua242 acl ( (Identifier=Hess, Options=(None), 
                                 Access=(Read) ) )
set node 0 disk $5$dua242 acl { {Identifier=Hess, Options={None}, 
                                 Access={Read} } }

The following are NOT

MCC> set node 0 disk $5$dua242 acl ( {Identifier=Hess, Options={None}, 
                                      Access={Read} } }
%MCC-E-UNBAL_OPENCLOSE, open and close delimiters are not balanced
MCC> set node 0 disk $5$dua242 acl ( {Identifier=Hess, Options=(None), 
                                      Access=(Read) } }
%MCC-E-UNBAL_OPENCLOSE, open and close delimiters are not balanced
MCC> set node 0 disk $5$dua242 acl ( {Identifier=Hess, Options=(None), 
                                      Access=(Read) } )
%MCC-E-SPLIT_CONSLIST, error in list of values

I have YET to get "[" or "]" to work.

Sorry about that, I should have release noted that one. I thought it was in
the manual but in checking I don't quickly see it.

The FCL is coded such that onces you open a construction you must close it
using the same "type" of close. This was done to simplify the parsing
of the command line. I will see if something can be done to lift this
restriction, but do not expect to be able to get to if for V1.2.

This has been entered as qar 651 in the MCC_INTERNAL qar database.

    I don't think '[' and ']' are currently supported as valid <open> and
    <close> delimiters.  The reason behind that is that there are other
    datatypes out there which could use these characters as part of a valid
    value.  So there could be some confusion as to whether to treat them
    as delimiters or as part of a valid value.
    
    Christine
    

Entry of  TowerSets is made much easier if the user can choose what sorts of
parentheses  to use and can use a mixture.  Note that DECnet-ULTRIX displays
TowerSets as follows:

    Address                      =
       {
          (
          [ DNA_CMIP-MICE ]  ,
          [ DNA_SessionControlV3 , number=19 ]  ,
          [ DNA_OSItransportV1 , 'DEC0'H ]  ,
          [ DNA_OSInetwork , 49::00-41:08-00-2B-02-D7-3B:21 ]
          ) ,
          (
          [ DNA_CMIP-MICE ]  ,
          [ DNA_SessionControlV3 , number=19 ]  ,
          [ DNA_OSItransportV1 , 'DEC0'H ]  ,
          [ DNA_OSInetwork , 49::00-42:08-00-2B-02-D7-3B:21 ]
          ) ,
	etc.

So people will be used to using these (and may want to cut and paste them).

Graham

.2 is right, if you open with a (, you must close with a ). However, that
wasn't Nestor's problem. He opened with a {, and then could not have a
construct contained in ( ) characters within it. As .4 notes, that is
not correct.

On .3, the use of [ ] characters in other data types does not conflict
with them appearing as Set, Sequence or Record delimiters. There was a small
problem in the FileName data type where it did not state that square brackets
must come in matching pairs. But that was fixed in T1.0.1 of the entity model
(ECO EM #11). In no case should that have been a reason not to support [ ] 
as open/close pairs. Note that the record type **recommends** the use of [ ]
on output.

So Graham is right, this bug should be QAR/SPRed and fixed.

					Mark