| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Creating Qmanager on Tandem using SMF (Virtual Disks) |
« View previous topic :: View next topic » |
| Author |
Message
|
| AndyMQ |
 Posted: Thu Apr 22, 2004 4:05 am Post subject: Creating Qmanager on Tandem using SMF (Virtual Disks) |
 |
|
Apprentice
Joined: 22 Apr 2004
Posts: 33
Location: Scotland
|
Has anyone successfully created a queue manager on a virtual disk on a Tandem S-Series?
My customer tried and received loads of errors. 
He has MQ 5.1 at CSD01 (haven't applied CSD02 yet). The crtmqm completes with lots of FFSTs, but the subvols and files are all created. The strmqm fails miserably though.  Can't find any mention of virtual discs in the manuals.
Anyone got any ideas? |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Thu Apr 22, 2004 5:09 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
I dont think MQ support is there for SMF as yet. Since the concept of SMF is relatively new. :)
But in any case, a curious question. Why do you want to "create" a qm on a virutal disk. I dont see any benefits of it. Unless of course, your standards say that "everything that is done on NSK has to BE on SMF". Because just creating a QM on SMF wont help in any way. Since the space taken by a qm is very minimal compared to what might be available for SMF.
Yes, i can understand you may want to have queues that would have lots of persitent messages of huge sizes to be on SMF. For that you could very well create a qm outside of SMF, on a physical volume and then use altmqfls to move those queues to SMF. Just a suggestion. :)
Cheers
Kumar |
|
| Back to top |
|
|
| AndyMQ |
| Posted: Thu Apr 22, 2004 5:51 am Post subject: |
|
|
Apprentice
Joined: 22 Apr 2004
Posts: 33
Location: Scotland
|
Curious indeed .... however the customer is new to S-Series having been a long time user of K-Series (and all preceding Tandems). They are migrating from a K-Series with 2GB and 4GB disks to S-Series with 18GB and 72GB disks, so the use of SMF is not because the have space issues, it is to make for an easy migration. They don't have to worry about changing file names as they can just lift and drop to the new system. Not the most efficient way of using SMF, but it serves the purpose. Their existing queue manager on K-Series unfortunately resides on one of the disks which will replaced by a virtual disk.
Fortunately, they will be setting up the queue manager environment from scratch on the new machine, and changes to volume names are simple, so they shouldn't have a problem.
Thanks for the rapid response and the altmqfls suggestion. I'll see if I can persuade them to try that, just out of curiosity of course!! |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Apr 22, 2004 6:03 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Well, as far as MQ is concerned, you dont really need to worry about migration and volume/sub-vol names etc, since you have UPGMQM utility that would change all of that for you. As for their other disk files, i would expect most of them to have hardcoded volume/sub-volume names, which would mean that they have to find a single common disk volume name(for SMF which would have only one single disk voulme name, as far as i understand it. Though havent worked with SMF a lot, :)... ). And it may be hard anyways.
Imagine they having about 10 subvols with 100's of enscribe files in it and most of them audited files with hardcoded disk/volume/sub-vol names. How can you move all of them without having to manually change this info to SMF(since it would be now a single disk volume name).
Now, all of the above theories are on the assumption that SMF uses only one volume name and that it is mapped to many physical volumes.
So, all in all, i would think a lot of manual intervention is needed anyways. If i were to design the migration, i would keep all the disk volumes and sub-vol names and structures "as is" to save the overhead time to deal with errors/issues later on.
But again, if it were you or me, we would have probably done this. Customers... hmmm... :). Good luck.
Cheers
Kumar |
|
| Back to top |
|
|
| AndyMQ |
| Posted: Thu Apr 22, 2004 6:28 am Post subject: |
|
|
Apprentice
Joined: 22 Apr 2004
Posts: 33
Location: Scotland
|
Yep, luck is what we need. The way they are using SMF is kinda different from everybody else. They only have a single pool per physical disk, so all files on a virtual disk will actually reside on a single physical. That means that they don't actually have to change filenames. Just create SMS, create the pools, create the virtual disks, restore the files, and Bob's yer uncle!! The virtual disk process manages the mapping of virtual to physical, so you don't actually have to do anything. It's actually pretty neat.
Of course the real reason for SMF is that the smallest disk sold by Tandem is 18GB and the customer currently have a mix of noddy 1GB, 2GB, and 4GB disks which are generally 50% full. They didn't want to have one-to-one mapping 'cause they'd end up with loads of 18GB disks with 90% freespace and more!!
They don't even have to use UPGMQM as they are installing and configuring from scratch, but will continue running from K-Series for some time yet.
They won't use UPGMQM because they experienced a LOT of problems using it to go from 2.2.0.1 to 5.1 just a few months ago. They ended up with both releases running side by side and configuring their 5.1 queue manager from scratch. That's why they have nice, accurate config scripts which should make life sooooo easy for them...you'd think!!!
Users eh? |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Apr 22, 2004 6:52 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Must be a lot of work, if they are mirroring everything from one node to the other. Why dont they use may be RDF to do the mirrioring for you. Even though this isnt again the most apporpriate utility to use, but serves the purpose.
Also UPGMQM in the GA version had lots of flaws which was fixed along the way and i believe CSD01 has the final version of this utility that works without any issues and have some enhanced features as opposed to the GA version of it.
Cheers
Kumar |
|
| Back to top |
|
|
| AndyMQ |
| Posted: Thu Apr 22, 2004 7:21 am Post subject: |
|
|
Apprentice
Joined: 22 Apr 2004
Posts: 33
Location: Scotland
|
It's actually even more scarey than that. They will be using RDF plus probably Extractor/Replicator and maybe even AutoSync and AutoTMF. The problem is that they have avoided migrating to S-Series for such a long time due to politics and strategies. So much so that they actually "split" their K-Series into 2 nodes some time ago rather than invest in S. The K to S migration actually becomes a 2 to 1 merge (or 4 to 2 if you include hot-standby).
As we are talking about a bank here, you can quickly appreciate the amount of planning (and paranoia) involved. The migration itself will span many months and go ahead in phases. I'm not sure when MQ will be cut over, or if they will try queue "hopping" as an interim measure, but I suspect MQ may be the least of their worries. |
|
| Back to top |
|
|
| AndyMQ |
| Posted: Fri Apr 30, 2004 12:55 pm Post subject: |
|
|
Apprentice
Joined: 22 Apr 2004
Posts: 33
Location: Scotland
|
Further investigation has shown that the problem had nothing to do with virtual disks. They were using an "unusual" hometerm process. When they changed to the standard $ZHOME, everything kicked off perfectly (including the queue files on a virtual disk).
Thanks for the suggestions though! |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Apr 30, 2004 1:04 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Glad to know that it all worked out well at the end. So, that would mean, NSK works on SMF now. Learnt something new today. :)
Since it wasnt documented anywhere, assumption was it wasnt supported. Cz if it were, it would have been documented. :)
Good luck.
Cheers
Kumar |
|
| 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
|
|
|
|
