| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Training for MQ on z/OS? |
« View previous topic :: View next topic » |
| Author |
Message
|
| bfzhou |
 Posted: Fri Oct 21, 2005 8:33 am Post subject: Training for MQ on z/OS? |
 |
|
Apprentice
Joined: 07 Aug 2003
Posts: 38
Location: Springfield, VA
|
I'm looking for the training from IBM that just enables me to manage MQ infrastructure on z/OS as I do on distributed platforms, but without the need to acquire mainframe system programmer level knowledge and skills.
Can anyone recommend such a class?
thanks, |
|
| Back to top |
|
 |
| wschutz |
| Posted: Fri Oct 21, 2005 8:36 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
|
| Back to top |
|
|
| javagate |
| Posted: Fri Oct 21, 2005 8:49 am Post subject: |
|
|
Disciple
Joined: 15 Nov 2004
Posts: 159
|
To install MQ and apply maintenance on z/OS requires basic System Programmer skill which cannot be learned overnight. That type of skill set takes many years of hard work.  If you are not familuar with z/OS this is not a good path. If you do not know z/OS you will NOT be able to install it, create queue-managers, or do any admin work. 
_________________
WebSphere Application Server 7.0 z/OS &
MQ 6.0. I work with WebSphere in the real world not in some IBM lab. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Oct 21, 2005 9:07 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Welllll....you could do the admin work via the support pack (MO71) I suppose, but I agree with javagate....Installation and Queue manager creation etc will take more than just an z/OS MQ manual.
 |
