Conference azur::mcc

    The "L" in TLV is 2 bytes long, which would give you a max of 32767
    unless it treats the field as unsigned at which point it could
    conceivably go up to 65536, but ASN uses the high order bit of its tags
    for various purposes so I wouldn't be surprised if it reserved the
    sign bit of the length field also.   Maybe as ASN.1 heavy could
    elaborate...
    

        The 32500 byte restriction is due to the way ILV/ASN was originally
coded, and due to the restrictions on VMS descriptors which has been 
inherited by mcc descriptors.  A VMS descriptor can point to 65535 of an
item, in the ILV/ASN case, bytes.  Due to size expectations and code
efficiency, the ILV/ASN code reserves 2 length bytes after each tag.  
The ASN.1 BER specifies that if there is more than one byte of length, 
the 7th bit is reserved for continuation. So, we loose another bit.  
The remainder of the loss is a safety factor & rounding.

        We could gain the extra bit by reserving an additional byte for the 
length and adding checking to be sure the actual length fits our descriptors. 
Note that this would require one byte per tag-- one byte for every
ilv_put_xxx call in Native Mode.
        Since the majority of the encodings don't require even 2 length bytes, 
and a better way to do this would be to re-write the mcc_asn routines to "save
bytes" by not pre-reserving the length space, the factor of two in available 
encoding buffer bytes has been sacrificed.

So, the answer to a) is no, not now.

I'm afraid I don't know about b).

Ruth Kohls

re .2,

Thanks Ruth for the explanation. 

Are there firm, future plans to fix this SERIOUS PROBLEM, say by re-writing 
the mcc_asn-* routines ?

regarding b) in the base note, I am still hoping to receive an answer.

Phil 

    Why is this a SERIOUS PROBLEM  (your caps, not mine)?
    
    What are you ILV encoding?
    

>Are there firm, future plans to fix this SERIOUS PROBLEM, say by re-writing 
>the mcc_asn-* routines ?

Now is the time to submit v2.0 requirements.  Do you know of another
group that is hitting this limit, or the nesting depth of 12 limit?
Can you tell me that 65 K is your absolute maximum size requirement, or
what is?  Also, nesting depth requirements.

Put your size requirements for buffers or a requirement for segmentation
and reassembly of data buffers containing single encodings, or both, into 
the mcc_futures notesfile, and also send it to requirements gatherers, such
as the DECmcc product and engineering managements.  

>regarding b) in the base note, I am still hoping to receive an answer.

is there any way to split this 65 K attribute into smaller pieces?  Is it
a single Latin1string?  The only way I can think of to do what you want
*generically* is to use the handle protocol, but you will still need smaller 
buffers for attribute segments, and you would not be using the handle protocol 
"according to the book" -- this would be "why more? = data buffer segmentation".

Given a description of the attribute (size & size range, datatypes-- its
msl description) we might be able to come up with a *particular* solution.

Keith, Colin, Jim, other gurus--do you have ideas?

Ruth

The DECmcc Call Protocol (MCC_CALL_FUNCTION/ACCESS) only returns one
Entities Partition worth of data at a time.  Like all the Characteristic
Attributes for a Phase 4 Node (show node foo all char).

The protocol doesn't allow for returning segmented Out-P buffers - at least
not today.

Now, for a moment, lets imagine that there is no ILV.  Your Out-P buffer
is an in-memory structured list of MCC Descriptors...of (virtually) 
unlimited size!  Sounds good.  But this would only work if the two Management
Modules were in memory together - as in the DECmcc/VMS model we use today.

For Ultrix, which uses an RPC method, the in-memory Out-P structure would
need some kind of encoding. The data would be shipped over to the remote
Mangement Module (MM) and decoded again.  This would be transparent to your MM.

The mechanism which the IM/Dispatcher (who would route the Data Request) uses
to encode and decode the data would require the ability to manage (virtually)
unlimited size buffers - ILV could be extended here - or whatever encoding
technologies is appropriate.  If the encoding technique actually buffered
up the data, piped it to the remote side which decoded it on the fly, then
there wouldn't need to be this single chuck of intermediate memory (ie, 
the ILV buffer).

Food for thought.

/keith

The attributes in question are Expression datatypes, which are basically 
Latin1strings enclosed in parentheses. These are application info and some of
them might be quite large. I was hoping to place a restriction of the
architected size of 65,535. 

I will have it on my requirement list.

re .4,

I consider it a problem because several datatypes are claimed to support up
to 65,535 bytes, but currently there is no apparent way to encode half that 
amount ! 

For now, I guess I have to live with it or have to find a way around it.  



On a related subject,

What is the limit on the PM input buffer? I have an FCL script that issues
a CREATE directive with an argument of type <SET OF RECORD>. When I have
a few elements (each field on a separate line), the FCL is not accepting the 
input. It looks like it is trying to truncate or don't accept more than 
something like 1024 bytes.
Is this true ? If so, why is it this size ? What about the IMPM, what size
does it impose on input ?



Thanks for all replies,
Phil  

or so that was my understanding as to why the limit (also that seemed
awful huge).

jill

First of all, MCC already should be able to parse length fields of 1-4 bytes
and indefinite-length.  The only reason that it encodes using 2-byte
lengths is that it makes it MUCH easier to predict how many bytes of
buffer space are required for a constructed value, such as a SET OF.
There is no need for the strict 2-byte encoding for primitive values,
since you already know the length of a primitive value at the time of the
PUT call.  There are other options, such as indefinite-length encoding.
Indefinite-length encoding has the added advantage that you don't have
to know the length of the entire PDU before you send any of it!
A MCC_ASN rewrite is not required to fix this problem.

Keith's idea is good, the DECnet-ULTRIX CMIP protocol engine works more or
less that way.  I didn't do MCC_ASN that way because there was no 
concept of an input or output device associated with an ASN.1 message
or ILV buffer.  This was to all be handled by the AM, dispatcher, etc.
My only concern was to make sure the data could traverse multiple address
spaces with no change (for RPC support).