| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Batch (MVS) |
« View previous topic :: View next topic » |
| Author |
Message
|
| offshore |
 Posted: Tue Dec 28, 2004 6:12 am Post subject: MQ Batch (MVS) |
 |
|
Master
Joined: 20 Jun 2002
Posts: 222
|
All,
First off Merry Christmas & Happy New Year.
I have a question, that I've been trying to figure out and thought I'd ask for input from you all here.
We have a MVS job that is part online & part batch and to throw some more fun is also in a parallel sysplex.
What I'm trying to do is figure out how to get the batch part of the process to be sysplex friendly. Currently the job has hard coded what queue manger to connect. What I need the ability to do is get that hard code partion out of there. Depending on what system the job get started on, the queue manager name is different.
Is there a way, aside from defining a default queue manager, to do this. What I was tossing around was some sort of QMGR Alias or virtual queue manager???
Thanks,
Offshore |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Tue Dec 28, 2004 7:44 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Offshore
If it were me I would write a quick program to determine what system the job is running on and have that set or pass the queue manager name to be used to the rest of the job.
Determining the system name of the system that the job is running on is pretty straightforward, what to do after that would depend on how the job is currently set up. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 28, 2004 11:37 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I would have thought that no qmgr would be hard coded in batch but rather be passed as a parm card.
But then my cobol & JCL days are over 15 years old...
Happy new Year  |
|
| Back to top |
|
|
| LuisFer |
| Posted: Tue Dec 28, 2004 12:09 pm Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
A QSG would can be a solution if you have RRS , DB2 , Coupling Facility & msgs under 64K?.
The QSG is unique on a SysPlex, and the Batch can run doing CONN to the QSG on any System with QMgrs connect to this one.
Merry Xmas. |
|
| Back to top |
|
|
| offshore |
| Posted: Thu Dec 30, 2004 3:53 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
Kevin,
That was my first choice, was to right a rexx exec to determing the sysname & assign the what QMGR needs to be put in the parm for a queue manager.
Which leads me to FJBs response. I orginally thought it was getting the qmgr name from a parm file (if you will), but it actully gets initiated thru CICS & submitted to the internal reader. As far as I know CICS has to have the JCL "hard-coded" into the program. There is a parm file, I assume incase it needs to be manually submitted for some reason.
LuisFer,
I've looked into QSG's, a year or so ago, but I don't think its a practical solution right now. I think the messages are above the 64K limit, so that included rewrite to segment messages, ect. Also, everything else I have setup for sysplex friendliness works fine, just this one little thing. So all the time & effort for 1 thing I don't think is worth it (yet).
I've come up w/ 2 options as of now. Have applications add a check to what system they're running on and substitute the appropriate qmgr name or see if I can convince & it's possible to convert to the MQ batch support pac.
Thanks All |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 30, 2004 10:38 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Offshore,
You are talking about CICS stuff. Well we have our CICS stuff triggered and read the QMGR name and Qname out of the trigger parameter that is being passed to the process....
Now if this process is not triggered you will have to fall back on any of the other methods you were looking at.
Enjoy |
|
| Back to top |
|
|
| pinhead |
| Posted: Thu Dec 30, 2004 11:36 am Post subject: |
|
|
Newbie
Joined: 30 Dec 2004
Posts: 8
Location: Hartford, CT
|
| Mainframe is very different from distributed. There really is no such thing as a default qmgr in this case. QMGR's are defined as an MVS subsystem, so the only way you can connect to an MVS QMGR is if you are running on the same processor. This is true for both batch and online. There are specific tasks in the system setup guide that explain how to connect to a given qmgr (IMS or CICS adapter, bridge, or batch). There are modules to assemble for IMS and batch (CSQBDEFV and CSQQDEFV), which allow you to specify qmgr name. You can have a separate library for each qmgr, which you can job/steplib to. This will allow your applications to issue connect statements without specifying qmgr name. You put the library you linked to into your IMS or batch JCL so you can connect to that specific qmgr. You don't need to do this for CICS, because you can only connect to one qmgr per CICS region. You cannot connect to a qmgr that is not physically on the processor your IMS/CICS control region, or batch job is running on. The only way I know of to use MQ across a sysplex regardless of what processor you are running on is to use shared queueing. This is not simple to set up, and there are restrictions which may not be practical in your environment. For batch, we use specific initiator classes that are only active on the processor that the qmgr needed lives on. |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Mon Jan 03, 2005 1:14 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Another solution is to place the "default" queuemanager module in a special dataset and place it on the linklist ahead of the normal MQ datasets. And I have different datasets on each LPAR.
This approach works for one of my clients. They are happy about the solution.
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| 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
|
|
|
|
