|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
