Hi Thomas,
For (a) I'd point out that hexadecimal values are reasonably familiar to a
fair number of programmers on this list and so entering packed decimals
aren't totally strange, but maybe just a simple editor that takes either
Hex or Char and the data formatting is up to the user?
I thought (b) might be too much. As you are passively reading the data
queue with the QMHRDQM API, you are not affecting the data that could be
processed by another program at any time and it would be a shame to risk
data damage by trying to be too clever.
After several weeks of playing with the data queue monitor, I have only
just found a bug! There is an option to display any data queue entry (as
both hex and char) but it *only* ever displays the first 100 characters
(bytes?) of the entry. There is an option to change how much of the data is
displayed, but this appears to have no effect on the display of data queues
longer than 100 chars. (I was using one of 1024 chars in length.)
Thanks for your continuing hard work!
-Paul.
On 20/09/2016 12:44, Thomas Raddatz wrote:
Hi Paul,
The data queue monitor uses the QMHRDQM API to read the messages of a
given data queue. Since the QMHRDQM API does not remove messages from
the queue, reposting of messages is not required.
Honestly I already thought about posting and deleting messages. Here
are my concerns about that:
a) I think that we can safely assume that people usually use data
structures to build the message data. So what shall we do when the
message data is composed of binary or packed values?
b) Removing messages from a data queue is not easy. As you already
pointed out, iSphere had to receive and repost the messages, ignoring
the messages to be removed. Can you think of a save way to do that?
Actually the plug-in cannot do that, because of network problem that
may happen all the time. Most likely iSphere had to use commands to
dump the queue to a physical file and to repost the messages from the
file. Both commands had to be called from a CL program on the IBM i
server. Just reading and reposting the messages one by one is not save
enough because of possible network problems. Another option could be
to create an empty "staging" queue (save/restore and QCLRDTAQ,
problem: produce temporary name), then populate that queue with the
remaining messages and eventually rename that queue to the original
name. Another problem is that the messages that are removed could only
be identified by their index number, when the whole thing runs on the
IBM I server. Last but not least there had to be an exclusive lock on
the queue from the point when the user selects the messages to the end
of the job.
Everybody: What are your ideas for solving the problem?
Regards,
Thomas.
-----Ursprüngliche Nachricht-----
Von: WDSCI-L [mailto:wdsci-l-bounces@xxxxxxxxxxxx
<wdsci-l-bounces@xxxxxxxxxxxx>] Im Auftrag von Paul Bailey
Gesendet: Dienstag, 20. September 2016 12:32
An: Rational Developer for IBM i / Websphere Development Studio Client
for System i & iSeries
Betreff: [WDSCI-L] iSphere data queue monitor
Hi Thomas/Frank,
I've been playing with the data queue monitor recently and I like it.
I have a question, and a possible enhancement request.
Is the monitor displaying the data in the data queue passively, or is
it reading and reposting the data queue items?
Can we have a feature to enable posting and deleting items from a data
queue? The posting part should be fine, using the QSNDDTAQ api, but
removing an item might require removing all and reposting the ones
still required.
What do you think?
-Paul.
--
This is the Rational Developer for IBM i / Websphere Development
Studio Client for System i & iSeries (WDSCI-L) mailing list To post a
message email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit:
http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/wdsci-l.
--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a
criminal offence. Please delete if obtained in error and email
confirmation to the sender.
midrange.com
