When you are building messaging systems that go against "legacy" back-ends, there are some special problems that you have to deal with. The biggest of them (IMHO) is that these legacy systems often have arbitrary limits on the amount of data that can be sent at one time. For instance, each CICS COMMAREA is limited to 32K. In most CICS programs, that means that a single transaction request (to, for instance, fetch back some rows from a Database) may result in multiple COMMAREAs being needed to return the values.

So there are a group of patterns here (I'm open to suggestions) about how to best do this sort of "data reassembly". Some potential topics include:

1. ordering (who generates the messages, what's in the first one, where is the size placed? For instance, two versions of this I've seen are (a) The first message contains a total "length" that tells how many messages will arrive, or (b) each message has a "more messages" flag that indicates if more will follow)

2. tolerance of duplicates

3. guaranteed delivery (does the messaging infrastructure guarantee this or not)

4. splitting/merging/grouping

So -- what are your experiences, good bad or ugly?

-- KyleBrown

----
As used in multiplexing : See MuxAdapter .