| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Download link for WebSphere MQ Base Version 7.0.0.0 |
« View previous topic :: View next topic » |
| Author |
Message
|
| raam |
 Posted: Sat Oct 01, 2011 12:31 am Post subject: Download link for WebSphere MQ Base Version 7.0.0.0 |
 |
|
Apprentice
Joined: 14 May 2011
Posts: 29
|
Hi,
Can someone kindly help me locate the link for downloading the WebSphere MQ Base version 7.0.0.0?
I am basically looking at migrating MQ from V6.0.2.5 to V7.0.0.0 and then upgrading to V7.0.1 eventually.
Thanks a lot.
_________________
Thanks a lot.
You're only given a little spark of madness. You mustn't lose it…..  |
|
| Back to top |
|
 |
| exerk |
| Posted: Sat Oct 01, 2011 1:35 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Talk to your IBM rep because you can't download that version even as the trial. I believe the latest GA version is 7.0.1.3 (as that's the current trial version), but your rep, or Passport Advantage will inform.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| zpat |
| Posted: Sat Oct 01, 2011 1:57 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Use the refreshed distribution of v7.0.1.3, you would be ill-advised to upgrade to anything earlier.
Even then applying the latest fixpack 7.0.1.6 afterwards might be a good idea. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 01, 2011 5:29 am Post subject: Re: Download link for WebSphere MQ Base Version 7.0.0.0 |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| raam wrote: |
I am basically looking at migrating MQ from V6.0.2.5 to V7.0.0.0 and then upgrading to V7.0.1 eventually.
|
Why do you feel the need to go to first to 7.0.0.0, and only eventually 7.0.1.x? Why not go to what's current?
_________________
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 |
|
|
| raam |
| Posted: Sat Oct 01, 2011 5:44 am Post subject: |
|
|
Apprentice
Joined: 14 May 2011
Posts: 29
|
Thanks for your responses.
I was under the assumption that the 7.0 base version was still available for download. However, after reading your responses, and going through the Passport Advantage link, I figured out that the WMQ version 7.0.1 is what is currently available. I have downloaded the relevant zip files for WMQ, WMB and the Toolkit.
So I guess I am good at this point.
Dear zpat -
Can you please elaborate on your reply, if you don't mind? Any reason why you are suggesting that I directly migrate WMQ to v7.0.1.3 and not any version earlier? I was considering migarting WMQ to v7.0.1 and then applying the FP 7.0.1.5.
Thanks a lot.
_________________
Thanks a lot.
You're only given a little spark of madness. You mustn't lose it….. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 01, 2011 9:09 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| raam wrote: |
| I was considering migarting WMQ to v7.0.1 and then applying the FP 7.0.1.5. |
IMHO, I'd want (my clients) to be at a version/release/fixpack recommended (offered) by IBM - not some older version (7.0.0.0). But I wouldn't want to be at a bleeding edge, brand-new fixpack level, unless there was some compelling business requirement the brand-new fixpack brings.
_________________
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 |
|
|
| mvic |
| Posted: Sat Oct 01, 2011 9:44 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| raam wrote: |
| Any reason why you are suggesting that I directly migrate WMQ to v7.0.1.3 and not any version earlier? I was considering migarting WMQ to v7.0.1 and then applying the FP 7.0.1.5. |
Research for yourself at http://www.ibm.com/support/docview.wss?rs=171&uid=swg27014224
Hint: search through all the APARs for "migrat". This will match "migrate", "migration", and so on. IMHO, it is best to use the latest code, to avoid known bugs from affecting you. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 01, 2011 10:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
Ah. We've stumbled into the perennial software maintenance quagmire: software that is too out-of-date likely has had bugs that were fixed in subsequent maintenance; while software that is too current likely has bugs that have not yet been discovered.
Most software bugs are detected and fixed in the first 90 days of GA. I'm a bit neurotic about applying maintenance in its first 90 days of life.
Each organization has its own level of risk-aversion.
[/img]
_________________
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 |
|
|
| mvic |
| Posted: Sat Oct 01, 2011 11:23 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| Most software bugs are detected and fixed in the first 90 days of GA. I'm a bit neurotic about applying maintenance in its first 90 days of life. |
I don't think there is any evidence for that. Maybe you intended some phrase other than "Most software bugs".
UPDATE:
To clarify what I was trying to say, compare the list of problems found and fixed in the first fix pack 7.0.0.1, which I think was about 6 months after 7.0.0.0, with the list fixed in later fix packs. The list found after 7.0.0.1 is much longer than the list found before. This effect will be reinforced the more people stay away from a product, waiting for the first fix pack or two to go by, before picking it up and trying it. IMHO, I don't suppose MQ is uniquely subject to this pattern - I'd guess it is the same with all software products that have a large-ish customer base.
The page I was referring to: http://www.ibm.com/support/docview.wss?rs=171&uid=swg27014224 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 01, 2011 1:56 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
I'm suggesting that organizational policy drive the maintenance cycle.
For organizations that operate vehicle fleets (like the one I came from) perform preventive maintenance (IBM PTFs, corrective service (IBMs APAR fixes), or they do nothing, based on an established policy, which is usually based on cost/benefit analysis - which falls within the organizations aversion to risk.
Computer hardware and software should be managed in the same way - by policy.
The organization I came from depended on its multi-million dollar daily billing cycle, and revenue stream that resulted; and we were a medium-size company. They, and I, were risk-averse. Most every decision made revolved around 'what is the risk to the revenue?'
The executives I worked for routinely asked (at my prompting) about the potential risk from fixpacks, application changes, o/s changes, network changes, new hardware, migrations, fall-backs (falls-back?), and so on.
I greatly appreciated those other organizations that cheerfully implemented the newest and latest of everything. They did the testing that was impossible for my organization (limited staff, limited budget limited time), and IBM, to accomplish, namely: real-world testing.
Again, I'm not suggesting apply the latest. Nor am I suggesting don't apply the latest. I'm suggesting that the decision should be based on policy - and with commensurate expectations.
_________________
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 |
|
|
| bruce2359 |
| Posted: Sat Oct 01, 2011 2:17 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| mvic wrote: |
| bruce2359 wrote: |
| Most software bugs are detected and fixed in the first 90 days of GA. I'm a bit neurotic about applying maintenance in its first 90 days of life. |
I don't think there is any evidence for that. Maybe you intended some phrase other than "Most software bugs".
|
One of my replies in this stream got lost.
I attended an IBM conference a few years ago. One of the sessions addressed the IBM hotline, code defects, problem-source identification, RETAIN, multi-level support at IBM, the APAR and PTF processes, and so on.
The session included a graph with months on the horizontal axis - from month 0 (GA), out to 24 months (if memory serves). This can be seen as very current through non-current. The vertical axis was percentage of code defects detected (by customers), and resolved.
The curve was knee-shaped. The steepest part represented the first 30, 60, 90 days (very current, somewhat current...). This is where IBM really appreciates us calling code defects to their attention. The curve flattens in the 90 day time-frame, and stays fairly flat beyond that.
mvic is correct in that if nobody applies the latest fixpack in the first 90 days, no code defects will be detected. Of course, this would mean that the 90 day clock didn't start ticking, did it?
The reality is that some organizations want or need to be very current, while others prefer not to be.
Not applying service means that your environment is at more risk from code defects already detected and fixed. Alternatively, applying service means that your environment is at risk from code defects not-yet detected and fixed.
What to do. What to do.
_________________
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 |
|
|
| exerk |
| Posted: Sat Oct 01, 2011 2:55 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
I prefer not to be further away than n-1 with FixPacks. Roll out the latest one on a crash-n-burn box representative of the infrastructure, i.e. developer tin, and see what (if anything) breaks, then roll it everywhere else after some soak time.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 01, 2011 3:09 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
Another common approach (see mvic's post above), and my favorite, is to look at the list of what got fixed in fixpack 7.x.x.x, then analyze the list to see if your current environment is at risk. Then apply, if it makes sense to do so; then test...
_________________
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 |
|
|
| mvic |
| Posted: Sat Oct 01, 2011 4:23 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| The reality is that some organizations want or need to be very current, while others prefer not to be. |
I'd say something like this, but not exactly this. A lot of sites (most?) have development and production teams. The development team is developing the next release of their app. The production team is looking after the current release of the app, and making it run smoothly.
In development, you can take the latest code, and in the occasion (rare/never) it regresses something, you can roll it back, no great loss to the business. In production the opposite, you only push out an update after it has been through a lot of QA. So I guess a single organization can have within it more than one policy on this. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 01, 2011 5:11 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
You have succinctly described a single, effective, encompassing policy that dictates:
test in TEST; then
validate in QA when testing confirms it's QA-ready; then
move to PROD if/when the prior two have demonstrated that the changes meet business requirements for going live.
I'm quite comfortable with this.
_________________
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 |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
