|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.