Trigger Program on Data Queue

4805 pts.
Tags:
AS/400
Data Queue
Hello All, I have a requirement where Program needs to be triggered whenever data is pushed into Data Queue. Without having a batch job checking for Data or running with delay job.
Your inputs would be appreciated.
Thanks,
Pradeep.


Software/Hardware used:
V7R1

Answer Wiki

Thanks. We'll let you know when a new response is added.

Mr bvining  , That was a life saver. I knew about waittime on QRcvDtaQ but didnt see this from CPU% point of  view. Thanks a lot.

The Receive Data Queue (QRCVDTAQ) API can be used such that there is no need for checking/polling or DLYJOB looking for data being pushed on to the *DTAQ. Just specify a Wait time (the 5th parameter when calling the API) of -1.

Discuss This Question: 12  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TheRealRaven
    Without a job that is "checking for Data", there will be no checking. Can you explain why you can't have a job that does it?
    21,845 pointsBadges:
    report
  • bvining
    The Receive Data Queue (QRCVDTAQ) API can be used such that there is no need for checking/polling or DLYJOB looking for data being pushed on to the *DTAQ. Just specify a Wait time (the 5th parameter when calling the API) of -1. This tells the system to essentially put your program to sleep and to wake you up just as soon as data becomes available. You process the data and just call the API again using a Wait time of -1. Your program will do nothing until another message becomes available for processing.

    Bruce
    7,070 pointsBadges:
    report
  • TheRealRaven
    The API would be used, but isn't it difficult without a job to run it in? That is, it's hard to tell whether the problem is about needing a job or in thinking that some kind of delay-loop is required that constantly reacts to a 'no data' condition.
    21,845 pointsBadges:
    report
  • bvining
    I interpreted the question as not wanting some job constantly running and checking the *DTAQ. Using the API, as you point out, does mean a job exist on the system, but the job will only run when triggered by the system detecting a message being placed on the queue.
    7,070 pointsBadges:
    report
  • deepu9321
    Hello All,

    Thanks for your reply.

    Yes bvining, There isn't any technical challenge to have a job checking with delay -1 through API. 

    But, Our customer doesnt want to have a Job being on the system for whole day. Instead they want to trigger a job whenever data is pushed into DTAQ. 

    Thanks,
    Pradeep.
    4,805 pointsBadges:
    report
  • TheRealRaven
    If this is a "remote" *DTAQ function, the Data queue server exit point/program might be useful. Otherwise, I don't think there's much choice; nor can I think of a good reason not to have a job monitoring the *DTAQ.
    21,845 pointsBadges:
    report
  • pdraebel
    I thought Data Queues were meant to facilitate communications between two jobs. What use does it have to force a new job structure every time a "request" comes in the data queue ? Not having a job of some kind to "Monitor" the data queue seems contradictory to me as to the purpose of Data Queues.
    7,455 pointsBadges:
    report
  • deepu9321
    That's true pdraebel.

    I have got to know that we can have Triggering Options with Websphere MQ (We do use this in current application). 

    We have proposed to have Job to monitor Data Queue as first preference and MQ as second. Yet to get confirmation from out customer. 

    Thanks a lot for your response. 

    Pradeep.
    4,805 pointsBadges:
    report
  • azohawk

    I thought for MQ to operate, there were jobs running or the dataque just fills up with no processing. Since the requirement is "Our customer doesnt want to have a Job being on the system for whole day", not sure MQ would meet the requirement.

    My current employer does not use MQ; but, my previous employer did. One of the things I recall doing every day was making sure the MQ jobs were started. If data was not flowing, restarting MQ and see all of the jobs start. Perhaps there are options we never explored or came out on versions after we implimented MQ (If is not broke, don't fix it); but, based on my experience with MQ and the requirement stated above, I'm not sure MQ will meet the requirements.

    At my current employment, we have data being put into data queues, but we have jobs monitor them 24x7 (less backup windows).

    2,565 pointsBadges:
    report
  • ToddN2000
    How is the DATAQ being processed currently? It seems like your program was designed to work one way but you now want to handle the processing another way. Triggers are designed to work with files to launch a program. DATAQ's sit as an async waiting for more data.
    82,315 pointsBadges:
    report
  • azohawk
    One thing that I have done is to create a program that performs a sbmjob with a specified paramater for the time to be submitted, but never with a dataq. The difficult thinkg I would think with this approach is how much time do you add between to the next submit. 
    2,565 pointsBadges:
    report
  • GregManzo
    First I'd question why you can't have a "Monitor" job reading entries from the *DTAQ. It won't be using any CPU while it's waiting, and IBM already has dozens of jobs in the system "all day" (check WRKACTJOB and discount the jobs you know are users signed on or transient batch jobs - chances are what's left are all IBM)

    Second: I'd have said monitor job wake up every couple of minutes to check for a controlled shutdown. It only takes a couple of microseconds each time, but it means you know the job will end itself cleanly. You should NEVER have a job that requires someone else to kill it to end. We have an entire subsystem dedicated to about 30 of these monitor jobs, day-end issues an ENDSBS *CNTRLD knowing that they will all be gone in 2 minutes or less. A STRSBS brings them all back up again.

    Third: If you really can't have a monitor job, you replace the *DTAQ with a write to a file and put an after trigger (ADDPFTRG) on the file to do whatever processing you need. The downside here is that the processing will be done within the job that issued the write - potential for locking issues or slow user response times.

    Fourth: You could just issue a SBMJOB, but the overhead in QSYSARBn here is more significant than the *DTAQ approach.
    1,635 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: