| Author |
Message
|
| solomon_13000 |
 Posted: Thu Oct 02, 2008 9:12 pm Post subject: coupling facility |
 |
|
Master
Joined: 13 Jun 2008
Posts: 284
|
| Are messages held in a shared queue stored in a coupling facility?. Why is it stored in a coupling facility?. Is it because of availability issue. What are the factors that lead to availability?. Is it because coupling facility resides outside of the OS environment and therefore it can withstand failure such as hardware, power and so on?. Also do we only use coupling facility in a mainframe environment?. Also when we define the attribute CFLEVEL with the value 4, it means that the coupling facility can hold messages of the size 100 MB. Now does the value 1 = 25 MB?. What is the minimum and maximum value that can be define for the attribute CFLEVEL? |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Fri Oct 03, 2008 2:32 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| The coupling facility is used on the mainframe and you need to go do some reading of the manuals. |
|
| Back to top |
|
|
| solomon_13000 |
| Posted: Fri Oct 03, 2008 5:03 am Post subject: |
|
|
Master
Joined: 13 Jun 2008
Posts: 284
|
| well Im more into win and linux platform. That is why I needed to have some general idea what I need to look for when it comes to MQ on mainframe as to be sure that I understand things in the correct way. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Oct 03, 2008 5:16 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 03, 2008 7:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Briefly, very briefly:
A CF is an architectured storage (not byte addressable) box that is fiberoptic attached to several/many instances of z/OS LPARs - either in the same box or differnt boxes. No disks in the CF.
Through another software (DB2 Shared Data something) layer and local qmgr local queue definitions, messages can be propogated (put) into a CF 'queue' such that any qmgr can get them.
This provides for substantial increase in throughput and failover capability. Read more. Take the WMQ Advanced System Admin for z/OS course from IBM.
_________________
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: Fri Oct 03, 2008 7:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Further:
Each qmgr runs in its own address space with its own logs and datasets (mainframe term - think filesystem and you are close enough for this discussion). The only thing shared between these instances of z/OS and qmgrs is data in the CF.
_________________
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 |
|
|
| solomon_13000 |
| Posted: Fri Oct 03, 2008 7:44 am Post subject: |
|
|
Master
Joined: 13 Jun 2008
Posts: 284
|
So a DB2 Shared repositary is required to setup a shared queue.
Last edited by solomon_13000 on Fri Oct 03, 2008 8:10 am; edited 2 times in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Oct 04, 2008 4:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Meaning that the queue manager log and data files residing on an external storage will be mounted on the primary or standby server. |
Are we still discussing the mainframe Coupling Facility?
Yes, the CF is mainframe-only. The usual configuration is for many z/OS instances - all having access to the same set of i/o devices, thus the same applications and data. This allows for any z/OS instance to do any workload (workload sharing). At this level (Parallel Sysplex), the CF, a stand-alone box (or duplexed boxes) can host frequently-used objects (data tables, queues) without disk access latency.
A shared queue can be shared with many qmgrs - in the same LPAR, across LPARs in the same box, or across physical boxes. Each qmgr maintains its own logs and pagesets - these are not shared. These qmgrs are usually alive and well doing application work with non-shared and shared queues - not in standby.
The usual objective of queue-sharing is to enable any app connected to a qmgr with access to the CF can get a msg from the CF, or put a message to the CF. The CF offers high-bandwidth (fiberoptic channels) and high-availability (available to many qmgr instances). Shared queues can be triggered, in which case any qmgr app can consume the message.
Another feature of shared queues is Intra-group queuing, which eliminates the need for an mq message channel for a message to flow from one qmgr to another across the CF.
Take a look at the WMQ z/OS Concepts and Planning manual, where shared queues are discussed in some detail.
The CF runs in LPAR mode (under PR/SM). The Coupling Facility Control Code is upgraded from time-to-time. The CFLEVEL is the version/release of this CFCC code.
_________________
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 |
|
|
| fjb_saper |
| Posted: Sat Oct 04, 2008 8:00 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
|
| Back to top |
|
|
|
|
