|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
JMS with IBMMQ jar dependencies during run time |
« View previous topic :: View next topic » |
Author |
Message
|
mqjeff |
Posted: Fri Sep 10, 2010 8:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Vitor wrote: |
70033 wrote: |
This is of course the management desire to have a vendor neutral solution just by changing configuration ( and not adding any provider specific jars anywhere). |
I knew it! I just knew it! I'm on fire today.....
Of course, you could reasonably argue that that's exactly what you've achieved. To change vendors you just change the configuration, which includes installing the vendor specific components. You don't need to change or regression test a line of code. |
But you do need to rebuild your entire messaging network and retrain your entire messaging network staff and reconfigure or replace your messaging network monitoring solution and and and and
Just ask Management how much difficulty it would be for them to switch from using Microsoft Excel to using OpenOffice or Lotus Symphony.
Then see how they really feel about vendor-specific installs.
If nothing else, it might distract them from meddling in your affairs whilst they spend six months trying to find a vendor-neutral spreadsheet program.  |
|
Back to top |
|
 |
Vitor |
Posted: Fri Sep 10, 2010 9:10 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mqjeff wrote: |
But you do need to rebuild your entire messaging network and retrain your entire messaging network staff and reconfigure or replace your messaging network monitoring solution and and and and |
Well yes, of course, but the code is vendor neutral and configuration changes are simple. It said so in that magazine article they read in the airport terminal that prompted all this...
mqjeff wrote: |
Just ask Management how much difficulty it would be for them to switch from using Microsoft Excel to using OpenOffice or Lotus Symphony. |
Or from OS/COBOL to COBOL/370. A "simple configuration change" requireing nothing more than the change to the STEPLIB of every single piece of compile JCL in the place, the recompilation of slightly over 5,000 source decks and then fixing the odd bit and pieces that didn't compile due to obsolete features or loose code the new compiler wouldn't wear.
Then of course you track down the subtle changes in runtime behaviour that crawl out of the woodwork. But it's a simple configuration change, doesn't take long or need many people....  _________________ 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
|
|
|
|