| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| How to convert messages with a blank message format |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Sat Nov 25, 2006 9:38 am Post subject: |
 |
|
Guest
|
Hello, zpat.
"...I won't need to spend my time flying around Europe..." Wow! You get to fly around Europe to fix things?? I envy you. Traveling around Europe sounds like a wonderful benefit.
"...IBM manuals don't make a point of recommending..." True; but the expectation is that programmers understand the data they are working with, and how MQ moves messages. String may make sense if all the data fields (name, address, phone,...) are just plain string data; but not all data qualifies.
Most MQ applications I've seen have merely replaced an intermediary file (disk or tape) with an MQ message with mixed data types, and data fields are not just string. Some other issues that string doesn't address: Intel stores numbers backwards, packed-decimal, floating-point, signed numeric data fields.
Application architects (analysts) usually decide what data fields and records look like. Few programmers get to decide.
"...but they only tested on Windows ... on local queues..." Apparently, the programmers didn't understand the 'put global; get local' rule. Or test adequately. Didn't test on different platforms across a network. Maybe your organization bought the wrong application package; or didn't write good specifications. I've worked in all these environments.
I've worked with most of IBM's products. MQ comes from the factory with pretty darn good as-built (not "default") settings. They seem to make sense for most uses. The MQ documentation is perhaps IBM's best to-date.
"Most people assume ..." Good analysis means understanding the problem, the tools available to fix the problem, and how to correctly use the tools selected. Failing any one (or more) of these dooms the project to failure.
One of the advantages of being a consultant (rather than an employee) is that consultants don't "own" the project. A good, professional consultant keeps a safe emotional distance from the project. If the project owners make lots of bad choices, the consultant doesn't have to live with them in the long-run (for raises, promotions).
I spent many years as an employee, and recognize what you are going through. I do sympathize. You have correctly identified the root cause of the problem: untrained, unskilled, unprofessional programmers. But, you've expressed your frustration by pointing at MQ.
If I may offer a small bit of hard-earned wisdom: even though your title is sysadmin, you are a consultant to your organization. A good professional consultant will analyze, report, and recommend. Management decides.
Recommend means suggesting best practices. Don't point fingers at programmers or vendors or manuals or users. Without emotion, state the facts, offer your best professional business recommendation. Then, if your organization makes a poor choice (like having you change the initial values), then your choice becomes: do it, don't do it. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sat Nov 25, 2006 10:54 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You mean to say he has 3 choices
- Initiate change
- Comply with whatever is decided
- Take the road less travelled
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Sat Nov 25, 2006 11:21 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It's really simple; Me = customer, IBM = vendor.
This debate has gone on long enough, time to get back to working on my OS/2 rollout..... (only joking - sadly!). |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 25, 2006 12:39 pm Post subject: |
|
|
Guest
|
[quote="zpat"]It's really simple; Me = customer, IBM = vendor.
Hmmm. So, I guess you believe IBM should change its software to accomodate your untrained programmers... What will this do to all the existing applications written world-wide, and to all the trained application programmers doing the right thing? Seems like an irrational expectation.
I'm not happy with some aspects of Windows, SunSolaris, AIX, mainframes, iSeries, pcs, my car, ... I try to identify what I can change (or reasonably expect to change), and what I can't. Education is the key to effective change.
fjb_saper says:
You mean to say he has 3 choices
- Initiate change
- Comply with whatever is decided
- Take the road less travelled
Initiating change for the sake of change OR to accomodate the untrained makes no sense to me. If you change the initial values at the sending end for the few untrained programmers, you would have continue to do so for all future releases and maintenance cycles of MQ. This would require lots of testing AND needless work for you.
I don't understand why you fight this? (although it's a good, healthy intellectual discussion). Are you anti-IBM? If so, get over it. There is no real replacement for MQ. Businesses decisions should not be made based on favorite vendor (or hated vendor). Do you complain about the compiler if the programmer doesn't write good code?
I always try to remember to "do the right thing for the business." The right thing includes understanding the long-term effect of a change change. Ask 'do we have to make the change; or do we want to make the change?' There are always alternatives. See next paragraph.
Missing from ftb's short list of options is: educate those around us to understand the real (business) issues that underly our (your) recommedation. Again, if management decides that it is easier (in the short term) to change initial values, rather than training programmers, the decision is theirs, not yours.
zpat, I made the assumption that you are a sysadmin. If you are a manager, you can make changes whether they make (business) sense or not; whether they are needed or not - you have the power. If you are a sysadmin, your scope to change things is less. A change that meets your technical needs may be the wrong change for the business. It might make you more comfortable in your job - in the short term.
I mentioned in an earlier post that (I believe) you job is to protect the business from just this kind of change. |
|
| Back to top |
|
|
| zpat |
| Posted: Sat Nov 25, 2006 12:59 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Anti-IBM - hardly! I am usually accused of the opposite.
Doesn't mean that they can't improve their products though - even though many IT consultants like the fact that complexity means more work for them!
No alternative to MQ? - sadly many new IT people I meet think that FTP is good enough for data transfer and Web Services over HTTP is considered as the way forward for online services.
They don't seem to teach transactionality (in the CICS, MQ, DB2 sense) at Uni. Most IT graduates have never heard of MQ.
The day I stop trying to put the world to rights is the day I stop - period! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 25, 2006 1:17 pm Post subject: |
|
|
Guest
|
"The day I stop trying to put the world to rights is the day I stop - period!"
Excellent!
Caution: Some things need changing, some don't. Some things are much harder to change than others, some are easier. Some things take way too much time to change. Some things just aren't worth the effort. Some times winning the battle loses the war.
As Clint Eastwood said in some movie or other (and I paraphrase): "A man needs to know his limitations."
Most CIO's spent four years in college/university in front of a pc or UNIX workstation; and believe they know all there is to know about IT. This just adds to the challenge we face. It's these folks we have to pprotect the business from.
I saw a bumper sticker at some conference or other. It said: "FTP works 9 times out of 10." Yes, it does.
I've enjoyed our conversation. Thank you. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Nov 27, 2006 4:31 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Sorry Bruce. I think you misunderstood me when I said initiate change...
What I meant was to have them review their coding standards and conform to best practices... Not ask IBM to change it's code...or defaults....
But anyways this is all water under the bridges now...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 27, 2006 4:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I lost the will to go on at:
| bruce2359 wrote: |
| As a side note: programmers are trainable. |
I wish my lot were.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Nov 27, 2006 4:56 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Vitor wrote: |
| bruce2359 wrote: |
| As a side note: programmers are trainable. |
I wish my lot were.... |
Entrust to your application developers the creation of
1. the message data
2. the message descriptor - there are lots of things in here that need to be considered, designed, implemented. Persistence, CorrelId, CCSID, Encoding, Format, Expiry, ReplyToQ, etc. etc.
Just IMHO: I don't think it makes sense to remove responsibility from the application developers for 1 or 2. Application programs place messages into the messaging system; they care about data formats, and rules for processing data - including Format, CCSID, encoding etc. Providing overrides for these via admin interfaces appears to me to be (much) more error prone than the system we already have.
Just MHO, as I said. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 27, 2006 4:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I'm happy when they get the message data right. In 6 testing cycles or less.
As to the rest, I doubt they can spell MQMD.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Nov 27, 2006 5:03 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Vitor wrote: |
I'm happy when they get the message data right. In 6 testing cycles or less.
As to the rest, I doubt they can spell MQMD. |
I feel your pain (I think). But you wouldn't argue for sys admins overriding app settings of the msg data and msg descriptor, would you? Just interested... |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 27, 2006 5:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
In terms of settings like CCSID, Format, Persistence etc? Certainly not - these decisons properly belong with the application.
My point is solely that in my pain-distorted world life would be eaiser if things like Format could default to an admin-determined setting. In my case, it's an accepted fact that you code PERSISTENCE_AS_Q_DEFAULT but I doubt you could find 3 people who know what it means or indeed what the alternative values are! Likewise, they code FMT_STRING because if they don't a) the magic goes away b) I start ranting.
Hence, if persistence, priority & CCSID are under admin controlled default, why not format?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fswoc |
| Posted: Mon Nov 27, 2006 5:47 am Post subject: An update... |
|
|
Newbie
Joined: 23 Nov 2006
Posts: 2
Location: Toronto, Ontario
|
The responses to my original question have certainly pointed out some key concepts and configuration considerations. Thank you all for a very interesting discussion!
As for my original problem -- at present, I am forced into a "kludge" mode (ack , arrgh, but it is getting me over my hurdle) I do however, remain mindful of zpat's original warning "Anything else is a kludge that will cause more problems long term." so I don't consider my current solution as "the fix" by any measure.
I did some additional analysis on the 2 receive queues from my customer. Comparing messages, the "Put Application Name" is different; and the key difference is that app "A" sets MQSTR whereas app "B" leaves it blank... yet both contain the exact same type of data -- string.
What is worse is that my original software vendor (i.e. who wrote my "MQGET" application, a vendor who professes MQ expertise) did not even identify this issue during launch! This means whatever they're doing in their code is also a kludge... which makes me wonder what other kludges are there, too!!!  So I am sending off a nicely worded request to my customer to have their programmers update app "B" to play nicely. And a stern set of questions to my software vendor as well.  |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Nov 27, 2006 5:51 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Vitor wrote: |
| Hence, if persistence, priority & CCSID are under admin controlled default, why not format? |
For persistence and priority I agree, app can choose to "delegate" control to the administrator (but I don't think this is a good idea - if the message is important enough to be persistent and/or high priority, why allow a later admin alteration to a Q def to negate this?). For CCSID - is this admin-overridable? For Format, this is so closely coupled to the message data that I can't imagine wanting to "delegate" control to the administrator, unless the message contents were also similarly delegated. Maybe this would work in some shops, but not many, I would venture to suggest.
Footnote: insofar as an admin can install API exits for MQPUT, all such parameters are controllable by admins, so maybe all this is moot. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 27, 2006 6:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mvic wrote: |
| Footnote: insofar as an admin can install API exits for MQPUT, all such parameters are controllable by admins, so maybe all this is moot. |
If you're going to start talking exits, I'm going to go green & remember this appointment I need to go to....
Allow me to clarify my position (before we put down our handbags and return to our previous lives). In a standard configuration, MQ supplies to the application a default persistence & priority. The app has two choices: to explicitly set these values or to accept the defaults provided. I see most typically these values being left to the adminsitrator but determined as part of the design process. Message priority is relative - a high-priority message from a given application could easily be lower priority than another app using the same queue manager / channel / receiving queue. It is the job of the administrator, looking at the MQ set up as a whole, to decide what should use what.
As further evidence, I ask how many times you've been told a message must be persisitant by the programmer when there's absolutely no need for it to be? Or how often you've been told that a message can arrive "whenever there's time to deliver it" - all messages, even pointless updates, are top priority to the guy sending them!
Currently CCSID is a default queue manager value. My sole point is that, where the bulk of traffic is tag & value or XML, it would be useful if the queue manager could be set to default to this. Still leaving the app the ability to explicitly set it if the message required it.
fswoc - so long as you're over the hurdle you're further forward. Now you can worry about the ditch a bit further along..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
