Ok, pursuing Scott's suggestion helped me find the problem. He recommended
I post full code of the program in question so others could test the issue
as well. In preparing to do that I found my problem. It was not in my
program that was creating data queue entries. It was in my use of JCRDQE as
a tool to review the data queue contents. There is apparently a limit to
the data queue size JCRDQE can handle. It would not show values beyond a
certain position in the entry and displayed blanks. I wrote a new program
to retrieve entries from the data queue (to show Scott) and placed it in
debug to review the entries retrieved. It was retrieving entries properly
and the contents were intact. Using the 'eval DataQueueData:c 4296' command
in debug allowed me to see the full contents.
I'll have to review the JCRDQE source to see what may be the problem.
Thanks for your suggestions, and offers of help.
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Thomas Garvey
Sent: Tuesday, September 08, 2009 8:26 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Problem with QSNDDTAQ
You're right, they're not the real d-specs (I copied them from procedural
parameters that have been commented out when I changed the program to call
QSNDDTAQ directly with a call rather than a procedure call with EXTPGM
I'll try to do what you suggest but I can't just send the original code
itself. Populating the data for the data queue entry is just lines and lines
of cryptic code, inside of a trigger.
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, September 08, 2009 7:20 PM
To: Midrange Systems Technical Discussion
Subject: Re: Problem with QSNDDTAQ
It would help an awful lot if you provided actual code that we can load and
run to try it for you. Something simple, since we don't want to spend hours
or days setting up an environment.
When you post snippets, the best we can do is TRY to see some flaw in them,
since we can't actually compile or run the code. And we have to mentally
fill in all of the details you've left out, or ask for more information
(which takes both more of my time, and more of your time waiting for a
In this case, I looked at your D-specs, and immediately said "these
aren't his real D-specs". How do I know that? because they're not
legal syntax. They say "CONST" on them, which isn't allowed for a
standalone def in RPG.
Furthermore, we don't know what values are in these fields at the time the
CALL is run, so we have to guess.
Can you please post a short/simple program that demonstrates the problem?
Thomas Garvey wrote:
Sorry, I left out the defs for the parameters...
d QueueName s 10a const
d QueueLibrary s 10a const
d DataQueueData s 4296a const
Data block for DTAQ
d DataQueueLen s 5p 0 const
Data block for DTAQ
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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l