API - how to handle unknown receiver variable size

[bvining@xxxxxxxxxxxx]

Dave,

Sorry it has taken me a day to get back, but some job responsibilities
came up.  Anyway...

The "easy but perhaps not so user friendly" approach would be to first
call the Retrieve Data Queue Description (QMHQRDQD) API and find out what
the maximum message length and current number of messages was for the
*DTAQ.  I would then calculate a reasonable size for a Receiver Variable
(((NbrMsgsOnDQ * (MaxMsgSiz + 12)) + 54) * 1.05) where

   NbrMsgsOnDQ is the current number of messages on the *DTAQ
   MaxMsgSiz   is the maximum size of messages allowed on the *DTAQ
   12          is the overhead per message (offset, date/time)
   54          is the overhead per Receiver variable (RDQM0100)
   1.05        is an arbitrary fudge factor for growth and/or new
               messages being received before QMHRDQM gets control

and then create a User Space by that size (or alternatively ALLOC the
storage).  When prototyping QMHRDQM I would not define the Receiver
variable as a varying character field, but rather as a Pointer passed
by value (though this is a matter of style).  I could then pass a
pointer to the User Space (obtained with the Retrieve Pointer to User
Space (QUSPTRUS) API) or the pointer returned by ALLOC.

When QMHRDQM returned I would then used a Based structure (for the
repeating fields) to process the various messages returned using the
Offsets provided in the "receiver variable".  Examples of this can be
found in the System API Programming (not the Reference) manual.

Now the above approach does have a drawback from an end-user
perspective; and that is that if the *DTAQ has say 10000 messages it
may be quite a while before they see the first subfile page as QMHRDQM
is going to have to process all the entries (there is no restart
capability with non-keyed *DTAQs).  If we wanted a "more difficult
but also more user friendly" approach then one idea would be to only
process (in the above manner) the first N messages where N is the number
of messages that can be displayed in the first (say) 5 subfile pages.
In that case we substitute (5 * PageSize) for NbrMsgsOnDQ AND submit
a second job which will also call QMHRDQM but will ask for all messages.
This second job (using the above approach) would then asynchronously
write the messages to a pre-agreed named User Space which can be read by
the interactive, subfile controlling, program.  This way the user can
get reasonable response time and all the messages.

Some synchronization considerations may apply as messages could be
removed from the *DTAQ such that the interactive program "saw" it but
the batch program didn't so trying to perfectly flow from page 5 to
6 may require some scanning of the User Space, but with the Message
enqueue date and time element that shouldn't be too difficult (it's a
unique value).

The use of Keyed queues would allow some amount of additional flexibility
in approach as a limited restart capability does exist.  But I hope this
is of some assistance for your non-Keyed environment.

Bruce

>
>Bruce,
>I'm looking for a generalized approach for any old *DTAQ.  I'm developing
>in
>RPG IV and my *DTAQ in this case is non-keyed.  I'm looking to minimize
>development time where possible.  Most specifically, I'm not sure how to
>code
>the receiver variable using format RQDM0100 of the QMHRDQM API.
>The last few fields in RDQM0100 are repeated for each message retrieved.
>Do I define the receiver variable as VARYING?  What's the most efficient
>way (by the above definition) to get the text of each message?
>
>  want to build a subfile displaying the *DTAQ's contents before that data
>is processed.
>
>TIA,
>Dave
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---