| Author |
Message
|
| mqjeff |
 Posted: Wed Dec 31, 2014 5:38 am Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Tim -
As someone who has spent a lot of time maintaining programs that need to translate between MQSC and PCF...
Yes, the manuals have some flaws.
The doc team is rather overloaded in a lot of cases, and they do have to wait for input from the development team.
But please do make effort to submit feedback to the KC. I know it's a PITA, especially sometimes. But it might make it less frustrating if you make an ongoing list of bugs and their corrections... and then submit one larger feedback rather than trying to submit many small ones.
 |
|
| Back to top |
|
 |
| tczielke |
| Posted: Wed Dec 31, 2014 6:08 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Hi Jeff,
So I gave this another try. With Internet Explorer, the Feedback link for a given page in the KC just says "Error on page" when I click it. For Firefox, I don't even see the Feedback link for the given page. There is a generic feedback option at the very bottom of the browser that looks new and does seem to be working, although it is very generic. I will give that a try next time. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Dec 31, 2014 6:40 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
When I clicked "feedback" link, the pop up window had a drop down list "Please choose a topic" with topics "current page" and "Overall KC".
Clunky but I guess this is the equivalent of what we had.
BTW, I was using FireFox. |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Jan 05, 2015 2:33 am Post subject: Re: MQ Expiry Value - How is this possible? |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| PeterPotkay wrote: |
| mvic wrote: |
| Ask your app people? |
No matter what they say or show me, the question remains. The manuals say 999999999 is the max value. |
What if the manuals are wrong. What if the code is wrong. How can a user tell the difference.... anyway the value is nonsense and it's probably nonsense because your app set it to be nonsense. Did you check with your app people? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jan 05, 2015 5:54 am Post subject: Re: MQ Expiry Value - How is this possible? |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
The below is the top snippet of the message from MO71. MQ Explorer and BMTM also confirm this value.
| Code: |
[ 364 bytes] Message Descriptor (MQMD)
StrucId :'MD '
Version :2
Report :00000000
Message Type :8 (Datagram)
Expiry :2146624636
Feedback :0 (None)
MQEncoding :0x'222'
CCSID :819
Format :'MQSTR '
Priority :0
Persistence :1 (Persistent) |
The value is decrementing.
This app is producing lots of messages like this.
WMB and DataPower are forwarding it along, maintaining that value!
How is this possible? |
What can you tell us about the app that is producing this? Is it a C app? COBOL? From what mq version? Do these messages originate from the broker?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 05, 2015 6:24 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
Hex value for 2146624636 is 7FF2 E47C.
Looks like this might have started as a max positive value of a signed DWORD : 7FFF FFFF.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jan 05, 2015 6:04 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The messages are coming from a business partner so I don't have access to the code. I suspect Tim and FJ are correct, though.
I have a PMR open. An APAR is coming. I will share the # when I have it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jan 06, 2015 6:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
I wonder if this is just a programming error...
Somebody thinking to put the max value, thinking it will be FFFF FFFF i.e. -1 or no expiry when in fact putting 7FFF FFFF...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Feb 14, 2015 6:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| tczielke |
| Posted: Sat Feb 14, 2015 7:22 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
My two cents, this seems like too disruptive of an approach for IBM to take to address this discrepancy. I would of thought it would have made more sense to just update the manual to replace 999,999,999 with 2,147,483,647. If there are any applications out there that are using a value greater than 999,999,999 for the Expiry on the PUT, they will now fail when this future maintenance is applied. It is much easier to make a documentation update, then require customers to change their code or set environment variables in queue managers. Unless you are 100% sure that you have no apps using an expiry > 999,999,999, this approach is backing you into running with an environment variable for your queue manager (which can be an administrative burden, especially if you are not currently using any environment variables).
Lastly, it is just not good to make a change to MQ that has the potential to break applications when MQ maintenance is applied. Having previously working business applications break when MQ maintenance is applied causes the business application groups to view MQ in a more negative light.
Maybe I am missing something else here that required IBM to take this approach. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Feb 14, 2015 9:59 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Software is written to conform to the specifications in the official documentation, not the other around.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Feb 14, 2015 10:21 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
| bruce2359 wrote: |
| Software is written to conform to the specifications in the official documentation, not the other around. |
Vendor software yes... Customer software or the cloud development stuff IoT is written any .... way the developer was able to make it work...
If the definition of the variable was MQsomething equivalent to DWORD (C ), guess what, those are the max values he is going to apply!!!.
Especially if using Cobol where it is easy to set max and min in hex...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Feb 14, 2015 10:59 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| fjb_saper wrote: |
| Vendor software yes... Customer software or the cloud development stuff IoT is written any .... way the developer was able to make it work... |
Customer-written software is supposed to conform to the official documentation, too. Developers, the professional ones, will read, understand, and adhere to the official documentation.
IBM COBOL specification doc has forever stated that after a file (DDNAME) is closed, the last record read from the dataset is no longer available to the app. Early COBOL releases did not enforce this, so many coders relied (incorrectly) on having the last logical record available. Once IBM fixed this bug, developers complained loudly and often '...but, it used to work!'
I suspect that there are other similar anomalies awaiting developers and administrators. Just because you can do something, doesn't mean that you should.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| tczielke |
| Posted: Sat Feb 14, 2015 11:34 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| I looked at that APAR more closely, and it only applies to 7.5 and 8.0. So it looks like this behavior of allowing an Expiry over 999,999,999 was introduced at 7.5. This makes more sense then why IBM is taking this approach. I was thinking this was more of a historical behavior with Expiry that they were correcting, not something that just got recently added in. However, this still is going to be messy for their customers at 7.5 and higher that might have exploited this behavior. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Feb 15, 2015 6:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| tczielke wrote: |
| However, this still is going to be messy for their customers at 7.5 and higher that might have exploited this behavior. |
Exploiting a bug or undocumented behavior is most definitely not a best-practice.
Depending on ongoing support for such an exploit by IBM, another vendor, or your auditors or management is naive.
"Exploiting" in such a case, is more accurately "getting away with" writing bad code.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
