× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi,

I'm having a problem using the QIBM_QZHQ_DATA_QUEUE exit point in
conjunction with the QSNDDTAQ API.

Here is the picture: I've created a data queue that is attached to an alert
filter. This alert filter in particular looks for any UPS CPF's sent in the
QSYSOPR outq and writes a ZHQ00100 data format to the data queue once its
triggered. This part works just fine. I've created a small CL pgm that sends
the CPF to the outq (in order to trigger the exit point pgm) and then reads
the dtaq using the QRCVDTAQ API (for confirmation purposes). This confirms
that the triggered alert writes to the dtaq. I would expect that this output
to the dtaq would then trigger the exit program that I've defined for the
QIBM_QZHQ_DATA_QUEUE exit point but it doesn't. Using a CL program (using
QSNDDTAQ API) to simulate the effects of the send to dtaq yields the same
effect. I was therefore assuming that there had to be a problem with the
exit program or a bug with the exit point somehow.

I found out I was wrong on both accounts. Since the QIBM_QZHQ_DATA_QUEUE
exit point is in fact a Client Access server (SBSJOB QSYSWRK/QZHQSRVD). I
thus decided to simulate the the effects of the send to dtaq using a java
program instead. To my surprise, everything worked just fine!

After some research, I can only draw one conclusion to the reasons for this
problem: Somehow, Its like the alert filter and the QSNDDTAQ API seem to
bypass the QZHQSRVD daemon when writing to the dtaq while Java goes through
the daemon thus triggering the exit point (SNA v.s. TCP?). Could someone
please correct me if I'm wrong, am I missing something here?

I'm trying to avoid using obvious solutions as creating a program that
constantly monitors the dtaq.

I've since tried to see if there is a way to trick the daemon by using a
*DDM dtaq remotely attached to a local *STD dtaq (loopbak). This way, I'm
hoping to force the write to the dtaq through the daemon in order to trigger
the exit point. It looks like sci-fi and I doubt there is any way of
achieving results this way (APPC) but its all I can come up with in respect
to the way I'm trying to achieve this (Real time event monitoring using
alerts and exit points). I understand there might also be a way to do this
using an SNMP solution in conjunction with the QIBM_QZCA_SNMPTRAP exit
point.

Any suggestion?

Thanks!

____________________________________________________________
Le Groupe Option Retraite Inc. n'assume aucune responsabilité quant
à la confidentialité et l'intégrité du présent courriel en raison
des risques d'interception inhérents sur l'Internet. Pour cette raison,
toute opinion exprimée au terme des présentes, ne reflète pas nécessairement
celle du Groupe Option Retraite Inc.

Due to the security risks involved in sending information over the Internet,
Retirement Option Group Inc. cannot be held responsible for ensuring the 
confidentiality and integrity of the present e-mail. For this reason, the 
opinion expressed 
herein, do not necessarily reflect those of Retirement Option Group Inc.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.