|
| Back to top |
|
|
| javagate |
| Posted: Fri Oct 21, 2005 9:11 am Post subject: |
|
|
Disciple
Joined: 15 Nov 2004
Posts: 159
|
MO71 is a security risk yet a great tool... A good z/OS MQ guy would lock any users from using MO71 and or any non production blessed applications out. 
_________________
WebSphere Application Server 7.0 z/OS &
MQ 6.0. I work with WebSphere in the real world not in some IBM lab. |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Oct 21, 2005 11:13 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
As everyone here had already stated, If you take this class (I am an IBM instructor, and a MF+MQ admin, so I should hopefully know) you will not be able to install MQ on your own, and even if you would theoretically be able to - Don't; this is something only an experienced MF admin should do, you easily could end up crashing the whole system.
You will, however, be able to tell your MF admin exactly what you want your setup to look like - Page files, log files and archiving behavior - and that's saying a lot. The best scenario would be that the z/OS MQ admin used to be a MF admin in the past, but if such a person is not available, it is still beneficial to take the course, provided you at least know MF basics. |
|
| Back to top |
|
|
| javagate |
| Posted: Fri Oct 21, 2005 11:37 am Post subject: |
|
|
Disciple
Joined: 15 Nov 2004
Posts: 159
|
MQSeries on the MF takes many hats to support.
1 Hat to do the SMP/E installation + apply any maintenance
1 hat to set the qmgrs up (allocate pagesets,logcopy,bsds,define objects,etc)
1 hat to set up security
1 hat to have the ability to tune the qmgr
1 hat to do the programming
1 hat to understand some TCP/IP,VTAM if using LU6.2 channels,Networking
1 hat to diagnoise problems, take SVC dumps/read dumps, take traces, start/read GTF traces
There is a lot to know 
_________________
WebSphere Application Server 7.0 z/OS &
MQ 6.0. I work with WebSphere in the real world not in some IBM lab. |
|
| Back to top |
|
|
| bfzhou |
| Posted: Fri Oct 21, 2005 11:37 am Post subject: |
|
|
Apprentice
Joined: 07 Aug 2003
Posts: 38
Location: Springfield, VA
|
thank all for the input.
Currently I access MQ on z/OS through a system interface, where I can perform routine admin work, although not in the scale of convenience on the distributed platforms. For instance, I don't have a command console where I can run runmqsc command or create backup of qmgrs.
My mainframe collegue told me that tasks like setting up triggering on mainframe is different than on distributed platforms, which I don't really believe is the case. But since I knows nothing about z/os, I can't figure out the right way of doing these things.
On the other hand, I don't want to become a z/OS system programmer.
What I need is just a 2-day intro course on basics of z/OS that is closely related to MQ admin tasks. I realized also the manual is not enough. for example, I just can't find a command console to put in the command as stated in the manual. |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Oct 21, 2005 11:52 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| For instance, I don't have a command console where I can run runmqsc command |
You have the same commands, it's just that they're submitted through a batch job.
| Quote: |
| setting up triggering on mainframe is different than on distributed platforms |
Not triggering in general. Triggering Channels to start when messages arrive on the XMITQ used to be different, but not any more.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Oct 21, 2005 11:55 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| bfzhou wrote: |
| My mainframe collegue told me that tasks like setting up triggering on mainframe is different than on distributed platforms, which I don't really believe is the case. |
He's wrong, you're right. All WMQ tasks, in 5.3+ versions, other than installation/performance tuning/logging management and the like are the same - MQ is MQ.
| bfzhou wrote: |
| On the other hand, I don't want to become a z/OS system programmer. |
No worries, no such certificate is bound to pounce on you from a dark corner
| bfzhou wrote: |
| What I need is just a 2-day intro course on basics of z/OS that is closely related to MQ admin tasks. I realized also the manual is not enough. |
No such course, and surely no such 2 day course.
First you must get the hang of the MF interface (aka ISPF), no going around it - then you must learn to use the console, write JCL (batch jobs), compile programs etc etc. So first take a MF course (3 days very basic, another 3 to complement) and then take the 3 day WMQ z/OS course; the order is not important, but just one is insufficient.
| bfzhou wrote: |
| for example, I just can't find a command console to put in the command as stated in the manual. |
That's because it doesn't exist, there's something called a "console" and a "subsystem command prefix" you should look into, or just ask a MF admin. Or you can, as EddieA suggested, use CSQUTIL in batch. |
|
| Back to top |
|
|
| bfzhou |
| Posted: Fri Oct 21, 2005 12:15 pm Post subject: |
|
|
Apprentice
Joined: 07 Aug 2003
Posts: 38
Location: Springfield, VA
|
I think I should pursue the route you suggested.
Specifically, we have a major argument with my MF collegue over the use of MA12 from Wayne Schutz. My common sense told me it must operate just like the included runmqtrm in other platforms, that it should be running all the time, that only one initiation queue is needed per qmgr, and the process definition's applID field should contain sth (job card?) that starts the program.
But right now, app_1 starts the trigger monitor upon sending out a request, when the reply arrives, and a trigger msg put into the initiation queue, the it starts a second application app_2, and shutdown the trigger monitor, the trigger monitor virtually does nothing. This looks a rather strange setting, but it works most of the time. This is certainly not the right way of doing things. But to straighten it out, I have to have certain minimal MF skills related to the tasks.
You're right, there is probably no shortcut than learn the basics of MF first. I do have a ISPF where I access MQ objects. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Oct 21, 2005 12:55 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
The MF people are right about one thing when it comes to triggering......there is no runmqtrm command. Any trigger monitor on the mainframe (other than CICS or IMS) will have to be user written.
There is a support pack out there that can be tweaked and used but someone will need to assess if that is approriate for your site. |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Oct 21, 2005 1:18 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| bfzhou wrote: |
| My common sense told me it must operate just like the included runmqtrm in other platforms, that it should be running all the time, that only one initiation queue is needed per qmgr, and the process definition's applID field should contain sth (job card?) that starts the program. |
As kevin just said, no batch trigger monitor is supplied with the MQ basic installation, but there's a support pack, and it's quite easy to write one yourself if you wish - you code the MQ part, and ask your MF guy to code the batch submission part.
| bfzhou wrote: |
| But right now, app_1 starts the trigger monitor upon sending out a request, when the reply arrives, and a trigger msg put into the initiation queue, the it starts a second application app_2, and shutdown the trigger monitor, the trigger monitor virtually does nothing. This looks a rather strange setting, but it works most of the time. This is certainly not the right way of doing things. But to straighten it out, I have to have certain minimal MF skills related to the tasks. |
Yep, that's a pretty odd setting indeed 
Why doesn't your sending application simply issue an MQGET after it's MQPUT? Why don't you just leave the "trigger monitor" (what is this? something you've written yourself?) running?
This is basic MQ stuff, I think you can probably solve this without MF related knowledge, just basic common sense and MQ skills. You have no alternative but to start learning how to work with a MF admin hand-in-hand; accept the fact that you will probably never achieve sufficient MF skills to install MQ, simply because you'll have to be a MF admin for a while to gain the necessary experience, and you'll be too busy with MQ. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 21, 2005 2:19 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
My recommendation, actually, is to not learn MQ on z/OS at all.
Merely push your current team to upgrade to v6.
Then you can use "regular" PCF messages, and will be able to, for example, administer z/OS MQ with the Eclipse based MQ Explorer that comes with v6.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Oct 21, 2005 3:14 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| jefflowrey wrote: |
My recommendation, actually, is to not learn MQ on z/OS at all.
Merely push your current team to upgrade to v6.
Then you can use "regular" PCF messages, and will be able to, for example, administer z/OS MQ with the Eclipse based MQ Explorer that comes with v6. |
That doesn't really help him with managing pagesets, logs, archiving, bufferpools, trigger monitors, CSQUTIL, dead letter queue handler... All that aside from the fact that sometimes, there's a comm problem (which may even be the actual prob at hand), and you can't connect externally - console abilities, in general, always pay off.
Notwithstanding that MQ v6, as has been said many times b4, is too new to be safe, especially for a site with no descent z/OS MQ admin (no offense bfzhou). |
|
| 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
|
|
|
|
