Re: api QRCVDTAQ not removing entries from dtaq?

Yes, the queue is keyed.

Also, DSPDTAQ is part of TAATOOLS.


On 3/22/07, Roger Harman <RHarman@xxxxxxxxxx> wrote:

Is the queue keyed?  If not, it probably should be.

>>> burns.gene@xxxxxxxxx 03/22/2007 1:35:30 PM >>>
Thanks Rob,

The test you suggested pointed me in the right direction.  The problem
was
in the receiving of the data from the queue.  I have a requirement to
retrieve the data in descending date sequence.  So, I took the current
date
and decremented it 1 day for each step through the For loop for 60 days.
However, I did NOT make sure that I had received all the data for that
date
before going to the next date.  So a lot of data was backing up in the
queue
and when the programs that load the queue were run again, duplicate
data.
All I needed was a Do loop inside the For loop.  Sometimes I make such
stupid mistakes!  I guess that's what happens when you try to be to
clever
with a solution.

Thanks for you help Rob.

Gene

On 3/22/07, rob@xxxxxxxxx <rob@xxxxxxxxx> wrote:
>
> If DSPDTAQ says there are multiples then there probably are and then
the
> issue is with your loading of the data queue.  Although that seems to
be a
> custom command.
>
> Good question at the end.  Write two quick and dirties.  First one
loads
> three entries into the queue.  Could be as simple as 'A', 'B', 'C'.
Second
> program reads the queue and does a DSPLY of the contents.  Then at the
end
> do another DSPDTAQ.
>
> CRTDTAQ DTAQ(QTEMP/BLARNEY) MAXLEN(1)
> CALL PGM(QSNDDTAQ) PARM('BLARNEY   ' 'QTEMP     ' X'00001F' 'A')
> CALL PGM(QSNDDTAQ) PARM('BLARNEY   ' 'QTEMP     ' X'00001F' 'B')
> CALL PGM(QSNDDTAQ) PARM('BLARNEY   ' 'QTEMP     ' X'00001F' 'C')
> DMPOBJ OBJ(QTEMP/BLARNEY) OBJTYPE(*DTAQ)
>
>
> Rob Berendt
> --
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> "Gene Burns" <burns.gene@xxxxxxxxx>
> Sent by: rpg400-l-bounces@xxxxxxxxxxxx
> 03/22/2007 03:48 PM
> Please respond to
> RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
>
>
> To
> "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
> cc
>
> Fax to
>
> Subject
> Re: api QRCVDTAQ not removing entries from dtaq?
>
>
>
>
>
>
> Because DSPDTAQ shows the data still in the queue and I am getting
some of
> the same data received into the program using the QRCVDTAQ api
multiple
> times.  Perhaps the problem actually resides in the loading of the
data
> queue? (he asks hopefully)
>
> Gene
>
> On 3/22/07, rob@xxxxxxxxx <rob@xxxxxxxxx> wrote:
> >
> > What makes you think the data is still in the queue?
> >
> > Rob Berendt
> > --
> > Group Dekko Services, LLC
> > Dept 01.073
> > PO Box 2000
> > Dock 108
> > 6928N 400E
> > Kendallville, IN 46755
> > http://www.dekko.com
> >
> >
> >
> >
> >
> > "Gene Burns" <burns.gene@xxxxxxxxx>
> > Sent by: rpg400-l-bounces@xxxxxxxxxxxx
> > 03/22/2007 03:05 PM
> > Please respond to
> > RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
> >
> >
> > To
> > "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
> > cc
> >
> > Fax to
> >
> > Subject
> > api QRCVDTAQ not removing entries from dtaq?
> >
> >
> >
> >
> >
> >
> > I was under the impression, based on the IBM information, that when
the
> > api
> > received the data that it was gone out of the dtaq.
> > We are using several data queues in a particular application (one
per
> > user),
> > to separate data based on the user it should go to.
> > However, after the user gets the data and it is loaded into a
subfile,
> the
> > data is still in the queue!
> > I am not using the optional 11th, 12th, or 13th parms and according
to
> the
> > online api data from IBM the 11th parm defaults to *YES, remove the
> data.
> > Has anyone else seen this happen?
> >
> > Gene
> > --
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.