RE: *DTAQ exit program not called -- MIDRANGE-L

Simon,

You're right, the QIBM_QZHQ_DATA_QUEUE exit point monitors
only the client Access Data Queue Server.  This server is
listening for Client Access type data queue entries that are
sent from some remote system to your iSeries.  

In your case, you're using the QSNDDTAQ API on the /400 to
communicate with another process on the /400.  This means
that you have to write the server (that NEP job that you're
trying to avoid) rather than re-use the IBM CA server.  The
QSNDDTAQ API's do not use the QIBM_QZHQ_DATA_QUEUE Exit
point to communicate through.  Sorry :(

Incidentally, once you write your own server, you could hook
an exit program to it, but it sounds as if you'd be better
off putting all of your functionality in your own server
program anyway.

HTH,


jte



--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for
the use of the intended recipients and may contain
information that is privileged and confidential. If you are
not the intended recipient, any dissemination, distribution,
or copying is strictly prohibited. If you received this
email message in error, please immediately notify the sender
by replying to this email message, or by telephone, and
delete the message from your email system.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of Simon Perez
> Sent: Friday, October 31, 2003 11:10 AM
> To: MIDRANGE-L@xxxxxxxxxxxx
> Subject: *DTAQ exit program not called
> 
> 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.
> _______________________________________________
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.