Conference pamsrc::decmessageq

/*  cc -migrate -std1 -g2 -o test_sdm_handles test_sdm_handles.c -ldmq  */
#include <stdio.h>

#include <p_entry.h>
#include <p_typecl.h>
#include <p_return.h>
#include <p_symbol.h>

#define DMQ_Succ(exp) ((exp) & 1)
#define DMQ_Fail(exp) (!DMQ_Succ(exp))

#define DMQ_Check(exp,rout) if DMQ_Fail(retstat = (exp))	\
	{							\
	  printf ("%s returns %d; %s\n", 			\
		  rout, retstat, dmq_error_text(retstat));	\
	}


#define TAG_ONE   1
#define TAG_TWO   2
#define TAG_THREE 3


char *dmq_error_text (int32 dmq_status);
void EncodeSome (pams_handle sdmhandle);
void DecodeSome (pams_handle sdmhandle);


main()
{
  pams_handle   sdmhandle;
  int32  	retstat;


  DMQ_Check(pams_create_handle (sdmhandle, NULL), "pams_create_handle");

  /*
  **  Stuff something in the handle
  */
  EncodeSome(sdmhandle);

  /*
  ** Try to get it out again
  */
  DecodeSome(sdmhandle);

  /*
  **  Even the set_position seems broken
  */
  {
    int32 tag, flags;
  		
    flags = PSDM_ANY | PSDM_FIRST;
    tag = PSDM_NULL_TAG;
  
    DMQ_Check( pams_set_msg_position (sdmhandle, &tag, &flags), 
	      "pams_set_msg_position");
  }

  DMQ_Check(pams_delete_handle (sdmhandle), "pams_delete_handle");

  /*
  **  Now we MAKE IT WORK
  */
  {
    char    buffer[65535];
    uint32  msglen  = 65535,
            msgused = 0;

    DMQ_Check(pams_create_handle (sdmhandle, NULL), "pams_create_handle");
    EncodeSome(sdmhandle);

    DMQ_Check ( pams_extract_buffer (sdmhandle, buffer, &msglen, &msgused), 
	       "pams_extract_buffer");
    
    DMQ_Check(pams_delete_handle (sdmhandle), "pams_delete_handle");


    DMQ_Check(pams_create_handle (sdmhandle, NULL), "pams_create_handle");

    msgused = 0; /* MANDATORY TO MAKE IT WORK */
    DMQ_Check( pams_insert_buffer (sdmhandle, buffer, &msgused),
	      "pams_insert_buffer");
    

    printf ("\n\nafter extract-insert buffer\n\n");
    DecodeSome (sdmhandle);


    DMQ_Check(pams_delete_handle (sdmhandle), "pams_delete_handle");
  }

  return 0;
}

void EncodeSome(pams_handle sdmhandle)
{
  int32  	an_int32,
    		tag, flags, valuelength,
  		retstat, i ;

  an_int32 = TAG_ONE;
  tag      = TAG_ONE | PSDM_INT32;
  DMQ_Check(pams_encode_int32  (sdmhandle, &tag, &an_int32),
"pams_encode_int32");

  an_int32 = TAG_TWO;
  tag      = TAG_TWO | PSDM_INT32;
  DMQ_Check(pams_encode_int32  (sdmhandle, &tag, &an_int32),
"pams_encode_int32");

  an_int32 = TAG_THREE;
  tag      = TAG_THREE | PSDM_INT32;
  DMQ_Check(pams_encode_int32  (sdmhandle, &tag, &an_int32),
"pams_encode_int32");
}

void DecodeSome (pams_handle sdmhandle)
{
  int32  	an_int32,
    		tag, flags, valuelength,
  		retstat, i ;


  flags = PSDM_ANY | PSDM_FIRST;
  tag = PSDM_NULL_TAG;

  DMQ_Check( pams_set_msg_position (sdmhandle, &tag, &flags), 
	    "pams_set_msg_position");

  for (i = 0; i < 3; i++)
    {
      tag = valuelength = an_int32 = 0;
      DMQ_Check( pams_next_msg_field (sdmhandle, &tag, &valuelength), 
		"pams_next_msg_field");

      DMQ_Check( pams_decode_int32 (sdmhandle, &tag, &an_int32), 
		"pams_decode_int32");
      printf ("Decoded tag: %d, an_int32 = %d\n", tag, an_int32);
    }
}


char *dmq_error_text (int32 dmq_status)
{
  int32 dmq_message_len;
  int32 dmq_severity;
  static char dmq_message [255];
  int32 dmq_message_size=sizeof (dmq_message);


  if (pams_status_text ( &dmq_status,
                         &dmq_severity,
                         dmq_message,
                         &dmq_message_size,
                         &dmq_message_len  ) != PAMS__SUCCESS)
  {  
    dmq_message[0] = '\0';
  }

  return dmq_message;

} /* dmq_error_text */

