Conference azur::mcc

    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.
    

    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
    

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

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.)

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

>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.

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

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.

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

    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
    

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

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

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.

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

>
>                    -< 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

> 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

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.

    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.

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>

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

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

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!