3 Replies Latest reply on May 27, 2014 3:23 PM by Todd Little-Oracle

    Is FML32 really FML32 ?

    Kristian Ivarsson

      We're using FML32 with

       

      > uname -a

      Linux sadbtestutvfm5app1 2.6.32-431.5.1.el6.x86_64 #1 SMP Fri Jan 10 14:46:43 EST 2014 x86_64 x86_64 x86_64 GNU/Linux

      > tmadmin -v

      INFO: Oracle Tuxedo, Version 12.1.1.0, 64-bit, Patch Level 040

       

       

      The FML-field FML_SOME_LONG is of type FLD_LONG

       

      In a case we had a defect where we try to do the following

       

         double some_decimal_value; // i.e. contains something random, perhaps a large, value

         Fadd32( buffer, FML_SOME_LONG, (char*)&some_decimal_value, 1);

       

      Of cource this is wrong (i.e. try to add a double to an FML-field of type FLD_LONG, but if the service is called from another domain that do not have the same MTYPE, GWTDOMAIN seems to try to do some encoding and fails with

       

         081340.674.vsgfme!GWTDOMAIN.5746.3987982080.0: LIBTUX_CAT:6031: ERROR: Unable to pre-process buffer before tranmission.  Error code(12/4914)

         081340.674.vsgfme!GWTDOMAIN.5746.3987982080.0: LIBGWT_CAT:1282: ERROR: Memory allocation failure for compression

         081340.674.vsgfme!GWTDOMAIN.5746.3987982080.0: LIBGWT_CAT:1041: ERROR: Unrecoverable error occurred on send of data - sending failure reply over network

         081340.674.vsgfme!GWTDOMAIN.5746.3987982080.0: GP_CAT:1048: ERROR: Don't know how to encode/decode data for request opcode 0x30000000

         081340.674.vsgfme!GWTDOMAIN.5746.3987982080.0: LIBTUX_CAT:6031: ERROR: Unable to pre-process buffer before tranmission.  Error code(12/4914)

         081340.674.vsgfme!GWTDOMAIN.5746.3987982080.0: LIBGWT_CAT:1282: ERROR: Memory allocation failure for compression

         081340.674.vsgfme!GWTDOMAIN.5746.3987982080.0: LIBGWT_CAT:1041: ERROR: Unrecoverable error occurred on send of data - sending failure reply over network

         081340.674.vsgfme!GWTDOMAIN.5746.3987982080.0: GP_CAT:1048: ERROR: Don't know how to encode/decode data for request opcode 0xffffffffffffd8f0

         081340.674.vsgfme!GWTDOMAIN.5746.3987982080.0: LIBTUX_CAT:6031: ERROR: Unable to pre-process buffer before tranmission.  Error code(12/4914)

         081340.674.vsgfme!GWTDOMAIN.5746.3987982080.0: LIBGWT_CAT:1282: ERROR: Memory allocation failure for compression

       

      The "Memory allocation failure" implies that the error-handling in GWTDOMAIN is a bit suspicious as well

       

      I calling the service with UD32 (from same domain or domain with same MTYPE) also give us some strange results and output values larger than what would fit into a 4-byte (32-bit) integer. Since we're using a 64-bit architecture, the value it self is not strange, but since we're using FML32 we thought that it would use one of the 32 bits (BE/LE) and thus the transported/handled value would never be larger than std::numeric_limits<int32_t>::max()

       

       

      So, of cource we know how to fix this and we know that we're doin' wrong but,, is FML32 really FML32 or does it just become (narrowed to) 32-bit when MTYPE-encode/decode occurs ?

       

       

      Best regards,

      Kristian

        • 1. Re: Is FML32 really FML32 ?
          Per Lindström

          My understanding of the "32" in "FML32" has always been that it relates to the possible number of FLDID:s, not that it's really related to the number of bits in the actual field values.

           

          My understanding is that the version of Tuxedo (i e "32-bit" or "64-bit"), along with your C[++] compiler options, is what actually sets the limits of the field VALUES.

           

          You should be able ("been there, done that") to use FML32 to communicate between 32-bit and 64-bit versions of Tuxedo, although it will obviously be trouble if you try to send 64-bit (long) values that can't be represented in 32 bits to a Tuxedo application (or machine) using [only] 32-bits. Just one of the little "joys" of migrating from 32 to 64 bits :-).

           

          Hope this helps,

          /Per

          • 2. Re: Is FML32 really FML32 ?
            Kristian Ivarsson

            Hi Per,

             

            great answer and it seems like a reasonable answer and I'm a bit shamed that I did not think of that

             

            Yupp, it's a PITA to go from 32 to 64, but it would be helpful if we had a typesystem that took care of it instead of C-casts-from-hell combined with some obscure runtime-errors ;-)

             

            Best regards,

            Kristian

            • 3. Re: Is FML32 really FML32 ?
              Todd Little-Oracle

              Hi Kristian,

               

              Welcome to the world of C.  :-)   Unfortunately I think C casts are with us forever, at least in C.  And Per is correct in that FML vs FML32 is not about the data values but about the number and kinds of fields that are supported.  Most notably FML32 supports embedded field types that FML doesn't support.  Moving from 32 bit to 64 bit in C has always been a bit of a challenge due to the attempt to provide compatibility in the language that really didn't cut it.

               

              Regards,

              Todd Little

              Oracle Tuxedo Chief Architect

              1 person found this helpful