I'm running this on DIGITAL UNIX V4.0B
using the latest DMQ kit, dmqdev400_unixAlpha.tar, 
copied from ftp://www.dmq.rch.dec.com/dmqeng/kits/DmQ400/DIGITAL_UNIX/Alpha
on May 13 18:33

dmqmonc starts with 
                         DECmessageQ V400 Monitor


# setld -i | grep DMA
DMACL32A                        DECmessageQ Client Library
DMACL400                        DECmessageQ Client Library
DMACLS32A                       DECmessageQ Client Library Server
DMADEV32A                       DECmessageQ Development Environment
DMADEV400            installed  DECmessageQ Development Environment
DMADOC400            installed  DECmessageQ Online Documentation
DMAEXA32A                       DECmessageQ Example Programs
DMAEXA400            installed  DECmessageQ Example Programs
DMAINC400            installed  DECmessageQ Include Files
DMAMAN32A                       DECmessageQ Manual Reference Pages
DMARLS32A                       DECmessageQ Release Notes
DMARLS400            installed  DECmessageQ Release Notes
DMARTO32A                       DECmessageQ Run Time Environment
DMARTO400            installed  DECmessageQ Run Time Environment

Dirk

>  pams_create_handle (sdmhandle, NULL)
>  pams_encode_xxx (sdmhandle, args...)
>
>  flags = PSDM_ANY | PSDM_FIRST;
>  tag = PSDM_NULL_TAG;
>  
>  pams_set_msg_position (sdmhandle, &tag, &flags)
>
>  pams_decode_xxx (sdmhandle, args...)
>  pams_next_msg_field (sdmhandle, args...)

Actually, the handle is used for encoding.
Therefore the pams_set_msg_position here  is just asking to reset
encoding to beginning of SDM buffer.
Then you try to decode from a handle used for decoding, hence the
error returned.

JPG,

>>Then you try to decode from a handle used for decoding, hence the
>>error returned.

I read this as:
<<Then you try to decode from a handle used for ENcoding, hence the
<<error returned.


Remark 1:

  Where the hell did I tell the library that I need a handle for encoding only ? 
  pams_create_handle(sdmhandle,NULL) does not mention this.

Remark 2:

  This means that it is impossible (apart from unsupported dump routines)
  to "look what is already encoded". A feature like that is mandatory
  in projects where many people are working together, each making a
  differnt piece at different moment in time.  On top some pieces might
  be specified as "optional" how do you know it's there ?

Remark 3:

  have a look at the (on-line) documentation, especially the part where it 
  describes the method of coding a server.

  It states that one can use the same handle for decoding the request and
  encoding the reply.  I know this is the reverse order of what I try to do
  but I suggest to explicitly mention this.



On the other hand, we like the pams_encode/decode so much, that it seems to me
as a very usefull technique for passing messages between various components of
the same software, i.e. a caller encodes things into a handle, a callee decodes
them.  The major advantage is that the argument list becomes very dynamic. 
Usied in conjunction with .so or .dll this seems a major feature to me.

But unfortunately not supported, I guess.

I thought you are(were) a great fan of re-useable objects ;-)



Dirk

re "The major advantage is that the argument list becomes very dynamic. 
Usied in conjunction with .so or .dll this seems a major feature to me."

This is a problem we see with the handle based SDM of the MSG+ api. 
Developers use the handle based routines as a method of temporary storage 
with a simple interface, dynamic memory allocation and search facilities. 

Can BMQ Make it clear now whether this is supported or not. Problems arrise 
when the internals of these routines change due to future optimisations, 
caching etc which break applications previously dependent on nice features :-).

The use of the above also makes interpretation of runtime tracing more 
difficult with handles created and freed independently of any message put/get. 


Bob 

Bob,

I understand you concern, but I persist in putting emphasis on debugging and
testing BEFORE exposure to my beloved customer.

The handles used for encoding/decoding appear to me as belonging to a library
of reusable code that allows one to encode/decode across different hardware
platforms linear sequences of atomic quantities.  A priory, there is no
interaction with any of DMQ's transportation code necessary nor desired. I am
also entangled in multi-threading and I can tell you that pams_get_msgw and
pams_encode_int32 run into each other's territory if not protected by a mutex at
the application level. JPG has the proof of this.


DMQ itself can be considered as a re-user of the handle-based messages, since it
has built-in support for the handles.

In other words, to relief me from the burden of xxx_extract_buffer the DMQ
api is very nice to me and offers me the to do it on my behalf. 

A major feature THAT IS IMPOSSIBLE TO IMPLEMENT AT THE APPLICATION LEVEL, is
that the handle and it's dependent structures can be used for OPTIMIZATION of
the physical transport and other expensive (memory) resources. 

It shall be totally transparent to a pams_put / pams_get pair using handles
whether or not an xxx_extract/insert_buffer is performed internally in DMQ as
opposed to sending each encoded element ,or a reasonable group, as a single
-internal to DMQ- message.  Doing it the latter way releases a lot of pressure
on shared memory and other expensive resources, and allows for partial resend on
non-reliable transports. But it is pricy in overhead.  That is why I need 
experienced engineers to think it over for me and implement a really usefull
thing.

