| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| migrating v6.1 subflows to v8 question/issue |
« View previous topic :: View next topic » |
| Author |
Message
|
| NealM |
 Posted: Tue Jan 08, 2013 2:23 am Post subject: migrating v6.1 subflows to v8 question/issue |
 |
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
We have hundreds of v6.1 message flows, almost all of which use a bunch of shared common subflows. In v6.1, the subflows are still of type .msgflow, but in v8 they need to be changed to type .subflow.
This is causing all kinds of breakage in trying to import the flows from an SVN library. I'm sure this isn't unique to us, yet I have not located any literature on this aspect of migration from v6.1 to v8, nor any similar topic on this forum Has anyone here gone through this and come across a best approach? How do we get around having to rewire the subflow back into the using flow if we manually "convert to subflow" our .msgflow subflows? So, every single message flow which uses a subflow of our many hundreds (which in our case, really means all of them) is broken in v8. This is especially painful for those subflows that have multiple input and output terminals, the wiring has to be redone, and redone carefully.
Hopefully I am missing some real simple migration principle here. |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Tue Jan 08, 2013 4:40 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Do the subflows need to have their file extension changed?
One of the more recent posts of the issues surrounding .subflow (for a 8.0.0.2 fix AFAIK) suggests that a workaround it to rename the .subflow back to a .msgflow
I'd probably leave all your existing flows well alone and not change the extensions.
If you have to change thme (when 8.0.0.2) comes along I'd look at creating a new repo subtree with the V7 source and use that going forward. After all some of the changes you have to make for V8 might not work on V7. The .subflow point is just one of them.
PErsonally, I think that trying to use the same repo for both V7 and V8 flows is just asking for trouble. IT is also a good time to clean out a load of the crud that is no longer being used.
just my 2p worth
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jan 08, 2013 6:03 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Migrating is not turn-key or without pain. Since the number of flows you are migrating is larger, plan for the migration to take longer, and enlist the help of regression testers.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| NealM |
| Posted: Sat Jan 12, 2013 1:13 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
Thanks smdavies. After reading up on the current problems with nested .subflows, I filed a PMR against the APARs to see if we can get an ifix. I'll likely find out from L3 after the weekend. If that doesn't happen, then I guess the only wise course at present is to leave all our subflows as .msgflows, as you suggest. I was hoping to take advantage of deploying a common subflows library though, and migration time is my best opportunity for setting that up.
And we did create a separate v8 "branch" in our repository with a copy of all the v6.1 ("trunk") flows, so as not to cross-pollute as we make changes, try out DFDL, etc.
By the way, thanks to our heavy use of common subflows, there really isn't much crud at all to clean up, just a few early subflows that fell by the wayside or got absorbed, and the need to point the few flows still using them to their replacements, rather than going through their old hollowed out shells to get to the new ones. This is an SOA shop. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Jan 12, 2013 1:47 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| NealM wrote: |
Thanks smdavies.
|
you are more than welcome.
| NealM wrote: |
And we did create a separate v8 "branch" in our repository with a copy of all the v6.1 ("trunk") flows, so as not to cross-pollute as we make changes, try out DFDL, etc.
|
| NealM wrote: |
By the way, thanks to our heavy use of common subflows, there really isn't much crud at all to clean up, just a few early subflows that fell by the wayside or got absorbed, and the need to point the few flows still using them to their replacements, rather than going through their old hollowed out shells to get to the new ones. This is an SOA shop. |
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jan 14, 2013 1:22 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| csongebalazs |
| Posted: Mon Jan 21, 2013 2:29 am Post subject: |
|
|
Voyager
Joined: 30 Jan 2004
Posts: 78
|
Just a remark about: http://www-01.ibm.com/support/docview.wss?uid=swg1IC88593
My 8.0.0.1 toolkit connects to a CVS repository and during the check out of our projects (which made in toolkit 7) this error appered too too, and was no other option, just closing the toolkit. After reopening, the build was success, but i had no idea, the imported data is "healty" after this stack owerflow error, or not, and it would leads to another problem in the future. I did not found any info about afterlive of the overflow error nor on the IBM page, nor this topic.
And was no info either about is this error exsists under 8.0.0.0 or not, so i removed the fixpack by the installation manager, deleted my whole workspace and started the import from the scratch. The toolkit 8 without any fixpack didn't throw any stack overflow error during migration (check outing 4 different projects from the CVS repository).
So till IBM fix this problem in fixpack 2, should we do migration from 7 to 8 with "basic" toolkit, and install any toolkit fixpack after all migration done or should we awoid to install fixpack 1 totally and wait for fixpack 2? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 21, 2013 6:43 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you tried migrating by importing from an project interchange format? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| NealM |
| Posted: Mon Jan 21, 2013 8:58 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| IBM did generate an ifix for us (for z-linux platform) last week, which covers all known runtime (not toolkit) subflow problems, APARs IC89508, IC87097 (superceded IC86793), IC83407, and IC87243. So if you can't wait for FP 2..... |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
