[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

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

59.0. "Questions/Problems with RECORD Data Type" by BYBLOS::TAMER () Thu Feb 22 1990 16:26

The following is a set of related questions:

1.	It seems that every field of a RECORD is required as an input to the 
	TRM. Is this a TRM or an MCC restriction ? 
	We have some attributes that need to have a RECORD type and some that 
        have a SET OF RECORDs type.  It is inconceivable that a user has to 
        specify all the record fields every time he or she wants to modify a 
        field. Can anything be done about this ?


2.	When will Variable Records be supported ?
 

3.	Are there any readers of this notes file who are using SET, SEQUENCE,
        and RECORD DATA TYPES successfully in the IFT kit ? These types are
        being rejected in the kit that I have as the example below shows.  


4.       I have the following observation (and problem with the ILV encoding):

MCC> SET TPSYSTEM sub QUEUE q qrecord = {name = "q5", id = 5}
%MCC-W-QUOTESYNTAX, Syntax error in quoted string
MCC> SET TPSYSTEM sub QUEUE q qrecord = {name "q5", id  5} 
%MCC-E-ILV_BAD_MODE, ILV Mode inconsistent with Arguments
MICROW:: !<-----exits MCC

        Where qrecord is of type QueueRecord as follows:

     		TYPE
       		  QueueRecord = 15 RECORD
          		name  	= 1 : Latin1String ;
          		id  	= 2 : Integer8     ;
       		  END ;
       
	The first command seems to be rejected by the parser while the second 
        seems to be accepted by it. It looks like the syntax of assigning a 
        value to a record field does not PERMIT an equal sign. Is it true that 

		{<field> <value>} is legal while {<field> = <value>} is NOT ??
	

	NOTE: name and id are not the real fields and cannot be modelled as
        seperate attributes. They have to be a part of a more complex record.
T.RTitleUserPersonal
Name		DateLines
59.1REPLY - hope this helpsGOSTE::CALLANDERFri Feb 23 1990 17:5844
    
    re .0:
    
    1) records do require that all fields be present, that means the
       field name and some value. Defaults are not supported for fields
       in a record. This is described in the SRM. In the data types
       chapter you will note the BNF shows all fields as required, and
       in the enrollment chapter you will note that the MSL syntax does
       not support defaults within records.
    
       About the only thing I can suggest is that you consider using
       a variant record when availble, but even that will not make it
       much nicer. I would need more information about what exactly
       you are trying to do to see what can be done about it.
    
    2) There is still some contention around variable records. During
       the last two months it has come to light that what we were planning
       and what some (not everyone) people were expecting, were not
       the same. As soon as this is settled you will have your variant
       records. My current speculation is EFT update.
    
    3) Current SET, and SEQUENCE  are not supported. We only support
       SET OF and SEQUENCE OF. There are implementation problems with
       trying to support SET and SEQUENCE; more on these two when decided.
       
       As far as RECORD goes it is supported now, I would need to know
       what baselevel kit you are working with to determine if it was
       supported in that release.

    4) Okay from this one (I should have looked at the example more
       closely) I know what you are using and why RECORD doesn't work.
    
       In the release you have constructed data types are not supported
       inside an attribute list. Therefor the record type could not
       be used for an attribute. The ILV mode error is because the TRM
       was incorrectly setting the ILV mode on the RECORD to list instead
       of native mode.
    
       The <field> <value> format is correct, and what is documented
       in the SRM. But...your point is well taken, this seems very
       inconsistent. I will look into what it will take to make the
       = optional.
59.2Problem with SUBRANGE TYPE, notes on replyBYBLOS::TAMERMon Feb 26 1990 14:5856
RE .1:

Jill, 

Thanks for your reply. Here are some decisions that I have made:

 1)  I will try to avoid records that have more than a few fields requiring the
      user to expicitely set them.

 2)  I will try to avoid Variable records unless they become available and they
     are absolutely needed.

 3)  I really meant 'SET OF' and 'SEQUENCE OF' not SET and SEQUENCE,  
     respectively. I will wait for the EFT to use and test these types.

 4)  I think that the optional "=" for assigning a value to a record field makes
     a lot of sense. Hope it is not a lot work for you.


PROBLEM with subrange. Here is the problem:

I define,     

TYPE AlphaString= 16 Latin1String [48..57,65..90,97..122] ; 

in order to restrict a latin1string to the following (0..9, A..Z, a..z)

I enter the following TRM commands:

MCC> set subsystem sub queue q pid="ABC"
%MCC-E-OUTOFSUBRANGE, Value not in subrange

MCC> set subsystem sub queue q pid="012"
MCC> ! accepts it

I redefine the type by reversing the order of the first two pairs in the 
subrange, 

TYPE AlphaString= 16 Latin1String [65..90,48..57,97..122] ;

and I enter the following,

MCC> set subsystem sub queue q pid="ABC"
MCC> ! accepts it

MCC> set subsystem sub queue q pid="012"
%MCC-E-OUTOFSUBRANGE, Value not in subrange


It seems that the problem is: it is trying to validate the string by checking 
the subrange according to the first pair in the subrange definition and not 
according to all the pair(s) {or subsequent ones}.   


Regards,
Phil
59.3Not supportedSCRPIO::LIZBICKIWed Feb 28 1990 14:4916
>> PROBLEM with subrange. Here is the problem:
>>
>> TYPE AlphaString= 16 Latin1String [48..57,65..90,97..122] ; 
>>
>> in order to restrict a latin1string to the following (0..9, A..Z, a..z)

   I asked about subranges such as the one you described above, in
   note 29.*.   I contacted Dave Moore through mail as suggested in 
   29.3, and was told that only a single subrange is supported within 
   a subrange definition (the SRM is incorrect, and the MSL should not 
   accept multiple subranges).  What you are attempting above is not 
   supported, according to the latest info I have.

					Lynne
59.4INFO - Lynne is rightGOSTE::CALLANDERWed Feb 28 1990 17:048
    Lynne is right. It is my understanding that we should be getting
    to it soon, but right now we are trying to pull together all of
    the remaining lose ends, and then prioritize the remaining work.
    I will let you know more when we have definitive dates for the
    remaining TRM work.
    
    jill