But I stick (religiously :-) to my point of view. Encoding/decoding is a
re-usable piece of software in it's own right.


Dirk

Dirk, i'm all for keeping the encode/decode seperate from DMQ internals, indeed
that is a must if they are to port the SDM api to MQ series client to get the
full benefit of the DMQ<->MQ gateway. 

All I am saying is make sure DMQ engineering agree to support the use of handles
and encode/decode as temp storage. 

otherwise you get the NOT supported response when something breaks after an
upgrade.

Bob ( a handle in the hand is worth 2 pointers in the bush :-))

The Self-Describing Message support comes in two flavours :
  o bundled with PAMS API
  o standalone (to be used over other transports such as ObjectBroker, files,
    sockets, or - as you point out - memory)

When bundled with MessageQ, the message handles are directional to protect users
from decoding by mistake a message used for encoding.

However, you can still use it that way with the PAMS API by using extract/insert
functions as follows to preserve message direction :

  1/ create an outgoing message handle
  2/ encode as per your needs
  3/ extract the buffer (pams_extract_buffer)
  4/ create an incoming request
  5/ insert the buffer (pams_insert_buffer with a length argument valued to 
     zero to indicate a SDM buffer - note : address of zero not a NULL pointer)
  6/ decode as per your needs

If you need to use the standalone SDM library, please contact Glen Macko,
MessageQ Product Manager.

JF,

from the OFFICIAL kit, as compared to the field test we wre using before,
there is a vicious deltat in the header file p_entry.h.


Field test kit                      OFFICIAL kit

#define PAMS_MSG_HANDLE 1
#define PAMS_IS_A_HANDLE -1


In other words, 2 lines are missing.

Thanks to BEA for my lost re-compilation effort.

Dirk

>from the OFFICIAL kit, as compared to the field test we wre using before,
>there is a vicious deltat in the header file p_entry.h.


>Field test kit                      OFFICIAL kit

>#define PAMS_MSG_HANDLE 1
>#define PAMS_IS_A_HANDLE -1


>In other words, 2 lines are missing.

>Thanks to BEA for my lost re-compilation effort.


	  First of all, anything and everything is open to change before the
	final release of a kit.  The offical kit has this in it:

/************************************************************************** */
/*     Define symbols for large and handled message                         */
/************************************************************************** */
/*                                                                          */
#define PSYM_MSG_HANDLE -1
#define PSYM_MSG_LARGE -2

	These symbols properly reflect how the code is supposed to behave.
	From your response it looks to be an attempt to mix code compiled
	against the FT includes and linked against the final kit.  Only
	symbols that existed with the previous released kit can be considered
	valid.  In other words, you should have rebuilt your code under
	the new enviroment to protect against this sort of problem and not
	blame us for it.



	Marty

Marty,


PAMS_MSG_HANDLE is (was :-) used in a way equivalent to

  pams_create_handle (handle, &PAMS_MSG_HANDLE)



PSYM_MSG_HANDLE is (IS :-) used in a way equivalent to


  pams_put_msg   (	   rqe_p->Msg, 		/* char buffer */
			   rqe_p->Priority,	/* priority */
			   rqe_p->Target_q,	/* target queue */
			   rqe_p->Class, 	/* class */
			   rqe_p->Type,		/* type */
			   rqe_p->Delivery,	/* delivery byte */

			   &PSYM_MSG_HANDLE,	/* output length */

			   rqe_p->Timeout,	/* timeout */
			   rqe_p->Psb,		/* PSB structure */
			   rqe_p->Uma,		/* UMA */
			   rqe_p->Response_q,	/* response queue */
			   rqe_p->Large_Size,	/* must be NULL in V3.2 */
			   rqe_p->reserved_2,  	/* must be NULL */
			   rqe_p->reserved_3 )


In other words, the symbols have NOTHING in common; definitely not their meaning.

I don't care about value changes of #define'ed symbols, AS LONG AS THE CHANGE
DOES NOT BREAK RECOMPILATION.  Omitting a symbol usually breaks compilation.



Dirk

P.S. <cynics on>  Is it because the encode/decode was done in Europe that 
     American teams don't like it ? I heard about some animosity, and there
     one can read between lines of a previous reply. 
     <cynics off>

PAMS_MSG_HANDLE existed in the field test but was removed as it was
duplicated with PSYM_MSG_HANDLE which is the only valid symbol. As 
Marty pointed out, this is the down side of field tests as things may
change.

This symbol can be used in 2 different routines (namely pams_create_handle
and pams_put_msg). This is well documented. The fact your compilation failed
is a consequence of the merging of the symbols as explained before.

If you use the right symbols all should work just fine. If not, please
make sure you did not mix header files and/or objects of both kits.

Yep,

it seems to all boil down to "field test risk".


Thans a lot for the explanations to JPG & co.


Dirk