Conference azur::mcc

2293.0. "FCL requests required arg even when arg is supplied in directive" by UTES09::GOES (Paul Goes - T&N Digital Utrecht) Fri Feb 07 1992 05:50

Hi, I'm facing a strange behaviour of the FCL PM in DECmcc T1.2.4.

I have a create directive that has a required argument alarm class. Normally,
using the FCL PM it asks for the required argument when you do not supply it 
in your management directive.

My problem is that the FCL PM also asks for the required argument even when
you supply the argument.

To examplify this are included two directives (see below):

Both are create directives; one for a global entity PABX and one for the
child entity ERROR_CODE. The strange behaviour does appear when I
create the child entity ERROR_CODE but not when I create the global entity
PABX !!!

At the bottom of this note is included an extract of the MSL-code for both
directives and to my opinion they are the same.

I'm a little confused. 

If I issue both directives in the V1.1 version of DECmcc it works out fine
but now I translated the PABX AM to support T1.2.4 it no longer does.

Is there a problem with the names 'alarm class' and 'alarm class after system
receipt' are these names conflicting ??

Regards, Paul Goes.


>>> Both directives <<<

MCC> create pabx .pabx_test lat port name = lta203
			   >>> Doesn't ask for argument  OK <<<
PABX UTES09_NS:.pabx_test
AT  6-FEB-1992 16:22:23 

Entity successfully created.


MCC> create pabx .pabx_test pabx_alarming alarm_group SES error_code 2 -
_MCC> alarm class = 2
ALARM CLASS = 2            >>> Interesting Isn't it ? <<<

PABX UTES09_NS:.pabx_test PABX_ALARMING ALARM_GROUP SES ERROR_CODE 2
AT  6-FEB-1992 16:25:03
A PABX-specific exception has occured:
                         Pabx Exception = "Can't logoff from the PABX"

MCC> exit

$

>>> Both pieces of MSL Code <<<

       DIRECTIVE CREATE = 12 :      (* For the global entity PABX *)
	  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;

          RESPONSE 1 till x         (* This is no real code of course *)

       END DIRECTIVE CREATE;


       DIRECTIVE CREATE = 12 :      (* For the child entity ERROR_CODE *)
	  DIRECTIVE-TYPE = ACTION,
	  DISPLAY = TRUE,

	  REQUEST

	      ARGUMENT Alarm Class = 2 : Unsigned8
		 ECHO = TRUE,
		 DISPLAY = TRUE,
		 REQUIRED = TRUE,
		 DEFAULT = NO DEFAULT,
		 SYMBOL = ERROR_CRE_REQ_ARG1
              END ARGUMENT Alarm Class;

	      ARGUMENT Alarm Class After System Receipt = 3 : Unsigned8
		 ECHO = TRUE,
		 DISPLAY = TRUE,
		 REQUIRED = FALSE,
		 DEFAULT = NO DEFAULT,
		 SYMBOL = ERROR_CRE_REQ_ARG2
              END ARGUMENT Alarm Class After System Receipt;

          END REQUEST;

          RESPONSE 1 till x         (* This is no real code of course *)

      END DIRECTIVE CREATE;

    the problem is with the argument names. One argument name is a complete
    subset of the other name. The parser we use is *NOT* a look ahead
    parser and therefore can not tell what to expect next when parsing
    except by distinctly identifying the argument. It looks like FCL
    matched on the first two keywords, and then walked to the end of 
    the string entry (identifying the argument names) and matched on
    the 4 token version of the arugment, that is why you then got 
    prompt for the required argument. Depending upon what other strings
    are in the tables (we store all strings once so this means all strings
    from all modules are optimized and stored in a single table) who knows
    where they are stored and what the FCL will do.
    
    I believe that these arguments will be picked up by the registry as a
    "conflict", requiring you to uniquely name them. Where unique means
    that neither string can be a complete substring of the other.
    
    string1 = foo bar
    string2 = foo bar barbed
    
    if you enter
    
    verb entity string1 value  :== verb entity foo bar value
    if value :== barbed		   verb entity foo bar barbed
    
    how can this be distinguished from
    ver entity string2 !default value	:== verb entity foo bar barbed
    
    If the FCL is ever enhanced into being a look aheadh parser we could
    potentially make a more intelligent descision; but for now we are
    limited in how we handle multi keyword attr/args (we initially didn't
    handle them at all, and that was how we designed the parser).
    
    sorry.
    

Thanks for your reply but I have one question left.

You're talking about the parser as being a non-lookahead parser and maybe
the parser will be changed to a lookahead parser in the future. But ...

... Why was the same arrangement of arguments working for DECmcc V1.1 ?
    As I understand from your reply the parser in DECmcc V1.1 was also
    a non-lookahead parser and my access module is converted from
    DECmcc V1.1 to T1.2.4 and the V1.1 version never showed this problem. 

Regards, Paul Goes

    the on ly way you should be seeing a difference in the parsed
    output between v1.1 and T1.2.4 is if you are running with different
    data in the dictionary.
    
    The parser has not been modified between the two releases.
    
    The end results are that when you change the dictionary contents you
    change what happens (when conflicts are seen or not). No quick way to
    find out just what is going on, sorry. If you do need more
    investigation done so that you can alleviate this please let me know
    and we will see what can be done (note it would have to wait until
    after the v1.2 goes to SSB).
    
    jill