Conference azur::mcc

    
    to do the conversion from the user string to the encoded value we
    simply:
    
          sscanf(p_temp, "%E", (double *)p_object_desc->mcc_a_pointer);
          p_object_desc->mcc_w_curlen = 8;

    
    dont' know if this helps...
          

    
    re: .1 Thanks for the help but I'm adding this to an AM written in
    Pascal and unless I'm missing something, it doesn't answer my question:
    
    I don't understand what the relationship between 9.0 and the ILV 
    dump is and how MCC passes reals up and down the stack.
    
    [  0 ] (
        [  1 ] (
            [  18 ] (
                [  1 ]             48  -- H
                [  2 ]             81 ff cf 12 00 00 00 00 00 00
    				   | 
    				   Is this the real number 9.0 encoded as
    				   an array of bytes?
    
    				   Why is it ten bytes long?
    
    
    

    
    I don't understand what the relationship between 9.0 and the ILV 
    dump is and how MCC passes reals up and down the stack.
    
    [  0 ] (
        [  1 ] (
            [  18 ] (
                [  1 ]             48  -- H
                [  2 ]             81 ff cf 12 00 00 00 00 00 00
    				   | 
    				   Is this the real number 9.0 encoded as
    				   an array of bytes?
    
    				   Why is it ten bytes long?
    
ILV is based on ASN.1 encoding.  A real number is encoded 
as a fraction and an exponent, and the encoding is hardware specific.
For VAX hardware, our implementation of ASN.1 uses the G Float form, the 
closest VAX form to the international standards.  (We do not yet properly
d/encode real numbers for other hardware, including our RISC stuff.  We
will for DECmcc on Ultrix.)

So, no it is not an array of bytes, it is an encoded real number, able
to be interpreted by any hardware & software that understands  ASN.1 encodings.

ILV Dump is dumping bytes on the screen without attempting interpretation.
It only truly interprets text strings.  All encodings are dumped byte
for byte, as hex numbers. 

MCC is passing on the stack what you put there.  IF you say the number in the 
mcc descriptor you pass to ILV to be encoded is a real, it 1) gets converted
to G-float from other forms and 2) gets encoded in international standard
form into the buffer you supplied for the encoding.  See the SRM description
of the MCC call parameters for how each one may be encoded.

Have we hit the real question yet?

Ruth Kohls

    I'm beginning to understand now and hopefully this last question will
    clear things up:

    [  0 ] (
        [  1 ] (
            [  18 ] (
                [  1 ]             48  -- H
                [  2 ]             81 ff cf 12 00 00 00 00 00 00
    				   
    If entry [ 2 ] in the ILV is the G-float rep of 9.0, then why is
    it 10 bytes long?  Double floats are 64 bits.


    

          <<< Note 767.4 by LEVERS::CIARFELLA "Saabless and happy" >>>
                      -< One more clarification, please. >-


    I'm beginning to understand now and hopefully this last question will
    clear things up:

    [  0 ] (
        [  1 ] (
            [  18 ] (
                [  1 ]             48  -- H
                [  2 ]             81 ff cf 12 00 00 00 00 00 00
    				   
    If entry [ 2 ] in the ILV is the G-float rep of 9.0, then why is
    it 10 bytes long?  Double floats are 64 bits.

>I knew you'd ask, as soon as I looked and saw the discrepancy myself.

> It isn't the G-float representation, which ILV et al expects (requires)
> to be 8 bytes (64 bits) long.  This is the ASN.1 encoding of the
> VAX G-Float.  There is more information than simply the fraction and
> exponent that needs to be encoded.  Different machines use different
> bases for representing reals, negative numbers can be ones or twos
> complement, etc.  To pack more numbers into less bits, the VAX architecture
> does some unique stuff with the exponents of real numbers. 

>ILV dump interprets tags (the stuff in []'s) and attempts to
>interpret anything that might be text.  The interpretation comes
>after the "--".  When we added Real as a primitive ASN.1 datatype,
>we didn't extend ILV dump to deal with Reals.

>If you think you're having trouble getting out of a real encoding what you
>put in, decode it using the ILV get routines, and look at it that way.

>Ruth

    
    Thanks, Ruth.  I understand now how to pass reals up and down the
    mcc_call stack.  
    
    Paul C