[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

915.0. "PROB: Bugs/inconsistencies Using BITSET of Enumeration" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Mon Apr 15 1991 16:53

V1.1 SSB

MSL details are at the end of this posting. To summarize, the problems
described here are for a BitSet of Enumeration.

(1) When processing an ILV value of datatype BitSet, mcc_ilv_get
    expects a buffer size of 32 *bytes* instead of 32 *bits*. Even
    though sizeof (MCC_T_BitSet) is 4, the ilv_get will fail with
    ILVTOOBIG until the buffer size is increased to 32. Once that
    buffer size is specified, the correct bits are set in the low byte
    for the specified set elements (I don't have enough elements
    defined to test more than the low byte). This is the ILV generated by
    either PM for the Options argument on the Diagnose directive, defined
    below.

(2) The FCL will not format the Bitset as a set when it appears as
    a native response argument. But it will properly format the
    attribute when it is an element of the attribute list argument in
    the response to Show. Examples along corresponding ILV appear below.

(3) The IMPM shows the "Diagnosis Options Set to %X08000000" string in 
    response to the Diagnose, and "Error in %Octet string value" in 
    response to the Show. The former behavior is the same as FCL, the latter
    is not.

The ILV below is out_p on return from the directive entry point.

MCC> diagnose mcc 0 atlas_am options = {break}  /* this is an arg of BitSet */

[  2 ] (
    [  193 ]     04 40
    )

MCC 0 ATLAS_AM
AT 15-APR-1991 11:23:14

Diagnosis Options Set to %X02000000

MCC> show mcc 0 atlas_am options  /* This is an attr list */

[  1 ] (
    [  1 ] (
        [  193 ] (
            [  1 ]             0b
            [  2 ]             04 40
            [  3 ]             00
            )
        )
    )

MCC 0 ATLAS_AM
AT 15-APR-1991 11:21:56 Status

                                Options = {Break on Directive Entry}

/* The MSL for above */

    TYPE Options = 1 (All = 0, Break on Directive Entry = 1, Trace = 2,
                      Dump ILV = 3, Val16 = 4, Val32 = 5, Val64 = 6,
                      Val128 = 7);

    TYPE OptionsBitset = 2 BITSET OF Options;

         ATTRIBUTE Options = 193 : OptionsBitset
           SYMBOL = ATTR_OPTIONS
         END ATTRIBUTE Options;

       DIRECTIVE Diagnose = 52 :
         (* This directive will set the Options attribute, or if no
            argument value is supplied will generate a debugger
            breakpoint. *)
         DIRECTIVE-TYPE = ACTION,

         REQUEST
           ARGUMENT Options = 193 : OptionsBitset
             SYMBOL = ARG_OPTIONS
           END ARGUMENT Options;
         END REQUEST;

         RESPONSE Diagnosis Started = 1 :
           SYMBOL = DIAGNOSE_STARTED,
           TEXT = "Diagnosis Started"
         END RESPONSE Diagnosis Started;

         RESPONSE Diagnosis Options Set = 2 :
           SYMBOL = DIAGNOSE_OPTIONS,
           TEXT = "Diagnosis Options Set to !<Options>",
           ARGUMENT Options = 193 : OptionsBitset
             SYMBOL = ARG_OPTIONS,
             DISPLAY = FALSE
           END ARGUMENT Options;
         END RESPONSE Diagnosis Options Set;

       END DIRECTIVE Diagnose;
T.RTitleUserPersonal
Name
DateLines
915.1PROB: IMPM validation inconsistentCOOKIE::KITTELLRichard - Architected Info MgmtMon Apr 15 1991 22:4712
    Another anomaly with the BitSet datatype has been reported. Some
    sharp-eyed users have noticed that the IMPM treats a BitSet differently
    than a SET OF with respect to the enclosing delimiters. With a SET OF,
    the field can be | {Trace}  or | Trace  . With BitSet, a validation
                     +---------    +-------
    error occurs unless the braces are supplied.
    
    Of course, it wasn't reported that way to me. My users only noticed
    that the braces were optional on one attribute and required on another.
    They see the difference in datatype as an uninteresting implementation
    detail.
    
915.2used differentlyTOOK::HAOTue Apr 16 1991 13:1218
    Richard,
    
    This is the possible reason between the difference in Diagnose and
    Show in FCL.  Jill will verify and qar as needed (please, Jill?).
    
    In the Diagnose command, it appears that you define your response
    argument to be non-displayable, such that the argument's value is only
    used to fill in your return Text.  I believe that "fao" argument
    support in the Text string is currently limited to certain datatypes
    such as numeric, latin1strings, and enumerations.  When the FCL code
    sees a datatype it can't currently support, it will just handle it as
    an octet string.
    
    In the Show command, the bitset being returned is displayable, and not
    part of a Text string substitution.
    
    Christine
    
915.3restriction: don't substitute !<BitSet> in argument textCOOKIE::KITTELLRichard - Architected Info MgmtTue Apr 16 1991 14:0312
RE: .2

Christine,

Good thinking! I took out the argument substitution from the text and made
the argument displayable. FCL now displays the response arg correctly.

IMPM now responds with "Error in octet string value" for the response to
both the Show and Diagnose.

Thanks
915.4PROBLEM: {} not accepted for argument of BitsetCOOKIE::KITTELLRichard - Architected Info MgmtWed Apr 17 1991 13:5714
FCL will accept {} as a value for a directive argument of datatype SET OF
enumeration:

CREATE MEDIALIBRARY MUMBLE POLICIES ENABLED = {}

But the same value supplied to an argument whose datatype is BITSET OF 
enumeration elicts: 

MCC> DIAG MCC 0 ATLAS_AM OPT = {}
%MCC-E-ENUMERATION_ERR, no such Enumeration value

(I've re-titled the basenote, since more BitSet problems than displaying
 are discussed.)
915.5oops, bitset {}TOOK::CALLANDERWed Apr 17 1991 19:319
When I got {} to work for sets and sequences I didn't even think about
the bitset argument. I will take a look at that one and see what I can
do. As to the FAO substition problem, I will have to contemplate that
one a bit more. The schedule for 1.2 is real tight (unless you don't
want the notification PM)...so I am trying to limit FCL work to only
those items viewed as mandatory...and you can simply remove it from
the FAO list, but {} is a bug from the users view.

QAR 610 in MCC_INTERNAL
915.6COOKIE::KITTELLRichard - Architected Info MgmtWed Apr 17 1991 22:5112
>do. As to the FAO substition problem, I will have to contemplate that
>one a bit more. The schedule for 1.2 is real tight (unless you don't

Jill,

Don't burn any mental MIPs on our account for being able to substitute
BitSet as an FAO arg. It is no problem to do without.

Now, getting the IMPM to display a BitSet at all is a little more
important, but that is not your cubicle.

915.7You found some Iconic Map bugsVERNA::V_GILBERTThu Apr 18 1991 19:0218
Re .1

Anomaly is a nice word for bug - but the value entered by the user is passed to
a validation routine used by both the Iconic Map and the FCL and it does expect
braces.  I will add code to supply the braces if not supplied by the user.

Re .3

IMPM responds with "Error in octet string value" for the response to both
the Show and Diagnose.  I will guess that the curlen of the value to be
displayed exceeded 2.  The maximum length for the bitset datatype was 
erroneously set to 4 and it should be (and will be) (curlen *2) + 2.

Re .6

The above fixes should get the IMPM to display a BitSet.

Verna
915.8more infoCOOKIE::KITTELLRichard - Architected Info MgmtFri Apr 19 1991 22:1013
RE: .7

Verna,

I tried setting the curlen to 2 right before I did the mcc_ilv_put call.
Same error. I tried it again setting curlen to 1. I didn't get the
error, but the value was formatted as octet string in the Show window,
not a bitset of enumeration.

Sill that is better than the error, so I'll put in some workaround code
to force the curlen to 1 when converting bitsets to ILV.

Thanks.
915.9can't convert more than 8 bits to ILVCOOKIE::KITTELLRichard - Architected Info MgmtFri May 03 1991 19:0421
RE: .7

>displayed exceeded 2.  The maximum length for the bitset datatype was 
>erroneously set to 4 and it should be (and will be) (curlen *2) + 2.

Verna, 

I'm not sure that came out the way you intended. The SRM says between
1 and 32 bits, right? The Entity Model has much grander limits, but
32 bits is good enough for me at the moment.

With V1.1 SSB the limit is effectively 8 bits. I just had occasion to
add my 9th enumerated value to a bitset. mcc_ilv_get correctly sets the
low bit of the second byte, but mcc_ilv_put only encodes one byte, so
I can get bitsets longer than a byte into the system, but they can't
ever get back to a PM for display.

Richard


915.10length fields are in bitsTOOK::HAOMon May 06 1991 15:5323
    Hi there,
    
    re. Richard, Verna,
    
    I'm getting confused with the length fields being so low.  When I was
    still working on FCL (which, admittedly, is over a year ago), the
    length fields for the BitSet datatype is supposed to be in BITS, not
    bytes.  For instance, on input, the FCL always sets 32 for
    mcc_w_maxstrlen.  (Pete, Jill, has this changed?)  So anyways, my
    point is that I'm concerned that the length fields aren't being set
    properly, which may be why they're not encoded properly??  Just a
    guess.
    
    re. Verna.
    
    The common datatype conversion routine (mcc_pml_cvt_obj_str) that FCL 
    and Iconic Map shares has Bitset datatype conversion defaulting to 
    OctetString.  I believe FCL specifically checks for the Bitset datatype
    and calls another routine without allowing the case of ever falling
    into the default routine.
    
    Christine
    
915.11BitSets fully functional from FCL nowCOOKIE::KITTELLRichard - Architected Info MgmtMon May 06 1991 23:4516
RE: .10

Christine,

I forced the mcc_w_curlen to 32 before calling mcc_ilv_put for a BitSet,
and FCL will now display bits outside of the first byte. So when going
to/from ILV the length values should be bits. I have to leave them in
bytes the rest of the time so the various copy, compare and init routines
still work.

Making them work from FCL makes them break from IMPM, but hey, we're
making progress.

Richard

915.12Let me clear up reply 915.7VERNA::V_GILBERTWed May 08 1991 20:1817
Richard,

I guess I was not very clear in reply 7, re .3

When I said that the maximum length for the bitset datatype was erroneously
set to 4 and should be (curlen*2) +2,  I meant that the Iconic Map has an
error and it currently (and buggily) expects no more than 4, whereas when I
fix it, it will allow for curlen*2 +2.  So, right now, the only way for you
to not get an error is for your curlen to be 1 or maybe 2.  

As far as the display, the Iconic Map gives no added value to the display
of bitset.  If our display is a problem, it will have to be bumped up to 
management, since at this point we have no time scheduled to display it in a 
more user-friendly format.

Hope this helps.
Verna
915.1332 bits is all we need, display is fineCOOKIE::KITTELLRichard - Architected Info MgmtWed May 08 1991 20:3714
RE: .12

Thanks for the update, Verna.

As long as we can have a BitSet of an enumeration with values 0 through 31
and have it displayed by the Iconic PM, we'll be in good shape. I understand
that there is currently a bug limiting the values to 0 through 4, and
that you'll try to fix it for a future release.

The display of BitSet is fine. I've noted some inconsistencies between
how a BitSet of enumeration and a Set of enumeration is displayed, but
those are all subtleties, and can't pull rank on the other important
things you are doing.
915.14Warning - larger BITSETs are comingCAPN::SYLORArchitect = Buzzword GeneratorTue May 21 1991 23:115
Just a warning, there was recently a request to register a BITSET 
that would end up being 32 bits wide. I'd think real hard about fixing
BITSETs so longer BITSETs can be supported if I were you

Mark
915.1532-bit BitSets are *here*, Mark...TOOK::MCPHERSONi'm only 5 foot one...Wed May 29 1991 17:4511
>
>                    -< Warning - larger BITSETs are coming >-
>

They're *here*.   I'm working with a 3rd-party who's AM requires 32-bit bitsets
all over the place &  It's making the FCL barf...

I have all of my fingers crossed that this is going to be fixed in 1.2 (really
makes typing difficultm, though... ;^)    )

/doug
915.16 ILV handling of BitsetTOOK::KOHLSRuth KohlsTue Jun 11 1991 14:3222
> When processing an ILV value of datatype BitSet, mcc_ilv_get
>   expects a buffer size of 32 *bytes* instead of 32 *bits*. Even
>    though sizeof (MCC_T_BitSet) is 4, the ilv_get will fail with
>    ILVTOOBIG until the buffer size is increased to 32. Once that
>    buffer size is specified, the correct bits are set in the low byte
>    for the specified set elements (I don't have enough elements
>    defined to test more than the low byte). This is the ILV generated by
>    either PM for the Options argument on the Diagnose directive, defined
>    below.

Sorry It took me so long to notice this.  As Christine mentioned, for
Bitset, ILV put and get expect curlen to be in # of Bits, and any number
of bits from 1 to 32 is Ok.  Note that the min length is 1 bit (which will
require 1 byte of buffer).

I didn't see this mentioned in the mcc_ilv_xxx sections of the SRM, so I will 
add it to the list of errors to be fixed in the next version of the SRM, and
qar the SRM, if it hasn't already been done.

Ruth

915.17bitset qarTOOK::CALLANDERJill Callander DTN 226-5316Tue Jun 11 1991 17:348
there is also a bug, detected by Doug M. from the SVP group, with bitset.
What it comes down to is the fact that the bitset routine is not correctly
keeping track of its' pointer into the bitset structure. In many cases it
can/will walk past the end of the data space and give erroneous results (if
you are lucky enough to keep it up and running). A bug fix for this will
be in the next VMS available build. As my understanding is now this will
not effect the released products since no one is currently (in the field)
using the bitset datatype.
915.18check againNAC::ENGLANDWed Jun 12 1991 16:303
    If you ship the Phase V AM, then you are using the 
    BitSet data type, or at least NCL is.  For example, the node entity's
    supported functions attribute.
915.19DNA5 AM Bitset display....TURKEY::J_HALPINYou might say that. I couldn't possibly comment!Wed Jun 12 1991 19:2115
Jaspie>man/ent
DECmcc (V1.1.0)

MCC> show node quiff all status

Node JASPIE_NS:.quiff
AT 12-JUN-1991 16:19:10 Status

Examination of attributes shows:
                                    UID = 7E9C3460-1D17-11CA-9E98-08002B081D9C
                                  State = On
                      Functions Enabled = {Address Watcher,CMIP Listener}
                                     ID = 08-00-2B-08-1D-9C
MCC>
915.20and here's how you break it...MCDOUG::MCPHERSONi'm only 5 foot one...Wed Jun 12 1991 19:416
How wide is the BITset?

Try Enabling a lot of functions (i.e. turn on the bits one by one) and see if 
you get a reserved operand fault after a few operations...

/doug
915.21calcuation bug in bitsetTOOK::CALLANDERJill Callander DTN 226-5316Fri Jun 14 1991 13:4120
Ben. like Doug said, this problem only occurs when you turn on lots of
bits in the set.  Since the definition of the bitset in question here
is 
     TYPE
         Function = 1 (
             Address Watcher = 0,
             CMIP Listener = 1);

     TYPE
         Functions = 2 BITSET OF Function;

The problem will never be encountered. I also checked all other bitset
definitions in the V1.1 DNA5, none of them have a large enough definition
of the bitset to cause the problem (reserved operand) to be seen. To see
if you would hit the problem, add up the values for all of the items in
the bitset (in the above example: 0+1=1), if the number exceeds 32 then
you will be able to reproduce the problem by setting enough bits to have 
their value exceed 32.

jill
915.22BITSET OF Unsigned8STAR::PITCHERSteve Pitcher/VMS EngineeringThu Sep 26 1991 14:3419
All the previous examples seem to be using BITSET of an enumerated type.
I'm trying an even simpler BITSET.  In the TEST entity, the attribute 
Type Bitset is defined as: 

	ATTRIBUTE Type Bitset = 1033 : TypBitSet

where, of course, TypBitSet is defined as:

	TYPE TypBitSet = 36 BITSET OF Unsigned8;

Now, when I type:

	MCC> SET NODE WALUNG TYPE BITSET = {1,2,3}

It responds:

	MCC-E-INVALID_BASETYP, invalid base type.

This looks so simple!