Conference azur::mcc

1640.0. "PROBLEM: FCL Problem with two datatypes" by BYBLOS::TAMER () Thu Oct 10 1991 20:19

DECmcc V1.1 on VMS:

I am encountering the following two problems with the FCL parser:

1. When I have an attribute/argument of datatype Expression, the FCL parser allows me
   to have embedded parentheses, as long as they are balanced. 
   When I have an instance of type Expression, the FCL parser rejects any embedded parentheses
   eventhough they are balanced. The example below illustrates: (cutout from the LOG file).


create qms_repos .rep record def recdef def =( (abc)  )
!
!
!*****************************************************
!*     FCL PM Arguments before call_function:        *
!*****************************************************
.
.
.
!
show qms_cd x server ( (abc)  )
!%MCC-W-ATTRSYNTAX, syntax error in attribute )


argument definition on the 'CREATE record def' is an EXPRESSION and so is the 'SHOW server' instance 

CAN THIS BE FIXED for V1.2 since I have a class instance with an expression datatype that 
CAN have embedded parentheses in its selection clause ? 


2. When the instance datatype is an Integer64, the FCL access violates.

   I am trying to use the Integer64 datatype for the alternate identifier instance of the same class.
   If I can't use the Integer64 datatype, I might get around it by using the DTEADDRESS DATATYPE.But I hope
   that Integer64 can also be fixed. 


$ ! mcc_fcl_pm_log is defined to 8 here but no output appears.
$ ! <<<<<<<<<<<Here the instance is redefined to Integer64 in the MSL>>>>>>>

MCC> show qms_cd s server 16161616        
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000, PC
=0024B09C, PSL=03C00000
%SYSTEM-E-ACCVIO, access violation, reason mask=00, virtual address=0000000A, PC
=0000000A, PSL=0000000F


Thanks,
Phil

re .0

Problem 2 in base: Integer64 problem. Well, Unsigned64 works from the FCL and it might be 
enough for me. However, problem 1 (embedded parentheses in instance names) is a
problem that I can't get around.

Phil

Phil, there isn't going to be a way around the imbedded parens. You see
the parser only knows it has hit the end of an expression when it has 
found the "matching" paren. To do this we need some type of rules to
use in figuring it out since there can be any valid character between
the parens (except the "!"). So, we count right and left parens until
we have an even set of matched pairs.

Sorry
jill

re .2

Jill,

What you are saying here is exactly what I need. That is to stop when you have 
an even set of matched pairs of parentheses. 
Currently, this works when the expression is attribute/argument but does not 
work when it is an instance of type expression.

To illustrate further:  if ( (abc) ) is an attribute value, the parser accepts
it. If ( (abc) ) is an instance name, the parser does not accept. This means 
that the algorithm that you outlined in .2:

>So, we count right and left parens until we have an even set of matched pairs.

does work in the attr/arg case and does not work in the instance case.


Did I not understand your reply ?

Thanks again,
Phil


PS: I would like very much for this to be fixed if it is a bug since an entity
that I have depends heavily on this and I haven't figured out how to get around
it in case this can't be fixed.

Phil,
and expression doesn't allow you to state a datatype within the
expression, it simply looks for the matching paren. Your note
confuses me, you would need to be a bit clearer as to exactly
what datatype each thing is declared as being.

thanks
jill
(yes we went to field test so I am back)