RE: Strange DTAQ problem

Sometimes, we have found, data queues are resolved by an OLD address (in the
single-level store) that gets stored for a user profile and job.  This
happens when the OS does not resolve the dtaq name fresh upon the QRCVDTAQ,
and can be pointing to a queue that has the same name, but - for instance -
may NOW be in a renamed library.  

We have seen this especially where one user profile changes the queue (maybe
renames the lib it is in) and creates a new one, and another user profile
continues to try to access data and cannot.  This second user is pointing to
the address of the queue in the renamed library and will get no data, even
though the CALL is to the proper queue/lib.  Once the rename lib queue is
deleted, (or some other magic, like signing off and on) the API will resolve
the name and find the NEW address of the real queue, and read the data.

I suspect there may have been some actions on the queue immediately before
this and then others to change it and let the program "see" the proper
one...

Ira Chandler
http://curbstone.com
770-737-3045 & 888-844-8533
770-737-3046 Fax
* AS/400 Credit Card Software
* RPG Rapid Web Development
* Native Sockets Middleware





-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Krish Thirumalai
Sent: Friday, September 23, 2005 11:10
To: Midrange Systems Technical Discussion
Subject: Strange DTAQ problem


A couple of days ago, we experienced a strange issue with a Data queue
that we use for FedEx processing.

We were attempting to retrieve information from the data queue with a
Key.  We checked and the data did exist in the data queue with that
key using a tool that uses the QMHRDQM API, but the QRCVDTAQ command
was not finding the data.   After about an hour of this problem
occurring, it started to work, and then worked perfectly after that. 
Just trying to understand why it wouldn't have worked during that
first hour.

--
Krish Thirumalai