目前分類:◇MQueue (20)

瀏覽方式: 標題列表 簡短摘要
2007年12月16日 星期日

.
. IBM WebSphere MQ v6.0
. Ex 6 - IBM WebSphere MQ Client Implementation.
. 讓我們來練習一下 MQ Client Implementation
.

=== Exercise 6 : WebSphereMQ Client Implementation ===
What we will do :
A. Configure a Server for client connection.
B. Configure a client.
C. Test a client to server environment.
D. Use Auto-Definition of a CHANNEL.
E. Setup and perform Remote Administration.


=== Sample programs for MQ client ===
1. # amqsputc QName [QMgrName]
(This program is invoked the same way as amqsput and has the same parameter structure. But it connects to a WebSphereMQ client instead of a WebSphereMQ Server.)

2. # amqsbcgc QName [QMgrName]
(This program is invoked the same way as amqsbcg and has the same parameter structure but it connects to a WebSphereMQ client)

3. # amqsgetc QName [QMgrName]
(This program is invoked the same way as amqsget and has the same parameter structure but it connects to a WebSphereMQ client)


======================================================
[A. Server Queue Manager setup]
1. Create Queue Manager named QMC06 , and QMC07R :
 # crtmqm QMC06   # crtmqm QMC07R
 # strmqm QMC06   # strmqm QMC07R
 # runmqsc QMC06   # runmqsc QMC07R

 (on QMC06)
 : DEF QL(DLQ) REPLACE
 : ALTER QMGR DEADQ(DLQ)

 : DEF QL(XQMC07R) REPLACE USAGE(XMITQ)
 : DEF CHL(QMC06.TO.QMC07R) CHLTYPE(SDR) REPLACE +
  TRPTYPE(TCP) CONNAME('Host2(9007)') XMITQ(XQMC07R)


 (on QMC07R)
 : DEF QL(DLQ) REPLACE
 : ALTER QMGR DEADQ(DLQ)

 : DEF CHL(QMC06.TO.QMC07R) CHLTYPE(RCVR) REPLACE +
  TRPTYPE(TCP)
 : DEF QL(QL.A) REPLACE

 (on QMC06)
 : DEF QR(QRMT07R) REPLACE +
  RNAME(QL.A) RQMNAME(QMC07R) XMITQ(XQMC07R)


 (on QMC07R)
 # runmqlsr -m QMC07R -t TCP -p 9007

 (on QMC06, CHANNEL 啟動狀態)
 # runmqchl -C QMC06.TO.QMC07R -m QMC06
 # amqsput QRMT07R QMC06  (測試通道是否暢通)

2. Define a SVRCONN CHANNEL on QMC07R to make it connectable by clients :
 a. Use QMC07R_CLNT as the CHANNEL name.
 b. Protocol is TCP.

 # runmqsc QMC07R
 : DEFINE CHL(QMC07R_CLNT) CHLTYPE(SVRCONN) REPLACE TRPTYPE(TCP)

3. Be sure that an appropriate Listener function is avtive for the Server QM.
 # runmqlsr -m QMC07R -t TCP -p 9007

[B. Client setup (Method 1)]
4. Use the MQSERVER environment variable to provide a client-connection CHANNEL Definition to be able to connect to the Queue Manager.

 (UNIX / Linux Systems)
 # export MQSERVER=QMC07R_CLNT/TCP/QMC07R(9007)

 (Windows Systems)
 # SET MQSERVER=QMC07R_CLNT/TCP/QMC07R(9007)

[C. Test the Client connection (Setup Method 1)]
5. Use amqsputc to put messages on the Local Queue QL.A on the Server :
 # amqsputc QL.A QMC07R

6. Use amqsbcgc to browse the message on the Server Queue.
 (The value of Reply-to-QMgr in the MQMD will show.)
 # amqsbcgc QL.A QMC07R

7. Use amqsgetc to get the messages from the Server Queue.
 # amqsgetc QL.A QMC07R

[D. Server Queue Manager setup using Auto-Definition of CHANNELs]
8. Enable CHANNEL Auto-Definition in Queue Manager.
 so all teams are able to connect to Queue Manager
 : ALTER QMGR CHAD(ENABLED)

[E. Client Setup (Method 2)]
9. Use QMC07R to build a client CHANNEL definition table to enable a WebSphereMQ
 client to connect to each Queue Manager which has enabled CHANNEL Auto-Definition :
 a. Create 2 client connection CHANNEL entries to connect to QMC07R.

 (On QMC07R)
 : DEF CHL(CLNT_A) CHLTYPE(CLNTCONN) REPLACE +
  TRPTYPE(TCP) CONNAME('QMC07R(9007)') QMNAME(QMC07R)

 : DEF CHL(CLNT_B) CHLTYPE(CLNTCONN) REPLACE +
  TRPTYPE(TCP) CONNAME('QMC07R(9007)') QMNAME(QMC07R)


[F. Test the Client connection (Setup Method 2)] (需安裝MQ Client並設定)
10. On the client system ensure the following environment variables are point to the just
 created client CHANNEL definition table. Be sure to unset the MQSERVER.
 a. MQCHLLIB=
 b. MQCHLTAB=

 [UNIX Systems]
 Default location on the creating Queue Manager :
  export MQCHLLIB=/var/mqm/qmgrs//@ipcc
  export MQCHLTAB=amqclchl.tab
  export MQSERVER=

 [Windows Systems]
  SET MQCHLLIB=..\mqm\qmgrs\\@ipcc
  SET MQCHLTAB=amqclchl.tab
  SET MQSERVER=

11. Use amqsputc again to put a message to QL.A on QMC07R and ensure the
 operation is completed successfully. Verify that the new server connect CHANNEL
 CLNT_A is now defined on QMC07R.
 # amqsputc QL.A QMC07R

12. Stop CHANNEL CLNT_A . Then use amqsputc to put a message to QL.A . Verify
 that the new server connect CHANNEL CLNT_B is now defined on QMC07R, and
 that the message successfully arrived on the Queue.
 # runmqsc QMC07R
 : stop CHANNEL(CLNT_A)

 # amqsputc QL.A QMC07R


======================================================
======================================================
[G. Setup and perform Remote Administration.]
1. This requires that the managing Queue Manager be the default Queue Manager :

2. # runmqsc -w 15

3. : DISPLAY QMGR

 

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月16日 星期日

.
. IBM WebSphere MQ v6.0
. Chapter 6.3 - IBM WebSphere Security
.

=== WebSphere MQ Security Implementations ===
1. Object Authority Manager (OAM) facility.
2. CHANNEL Security using Secure-Sockets-Layer (SSL).

(※ MQ 只有授權Authorization, 沒有認證Authentication)


=== WebSphere MQ Access Control Overview ===
1. WebSphereMQ access control at user and/or group level :
 - UNIX use groups only (Username must exist, everyone is in nobody.)
 - Windows uses userids and/or groups.
 - System-level userids only are supported
  (No support for DCE principals, TXSeries userids, and so forth.)
2. Firsy level name only is controlled :
 - Alias Queues, Remote Queues.
 - Resolved name is not significant.


=== Object Authority Manager Installable Service ===
1. [ WebSphereMQ QMgr <---> Object Authority Manager (OAM) Access Control Lists ]
2. Access Control for WebSphereMQ objects :
 - Queue Manager   - Queues
 - Processes     - Namelists
 - Channels      - Authentication information objects
 - Listeners      - Services
3. OAM can be disabled :
 - Remove entry from mqs.ini or Windows Registry
 - Not recommended
 - Very difficult to re-establish uniform authority checking


=== Object Authority Manager : Access Control Lists ===
1. One authority file per object :
 - lus global permissions files.
2. Each file has one stanza per principle :
 - Principal (User)
 - Authority='bit pattern'
3. Windows OAM bypasses auth files for certain classes of principal
 - SYSTEM, local Administrators group, local mqm group


=== Security Management : setmqaut ===
1. Change the authorizations :
 - Queue Manager   - Queues
 - Processes     - Namelists
 - Channels      - Authentication information objects
 - Listeners      - Services
2. Principal or group level control
3. Granular control of access
 - No generic functions
 - Supports generic profiles

 # setmqaut -m QMgr -t Objtype -n Profile [-p Principale -g Group] permissions
 Example :
 # setmqaut -m QM1 -t queue -n MOON.* -g GP1 browse + get

4. Note that there are certain principals/groups which are granted automatic access to resources. These are :
 - mqm (user/group)
 - For Windows :
  a. Administrator (user/local group)
  b. SYSTEM (userid)
  c. The user (or principal group) which creates a resource.


=== Security Management : dspmqaut ===
1. Display current authorizations :
 - Queue Manager   - Queues
 - Processes     - Namelists
 - Channels      - Authentication information objects
 - Listeners      - Services
2. Principal or group level control.

 # dspmqaut -m QMgr -t ObjType -n ObjName [-p Principal -g Group ]
 Example :
 # dspmqaut -m QM1 -t q -n QL.Q1 -p mquser
 Entity mquser has the following authorizations for object QL.Q1 :
 get
 browse
 put ...


=== Security Managemnet : dmpmqaut ===
1. Dump current authorizations :
 - QMGR
 - Queues
 - Processes
 - Namelists
 - Authinfo (SSL CHANNEL Security)
 - Channels
 - Listeners
 - Services
2. Principal or group level control.

 # dmpmqaut -m QMgr -t ObjType -n Profile [-p Principal -g Group ]
 Example :
 # dmpmqaut -m QM1 -n a.b.c -t q -p mquser
 The resulting dump would display :
 profile : a.b.*
 object type : queue
 entity : user1
 type : principal
 authority : get, browse, put, inq


=== Access Control for WebSphereMQ Control Program ===
1. Most WebSphereMQ control programs
 - Such as crtmqm, strmqm, runmqsc, setmqaut, dspmqaut, dmpmqaut
2. Have restricted access :
 - UNIX/Linux restricts users to the mqm group
  a. Configuration as a part of WebSphereMQ installation.
  b. Control imposed by the O.S. not OAM.
 - Windows allows :
  a. mqm group
  b. Administrators group
  c. System userid
 - OpenVMS restricts users to those granted the MQM identifier.
 - Compaq NSK allows :
  a. MQM group
  b. SUPER.SUPER ID


=== Authority Checking in the MQI ===
1. MQI calls with security checking :
 - MQCONN / MQCONNX
 - MQOPEN
 - MQPUT1 (implicit MQOPEN)
 - MQCLOSE  (For Dynamic Queues).
2. WebSphereMQ events as audit records :
 - Events written to SYSTEM.ADMIN.QMGR.EVENT Queue.
 - Documented in Monitoring WebSphereMQ manual.
3. Reason code MQRC_NOT_AUTHORIZED (2035) returned if not authorized.
4. The MQCLOSE is generally not checked because the close options are usually none.
5. If the close options are set to MQCO_DELETE or MQCO_DELETE_PURGE (this is only for permanent
  Dynamic Queues) then, unless the Queue was created using the current handle, there is a check to
 determine if the user is authorized to delete the Queue.


=== Security and Distributed Queuing === ☆
1. Put authority :
 - Option for the receiving end of a message CHANNEL.
  a. Default user identifier is used.
  b. Context user identifier is used.
2. Transmission Queue :
 - Messages destined for a Remote Queue Manager are put on a Transmission Queue by the
  Local Queue manager
  a. An application should not notmally need to put messages directly on a Transmission Queue,
   or need authority to do so.
 - Only special system programs should put messages directly on a Transmission Queue should
  have the authority to do so.

=== Message Context ===
1. Information about source of message :
 - Identity section (user related)
 - origin section (program related)
2. Part of message Descriptor.
3. Can be passwd in related message.
4. Message context information allows for the application that retrieves a message to find out about
 the Originator of the message.The retrieving application may want to :
 a. Check that the sending application has the corrent level of authority.
 b. Keep an audit of all the messages it has worked with.
 c. The information is held in two field : Identify context and Origin context.


=== The Context Fields ===
An application can request the Queue Manager to set the context fields of a message by using the put message option MQPMO_DEFAULT_CONTEXT on an MQPUT or MQPUT1 call. This is the default action if no context if specified.

( ps : 用 # amqsbcg Queue QMgr 可以看到 )

1. Identify context :
 - UserIdentifier (user that originated the message.)
 - AccountingToken
  a. Windows (SID, Security ID in compressed format)
  b. i5/OS (Job accounting code)
  c. UNIX (Numberic user ID in ASCII characters)
 - ApplIdentityData (Blank)
2. Orign context :
 - PutApplType (MQAT_AIX, MQAT_CICS...etc.)
 - PutApplName
 - PutDate ( YYYYMMDD(GMT) )
 - PutTime ( HHMMSSTH(GMT) )
 - ApplOriginData (Blank)


=== No Context ===
1. Requested by a put message option :
 - MQPMO_NO_CONTEXT
 - Queue Manager clears all the context fields, specifically.
 - PutApplType is set to MQAT_NO_CONTEXT
2. To request "Default Context" or "No Context" requires no more authority than that required to put the message on the Queue.


=== Passing Context ===
A → [Queue1] → B → [Queue2] → C

1. Put messages on Queue2 with same Identity context as message taken from Queue1
2. Open Queue1 as "Save All Context"
3. Put messages with "Pass Identity Context"
4. Or transfer "No Context"


=== Alternate User Authority ===
A → [Queue1] → B → [Queue2] → C

1. Put messages with A's authority :
 - B needs appropriate authority.
 - UserID taken from message Context.
2. How it is requested ? :
 - AlternateUserID field in Object Descriptor.
 - Option on MQOPEN or MQPUT1


=== Setting Context ===
1. Two open options that require authority to use :
 - MQOO_SET_IDENTITY_CONTEXT
 - MQOO_SET_ALL_CONTEXT
2. Two corresponding put message options :
 - MQPMO_SET_IDENTITY_CONTEXT
 - MQPMO_SET_ALL_CONTEXT
3. Normally used by special programs only :
 - Message CHANNEL agents
 - System utilities


=== CHANNEL Exit Programs ===
MQPUT → TransmissionQueue → [Message] → MCA → Send →
                     
MQGET ← DestinationQueue ← [Message(retry)] ← MCA ← Receive ←
                     
                     

1. The uses of CHANNEL Exit programs are :
 - Auto-definition Exit can be used to modify the CHANNEL definition derived from
         the model SYSTEM.AUTO.RECEIVER
 - Security Exit is primarily used by the MCA at each end of a message CHANNEL
         to authenticate its partner.
 - Send and Receiver Exites can be used for purposes such as data compression
         / decompression and data encryption / decryption.
 - Message Exit can be used for any purpose which makes sense at the message
         level. The following are some examples :
     a. Application data conversion
     b. Encryption / decryption
     c. Journaling (日誌)
     d. Additional security checks such as validating an incoming user identifier.
     e. Substitution of one user identifier for another as a message enters a new
      security domain.
     f. Reference message handing.
 - Message-retry Exit is called an attempt to open a destination Queue, or put a
          message on a destination Queue, has been unsuccessful. The
          exit can be used to determine under what circumstances the
          MCA should continue to retry, how many times it should retry,
          and how frequently.
2. The Auto-Definition Exit is only supported on WebSphereMQ for AIX. HP-UX, iSeries,
 Solaris, and Windows, and MQSeries for Compaq Tru64 UNIX and OS/2 Warp V5.1


=== CHANNEL Exit Programs on MQI CHANNELs ===
                        [Auto-Definition]
          [Security]          [Security]
 MQCONN ←→        Send Receive
 MQOPEN ←→ CLNTCONN ←——————→ SVRCONN
  MQPUT ←→ 

1. No CHANNEL Exit Programs can be called on a client system if the MQSERVER
 environment variable is used to define a simple client conenction.
2. The Auto-Definiition Exit can be used to modify the CHANNEL definition derived
 from the model SYSTEM.AUTO.SVRCONN


=== Secure Sockets Layer ===
1. Protocol to allow transmission of secure data over an insecure network.
2. Combines these techniques :
 - Symmetric / Secret Key encryption
 - Asymmetric / Public Key encryption
 - Digital Signature
 - Digital Certificates
3. Protection :
 - Client / Server
 - Qmgr / QMgr CHANNELs
4. To combat Security Problems :
 - Eavesdropping (竊聽) ← Encryption techniques
 - Tampering (竄改、瞎搞) ← Digital Signature
 - Impersonation (偽裝) ← Digital Certificates


=== QMGR Attributes for SSL ===
1. ALTER QMGR command :
 - SSLKEYR  Sets the SSLKeyRepository.
 - SSLCRLNL  Sets the SSLCRLNamelist.
 - SSLCRYP  Sets the SSLCryptoHardware.
 - SSLTAKS  Sets the SSLTasks.
 - SSLEV   Enables or Disables SSL event messages.
 - SSLFIPS  Specifies if only FIPS-certified algorithms can be used.

ps : CRL (Certificate Re )

=== QMGR Authentication Object ===
1. ALTER AUTHINFO
2. DEFINE AUTHINFO
3. DELETE AUTHINFO
4. DISPLAY AUTHINFO


=== Channel Attributes for SSL ===
1. DEFINE or ALTER CHANNEL
 - SSLCIPH (Cipher 譯文)
 - SSLPEER
 - SSLCAUTH


=== Access Control for a WebSphereMQ Client ===
1. Access control is based on a user ID used by the server connection process :
 - Value of MCAUserIdentifier in MQCD determines this user ID
2. Security Exits at both ends of the MQI CHANNEL :
 - Client Security Exit can flow a user ID and password
 - Server Security Exit can authenticate the user ID and set MCAUserIdentifier
3. No security Exit at the client end of the MQI CHANNEL :
 - Value of logged_in USERID flows to the server system.
 - Server Secutiry Exit can authenticate the user ID and set MCAUserIdentifier
4. No Security Exit at either end of the MQI CHANNEL :
 - MCAUserIdentifier has the value of MCAUSER if it is nonblank.
 - MCAUserIdentifier has the value of flowed user ID otherwise.


=== Remote Queuing and Clients ===
1. CHANNEL Exits :
 - A number of CHANNEL Exits are available in the product and as SupportPacs
 - Serveral vendors in this market too.
2. MCAUSER :
 - The default setting is wide open, especially for client attach.
 - May want to set this to restrict who can access your Queue Manager.
3. MQ_USER_ID environment variable :
 - This war removed for WindowsNY and UNIX in the 5.1 release client env.
 - The logged-in username is now automatically used.
 - But this is not authenticated at the server ; you may still need security Exits.

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月16日 星期日

.
. IBM WebSphere MQ v6.0
. Chapter 6.2 - IBMWebSphere MQ Clients
.

=== WebSphere MQ Client ===
 ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
  Client-System      Server-System
 WMQ-Application      WMQ-Queue-Manager
 Client-Connection      Server-Connection
 Communications-stack→→→Communications-stack
         MQI-CHANNEL
 ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
1. Assured delivery.
2. Queue storage.
3. Data conversion.
4. Administration.
5. Recovery.
6. Syncpoint control.


=== MQI Clients Explained ===
1. The full range of MQI calls and options is available to a WebSphereMQ client
 application, including the following :
 - The use of MQGMO_CONVERT option on the MQGET call. This causes the
  application data of the message to be converted into the numberic and
  character representation in use on the client system. The server Queue
  Manager provides the usual level of support to do this.
 - A client application may be connected to more than one Queue Manager
  simultaneously. Each MQCONN call to different Queue Manager returns a
  different connection handle. This does not apply if the application is not
  running as a WebSphereMQ client.
2. The MQI stub which is linked with an application when running as a client is
  different from that used when the application is not running as client. An
  application will receive the reason code MQRC_Q_MGR_NOT_AVAILABLE
  on an MQCONN call if it is linked with the wrong MQI stub.

 ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
 1. MQCONN ---> (Queue Manager)
  2. QMOPEN ---> (Queue)
   3. MQPUT / MQGET / MQINQ / MQSET

  MQBEGIN
   MQPUT / MQGET
   IF successful -> MQCMIT
   ELSE MQBACK

  4. MQCLOSE ---> (Queue)
 5.MQDISC ---> (Queue Manager)

 ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆


=== Syncpoint Control on a Base Client ===
1. A WebSphere MQ client application may participate in a Local unit of work
 involving MQSeries resources.
 - Uses the MQCMIT and MQBACK calls for this purpose.
2. A WebSphere MQ client application cannot participate in a Global unit of
 work involving WebSphereMQ resources.


=== Extended Transactional Client ===
1. An Extended Transactional Client can participate in a Global unit of work :
 - Transaction manager runs on client system.
 - Transaction manager provides syncpoint processing.

=== MQ Client Installation ===
(略)


=== Defining an MQI CHANNEL === (MQ Client CHANNEL)
1. Use the DEFINE CHANNEL command with parameters :
 - CHLTYPE  CLNTCONN or SVRCONN (SVRCONN為client專用)
 - TRPTYPE  DECNET, LU62, NETBIOS, SPX or TCP.
 - CONNAME(string)  For a client connection only.
 - QMNAME(string)  For a client connection only.
2. No operational involvement on an MQI CHANNEL :
 - An MQI CHANNEL starts when a client application issues MQCONN
  (or MQCONNX)
 - An MQI CHANNEL stops when a client application issues MQDISC
3. Do not forget to configure and refresh the inet daemon, or to start the
 WebSphereMQ Listener, on the server system.


=== Two ways of Configuring an MQI CHANNEL ===
1. Method_1 :
 - On the server system, define a server connection.
 - On the client system, set the environment variable.
 - MQSERVER=ChannelName/TransportType/ConnectionName

 (Windows : SET MQSERVER=VENUS.SVR/TCP/hostname(port) )
 (UNIX : export MQSERVER=VENUS.SVR/TCP/hostname(port) )

2. Method_2 :
 - On the server system, define a client connection and a server conection.
 -If not on a file server, copy the client CHANNEL definition talbe from the server
  system to the client system.
 - On the client system, set the environment variables :
  a. MQCHLLIB= 
   Path to the directory containing the client CHANNEL difinition table.
  b. MQCHLTAB=
   Name of the file containing the client CHANNEL definition table.

  (Windows : SET MQCHLIB=C:\MQM
        SET MQCHTAB=AMQCLCHL.TAB
  (UNIX : export MQCHLIB=/mqmtop/qmgrs/QUEUEMANAGERNAME/@ipcc
      export MQCHLTAB=AMQCLCHL.TAB )


=== Auto-Definition of CHANNELs ===
1. Applies only to the end of a CHANNEL with type :
 - Receiver
 - Server connection
2. Function invoked when an incoming request is received to start a CHANNEL
 but there is no CHANNEL definition.
3. CHANNEL definition is created automatically using the model :
 - SYSTEM.AUTO.RECEIVER
 - SYSTEM.AUTO.SVRCONN
4. Partner's values are used for :
 - CHANNEL name.
 - Sequence number wrap value.
5. To enable the automatic definition of CHANNELs, the attribute ChannelAutoDef
 of the Queue Manager object must be set to MQCHAD_ENABLED.
 The Corresponding parameter on the ALTER QMGR command is CHAD(ENABLED)
6. CHANNEL auto-definition events can be enabled by setting attribute ChannelAutoDefEvent
 of the Queue Manager object must be set to MQCEVR_ENABLED.
 The Corresponding parameter on the ALTER QMGR command is CHADEV(ENABLED)


=== Let Queue Manager accessed by MQ Explorer ===
(☆☆☆ by AaA ☆☆☆)
1. SYSTEM.ADMIN.SVRCONN (Windows default, UNIX/Linux need to add manualy)
2. # runmqsc QM1
  : DIS CHANNEL(SYSTEM.ADMIN.SVRCONN)
  : ALTER CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('mqm')
  (MCAUSER原本空白,表示檢查UserID/Group。 而指定mqm表示連上來ㄉ,都自動以mqm登入)

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月16日 星期日

.
. IBM WebSphere MQ v6.0
. Chapter 6.1 - WebSphereMQ Family SupportPacs
.

=== WebSphereMQ Family SupportPacs ===
http://www.ibm.com/software/integration/support/supportpacs

1. MO01 ( Event and Dead Letter Queue Monitor ) :
 This SupportPac is the MQSeries Event queue monitor, Dead Letter queue monitor and Expired message remover for Windows, Java, OS/2 and AIX.

2. MS03 (Save Queue Manager object definitions using PCFs (saveqmgr) ) :
 This SupportPac (saveqmgr) saves all the objects, such as queues, channels, etc, defined in a either local or remote queue manager to a file.

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月15日 星期六
 

.
.讓我們來練習一下 Queue Manager Clusters
.

=== Exercise 5 : Queue Manager Clusters ===
What we will do :
A. Create Clusters.
B. Define all required WebSphereMQ objects for Queue Manager Clusters.
C. Test and Configure Clusters.
D. Manage workload in Clusters.

======================================================
[QM1]————————————
 ∣Cluster Transmission Queue∣
 ∣       [ Cluster-Sender CHANNEL ] →→ [QM3]
 ∣Local Appication Queues  ∣          ↙
 ∣            ∣    [QM2]  ↙
 ∣Cluster Command Queue ∣   ↙     ↙
 ∣        [ Cluster-Receiver CHANNEL ][QM4]
 ∣Cluster Repository Q   ∣
  —————————————


======================================================
[A. Set up the Cluster connections.]
1. Create a new default Queue Manager QM1 to be used in a Queue Manager Cluster.
 # crtmqm -q QM1   (-q : 為 default QM)
 # crtmqm QM3
 
2. Start the Queue Manager :
 # strmqm QM1
 # strmqm QM3
 
3. Start the Listener function for your Queue Manager QM1 on port 9051
  using the WebSphereMQ Listener.
 # runmqlsr -m QM1 -t tcp -p 9051
 # runmqlsr -m QM3 -t tcp -p 9053
 
4. Define the Cluster connection objects required for your Queue Manager.
  The Objects needed should include the following :
 a. One Local Queue to be used as Dead Letter Queue.
   # runmqsc QM1
   # runmqsc QM3
   : DEF QL(DLQ)
   : ALTER QMGR DEADQ(DLQ)
   : DIS QMGR DEADQ   (驗證Dead Letter Queue)
 b. One Cluster Receiver CHANNEL (CLUSRVR) pointing to the owning QM.
  (On Every Queue Manager in Cluster)
  ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
  DEF CHL(TO.CLUS_A9.QM#) CHLTYPE(CLUSRCVR) REPLACE +
   TRPTYPE(TCP) CONNAME('Hostname(905#)') +
   SHORTRTY(600) SHORTTMR(60) DISCINT(30) CLUSTER(CLUS_A9)

  ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
  ( # = your QM in Cluster , 這邊先在 QM1 設接收端)
  DEF CHL(TO.CLUS_A9.QM1) CHLTYPE(CLUSRCVR) REPLACE +
   TRPTYPE(TCP) CONNAME('localhost(9051)') +
   SHORTRTY(600) SHORTTMR(60) DISCINT(30) CLUSTER(CLUS_A9)
   ( ps : 其實在這邊一執行, 在MQ Explorer就會出現CLUS_A9)

  ( # = your QM in Cluster , 另一個在 QM3 設接收端)
  DEF CHL(TO.CLUS_A9.QM3) CHLTYPE(CLUSRCVR) REPLACE +
   TRPTYPE(TCP) CONNAME('localhost(9053)') +
   SHORTRTY(600) SHORTTMR(60) DISCINT(30) CLUSTER(CLUS_A9)

 c. One Cluster Sender CHANNEL pointing to a (the other) Repository
  Queue Manager in your Cluster.
  ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
  DEF CHL(TO.CLUS_A9.QM*) CHLTYPE(CLUSSDR) REPLACE +
   TRPTYPE(TCP) CONNAME('Hostname(905*)') +
   SHORTRTY(600) SHORTTMR(60) DISCINT(30) CLUSTER(CLUS_A9)

  ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

  ( * = Full Repository , 這邊在在 QM3 送出)
  DEF CHL(TO.CLUS_A9.QM1) CHLTYPE(CLUSSDR) REPLACE +
   TRPTYPE(TCP) CONNAME('localhost(9051)') +
   SHORTRTY(600) SHORTTMR(60) DISCINT(30) CLUSTER(CLUS_A9)


  ( * = Full Repository , 另一個 QM1 送出)
  DEF CHL(TO.CLUS_A9.QM3) CHLTYPE(CLUSSDR) REPLACE +
   TRPTYPE(TCP) CONNAME('localhost(9053)') +
   SHORTRTY(600) SHORTTMR(60) DISCINT(30) CLUSTER(CLUS_A9)

 d. If your Queue Manager is to be a Full Repository,
  ALTER the Queue Manager to include the Cluster name.
   ALTER QMGR REPOS(CLUS_A9)   (要加入Cluster的QM則執行)

  (ps : 這邊也是,可以Check一下,CLUS_A9完整生出來了... lol )
   Verify on QM1 => DIS CLUSQMGR(*)
   Verify on QM1 => DIS CHSTATUS(*)

   Verify on QM1 => PING CHL(TO.CLUS_A9.QM3)
   Verify on QM3 => PING CHL(TO.CLUS_A9.QM1)
  ( 成功的話, => AMQ8020: 連通測試 WebSphere MQ 通道完成。)
  ( 失敗的話, => AMQ9547: 遠端通道的類型不適合所要求的動作。 )
 AMQ9547 : Type of remote channel not suitable for action
 Cause :
  Its is not possible to start a Cluster Receiver CHANNEL that uses the group Listener port.
 Solution :
  Start a non-shared Listener (INDISP(QMGR)) and ALTER the Cluster Receiver CHANNEL to
  use its port number rather than the group Listener port.

5. Wait until all CHANNELs timed out upon the DISCINT value.
 
6. What is the CURDEPTH on the SYSTEM.CLUSTER.REPOSITORY.QUEUE ?
 DIS Q(SYSTEM.CLUSTER.REPOSITORY.QUEUE) CURDEPTH
 
[B. Set up the Cluster application objects.]
7. Define the Cluster application objects required on your Queue Manager.
 Define all Queues with DEFPSIST(YES) and for all Cluster Queue DEFBIND(OPEN).
 a. Two or more Local Cluster Queue QL.C#
  (exist in more then one Queue Manager = multi instance Q)

 (On QM1 or QM3, 我們先在 QM1 上 DEF 測試一下)
 DEF QL(QL.C1) REPLACE DEFPSIST(YES) DEFBIND(OPEN) CLUSTER(CLUS_A9)

8. Wait until all CHANNELs timed out unpon the DISCINT value.

9. What is now the CURDEPTH on the SYSTEM.CLUSTER.REPOSITORY.QUEUE ?
 DIS Q(SYSTEM.CLUSTER.REPOSITORY.QUEUE) CURDEPTH

[C. Test Clustering.]
10. Prepare a text file with 9 messages.
  Each message should contain a sequence number.
  Use this text file in the following steps with amqsput via standard input.

 Example :
 0001 MSG msg text1............
 0002 MSG msg text22...........
 0003 MSG msg text333..........
 0004 MSG msg text4............
 0005 MSG msg text55...........
 0006 MSG msg text666..........
 0007 MSG msg text7............
 0008 MSG msg text88...........
 0009 MSG msg text999..........


11. From the non-repository Queue Manager, run amqsput to put messages to the
 Cluster Queue that is not defined on that Queue Manager.
 Check which Queue and Queue Manager the messages arrive on.
 a. QL.C# (Cluster Queue)
  # amqsput QL.C1 QM3
  - All messages are put again on one instance of Queue.
  - CHANNEL activity to full repository and to QM where messages are put.
 
12. Set DEFBIND(NOTFIXED) for all Cluster Queues on all Queue Managers in your Cluster.
 Is there any CHANNEL activity in the whole Cluster ?
 - ALTER QL(QL.C1) DEFBIND(NOTFIXED)
or - DEF QL(QL.C1) REPLACE DEFPSIST(YES) DEFBIND(NOTFIXED) CLUSTER(CLUS_A9)
 - Yes, because the change of the DEFBIND attribute has to be communicated.

13. On which instances of the destination Queue do the messages arrive ?
 Is there any CHANNEL activity ?
 - The messages are now distributed between all instances of the Queue QL.C# (Round Robin)
 - Because of remote operations we have CHANNEL activity.

14. Stop one of the Remote Cluster Queue Managers.

15. Again put 9 messages to the Cluster Queue that is not Local on your Queue Manager.
 - the messages are now put to the remaining instances of the Queue QL.C#

16. Restart the previously stopped Cluster Queue Manager.

17. Disable puts on all Queue instances of QL.C# in your Cluster.

18. Again put 9 messages to QL.C#

19. Explain the error indication you get :
 - Reason Code 2268 is returned to the putting application.
  The status PUT(DISABLED) is also know on the Local Queue Manager even all
  instances are located on Remote QMGR in the Cluster.
 - The Cluster Queue entry in the Local Queue Manager is holding this information.
 - DIS Q(QL.C*) CLUSINFO ALL


Full Repository : is a Queue Manager that hosts a complete set of information about every Queue Manager in the cluster.

Partial Repositories : are other Queue Managers in the cluster [that] inquire about the information in the full repositories and build up their own subsets of this information.

※ If MQ Cluster configured with only one Full Repository, it has a single point of failure. The Cluster won't function if that Full Repository goes down. Otherwise, by using multiple Full Repositories, if one Full Repository goes down, the other Full Repositories will take over to manage the Cluster.

※ Each Queue Manager should have at least one Cluster-Sender CHANNEL (CLUSSDR) and one Cluster-Receiver CHANNEL (CLUSRCVR), regardless if the Queue Manager is a full or a partial repository. The only exception to this is for MQ Clusters with only one full repository. This full repository should only have a Cluster-Receiver CHANNEL (CLUSRCVR).

※ A Full Repository pushes its information via a Cluster-Sender CHANNEL (CLUSSDR) to another full repository's Cluster-Receiver CHANNEL (CLUSRCVR). These two CHANNELs should have the same name.


=== Set MQ Cluster Using IBM WebSphereMQ Explorer ===
(E1) Queue Manager Clusters :
 http://publibfp.boulder.ibm.com/epubs/pdf/csqzah07.pdf

(E2) Configuring WebSphereMQ Cluster :

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月15日 星期六

.
. IBM WebSphere MQ v6.0
. Chapter 5.3 IBMWebSphereMQ Clusters
.

=== What is a MQ Cluster ? ===
1. A Cluster is a collection of Queue Managers that may be on different platforms,
 but typically serve a common application.
2. Every Queue Manager can make the Queues that they host available to every
 other Queue Manager in the Cluster, without the need (Remote) Queue definitions.
3. Cluster specific objects remove the need for explicit CHANNEL definitions and
 Transmission Queues for each destination Queue Manager.
4. The Queue Managers in a Cluster will often take on the role of a client or a server.
 The servers will host the Queues that are available to the members of the Cluster,
 also running applications that process these messages and generate responses.
 The clients PUT messages to the servers Queues and may receive back response messages.
5. Queue Managers in a Cluster will normally communicate directly with each other,
 although typically, many of the client sysetms will never have a need to communicate
 with other client systems.


=== Cluster Support Objects ===

======================================================
[QM1]————————————
 ∣Cluster Transmission Queue∣
 ∣       [ Cluster-Sender CHANNEL ] →→ [QM3]
 ∣Local Appication Queues  ∣          ↙
 ∣            ∣    [QM2]  ↙
 ∣Cluster Command Queue ∣   ↙     ↙
 ∣        [ Cluster-Receiver CHANNEL ][QM4]
 ∣Cluster Repository Q   ∣
  —————————————

======================================================

1. Cluster Repository (Queue) :
 - A collection of information about the Queue Managers that are members of a Cluster,
  including Queue Manager names, their CHANNELs, the Queues they host and so forth.
 - This repository information is exchanged through messages sent to a Queue called
  SYSTEM.CLUSTER.COMMAND.QUEUE and stored on a Queue with the fixed name
  SYSTEM.CLUSTER.REPOSITORY.QUEUE
 - Repositories may be full or partial - more about this on the next visual. Each Cluster
  Queue Manager must have at least one connection to another Queue Manager that
  owns a full repository.

2. Cluster-Sender CHANNEL :
 - A CHANNEL definition of the TYPE(CLUSSDR) on which a Cluster Queue Manager can
  send messages to another Queue Manager in the Cluster that holds a full repository.
  This CHANNEL is used to notify the repository of any changes of the Queue Manager's
  status, for example the addition or removal of a Queue. It is only used for the initial contact
  with the first full repository Queue Manager. From this one the Local Queue Manager learns
  whatever it needs to know.
 - Note : Application messages will be sent by auto-defined sender CHANNELs that are
  created during operation based on repository information from other Cluster Queue Managers

3. Cluster-Receiver CHANNEL :
 - A CHANNEL definition of the TYPE(CLUSRCVR) on which a Cluster Queue Manager can
  receive messages from within the Cluster. Though the definition of this object a
  Queue Manager is advertised to the other Queue Managers in the Cluster, thus enabling
  them to auto-define their appropriate CLUSSDR CHANNELs for this Queue Manager.
 - You need at least one Cluster-Receiver CHANNEL for each Cluster Queue Manager.

4. Cluster Transmission Queue :
 - All the messages from the Queue Manager to any other Queue Manager in the Cluster
  are locally put to this Queue named SYSTEM.CLUSTER.TRANSMIT.QUEUE
 - It must exist in each Cluster Queue Manager

5. Cluster Queue :
 - A Cluster Queue is a Queue that is hosted by a Cluster Queue Manager and made available
  to Queue Managers in the Cluster. The Local Queue is either preexisting or created on the
  Local Queue Manager and to play a role in the Cluster the Local Queue definition specifies
  the Cluster name of the definition. The other Queue Managers can see this Queue and use
  it to put messages to it without the use of Remote Queue definition. The Cluster can be
  advertised in more than one Cluster.


=== More About Repositories ===
1. Each Cluster Queue Manager has to have a Local Queue called
 SYSTEM.CLUSTER.REPOSITORY.QUEUE where all Cluster related information is stored.
2. At least one (but for availability reasons preferably 2 or more) Cluster Queue Managers have
 to hold full repositories; that means a complete set of information about every
 Queue Manager in the Cluster.
3. For each Cluster Queue Manager, a Cluster-Sender CHANNEL has to be predefined that
 connects to one of the repository Queue Managers.
4. Repository Queue Managers (sometimes simply called repositories) must be fully
 interconnected with each other and positioned in the network so as to give a
 high level of availability.
5. Normal Queue Managers build up and maintain a partial repository that contains information
 about those Queue Managers and Queue that are of iterest to it. This information may be
 updated and extended during operation through inquirles of a full repository.

※ 每個 Cluster 至少兩個 Queue Manager.
※ 每個 Cluster 至少兩個 Full Repository.
※ 一個 QM 只能擔任某一個 Cluster 的 Fully Repository.

※ 當用 MQ-Explorer ---> Cluster-Receiver CHANNEL connection name : hostname(1414)


=== Setting Up a Cluster ===
1. QM1 is made a full repository Queue Manager for the Cluster named CLUS_A3 :
 ALTER QMGR REPOS(CLUS_A3)
 
 DEFINE CHANNEL(TO.QM1) +
  CHLTYPE(CLUSRCVR) CONNAME(...) +
  CLUSTER(CLUS_A3) DESCR('To other Repository')

 
 DEFINE QLOCAL(QUEUE1) CLUSTER(CLUS_A3)

2. A Queue Manager may be associated to more than one Cluster at time.
 The same is true for Queues and CHANNELs :
 - In this case a NAMELIST object has to be created with multiple Cluster names as
  single entries.
 - Then with all DEFINE commands , the name of this namelist has to be referenced
  instead of the Cluster name, and the REPOS attribute of the ALTER QMGR comand
  changes to REPONL.


=== WorkLoad Balancing Attributes === (CLWL)

CLUSTER "CLUS_A3"
==========================================================================
 MQOPEN QNAME(TARGET.Q)
  ↓        ↗ [QM2 ] TARGET.Q ↘
 [ QM1 ] →CLW EXIT → [ QM3 ] TARGET.Q → DEF QL(TARGET.Q) CLUSTER(CLUS_A3)
           ↘ [QM4 ] TARGET.Q ↗
 ALTER QMGR CLWEXIT(myexit)
==========================================================================

1. Queue attributes :
 - CLWLPRTY  (Cluster WorkLoad priority)
 - CLWLUSEQ  (use Local Queue)

2. Queue Manager attributes :
 - CLWLUSEQ  (use Local Queue)

3. CHANNEL attributes :
 - CLWLPRTY  (priority)
 - CLWLWGHT  (weight to a CHANNEL, 1 ~ 99)
 - NETPRTY   (network priority)


=== Continuous Operations ===
1. MQOPEN(TARGET.Q) MQOO_BIND_NOT_FIXED, MQPUT , MQPUT ... MQPUT
MQOO_BIND_NOT_FIXED 才能 Load Balance, 若是 On Open 就只會固定送到某QM

2. The Queue Attribute DEFBIND determaines whether or not rerouting will be performed
 while a Queue is opened.
 - DEFBIND(NOTFIXED) with a round-robin distribution of messages to all TARGER.Qs
  in the Cluster.
 - DEFBIND(OPEN) the destination Q is selected at MQOPEN time and will not be
  changed until MQCLOSE.


=== Cluster Related Queue Manager Attributes ===
1. REPOS(ClusterName)
2. REPOSNL(NamelistName)
3. CLWLDATA(32 char max string)
4. CLWLEXIT(Cluster WorkLoad exit name)
5. CLWLLEN(max # of bytes of message data passwd to Cluster WorkLoad exit)


=== Controlling Clusters - Cluster Commands ===
1. SUSPEND QMGR - Removes a QM from a Cluster temporarily.
2. RESUME QMGR - Reinstates a SUSPENDed QM.
3. REFRESH CLUSTER(clustername) - 強制讓Cluster Sync一次.
4. RESET CLUSTER(clustername)  - QM退出, 當亂掉時, 清除用
5. RESET CLUSTER(clustername)
  QMNAME(
QMname) ACTION(FORCEREMOVE) QUEUES(NO)
6. RESET CLUSTER(clustername)
  QMID(
QMid) ACTION(FORCEREMOVE) QUEUES(NO)



=== Controlling Clusters - DISPLAY CLUSQMGR ===
1. DISPLAY CLUSQMGR(*) CLUSTER(name) CHANNEL(name)
returns :
 CLUSDATE / CLUSTIME
  - the date and time when the Definition became available to the Local QMGR.
 DEFTYPE - how the luster QMGR was defined.
 QMTYPE - function of QMGR in Cluster, provides FULL or PARTIAL repository service.
 QMID - internalygenerated unique QMGR name.
 STATUS - the current status of CHANNEL for QMGR.
 SUSPEND - yes or no as a result of a SUSPEND QMGR cmd.

2. The DISPLAY CLUSMGR command returns cluster information about Queue Manager
 in a Cluster which is stored in the Local SYSTEM.CLUSTER.REPOSITORY.QUEUE
Definition Type may be :
 CLUSSDR - as a Cluster-Sender CHANNEL from an explicit definition.
 CLUSSDRA - as a Cluster-Sender by auto-definition.
 CLUSSDRB - as a Ckuster-Sender CHANNEL, both from an explicit definition
        and by auto-definition.
 CLUSRCVR - as a Cluster-Receiver CHANNEL.


=== Cluster Related Queue Considerations ===
1. Special DISPLAY option :
 DISPLAY QUEUE CLUSINFO
2. Cluster Alias Queue :
 DEF QA(PUBLIC) TARGET(LOCAL.Q) CLUSTER(ITALY)
3. Cluster Queue Manager Aliases :
 DEF QR(ROME) RNAME() RQMNAME(PISA) XMITQ(XQ) CLUSTER(ITALY)

4. Most types of Queues may be defined as Cluster Queues, and as a consequence,
 be advertised to all Queue Managers in the Cluster, just as for Local Queues.
 - Alias Queues may be made available to the Cluster simply by adding
         the CLUSTER keyword to the definition.
 - Queue Manager Aliases advertised to the Cluster may be of the same value as
         for traditional distributed Queueing.
 - Remote Queues are not intend to be advertised to a Cluster, because one of the
         benefits of Clusters is that Remote Queue definitions are no loger
         required. Remote Queues, however, can have a Cluster attribute.
         They can be used to attach a Queue Manager that does not
         support clusting.
 - Model Queues (and hence Temporary Dynamic Queues) cannot have a Cluster
         attribute.

5. Effect of ALTERing Queue definitions :
 - ALTER QUEUE(XXX) PUT(INHIBITED)
  will stop messages being put to that instance of a Queue and also mark it as being
  put inhibited throughout the Cluster. If applicable, this will cause messages to be
  sent to other instances of the queue.
 - ALTER QUEUE(XXX) CLUSTER(' ')
  will take a Queue out of its Clusters and stop other Queue Managers from sending
  messages to it but still allow messages to be put to it from the Local Queue Manager.

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月15日 星期六
 

.
. IBM WebSphere MQ v6.0
. Ex 4 - IBM WebSphere MQ Distributed Queueing.
. 讓我們來練習一下 Distributed Queueing.
. 兩個Queue Managers之間的連接
.
=== Exercise 4 : Distributed Queuing ===
What we will do :
A. Create the objects, required for Distributed Queue.
B. Configure and refresh the inet daemon.
C. Start message CHANNELs manually.
D. Create the required application objects.
E. Test the message flow using sample applications.
F'. Use Triggering in a distributed environment.
G'. Use the CHANNEL Initiator to start messages.

======================================================
[A. Create and configure the required connection objects.]
1. Use for the exercise again the Queue manager with circular logging.
 # crtmqm QMC01  (Local Qmgr , 送端SDR)
 # crtmqm QMC02  (Remote Qmgr , 接收端RCVR)
 
 # strmqm QMC01
 # strmqm QMC02

2. Be sure that NO CHANNEL Initiator (runmqchi) is running.

3. Define the WebSphereMQ objects required for a connection between your
 Local Queue Manager and the Queue Manager of your partner team.

 The necessary objects are following :
 a. A definition of a message CHANNEL (type=Sender)
  - Channel name = QMC01.TO.QMC02
  - Protocol = TCP/IP
  - Network address = 'Host2(9002)'
  - Transmission Queue name = name of the Remote QMGR
   # runmqsc QMC01
   DEF CHL(QMC01.TO.QMC02) CHLTYPE(SDR) REPLACE +
    TRPTYPE(TCP) CONNAME(
'Host2(9002)') XMITQ(XQMC02)

   Check => DISPLAY CHSTATUS(QMC01.TO.QMC02)
 b. A definition of a message CHANNEL (type=Receiver)
  The attribute should match to sender CHANNEL of the partner team.
   # runmqsc QMC02
   DEF CHL(QMC01.TO.QMC02) CHLTYPE(RCVR) REPLACE TRPTYPE(TCP)
   ps : 原講義這邊寫 QMC02.TO.QMC01 是不對的,應該要一致才行。 囧rz
 c. A Transmission Queue with the same name as the Remote Queue Manager (QMC02).
   DEF QL(XQMC02) REPLACE USAGE(XMITQ)
 d. A Dead Letter Queue named DLQ :
   DEF QL(DLQ) REPLACE
 e. Change the Queue Manager to use the Dead Letter Queue :
   ALTER QMGR DEADQ(DLQ)

4. Use runmqsc to create the WebSphereMQ objects. (cont.)

[B. Configure and activate the required TCP Listener function.]
5. Start the Listener Listening on 9002.
 # runmqlsr -m QMC02 -t TCP -p 9002

[C. Test and Start the connection.]
6. Ping the message CHANNEL from the sender end to test the CHANNEL definitions.
  # runmqsc QMC01
  PING CHL(QMC01.TO.QMC02)
  ( 成功的話, => AMQ8020: 連通測試 WebSphere MQ 通道完成。)
  ( 失敗的話, => AMQ9520: 通道沒在遠方定義。 )

7. Start the message CHANNEL using runmqchl and verify it it working.
 # runmqchl -c QMC01.TO.QMC02 -m QMC01

[D. Create the required application objects.]
8. Define the application Queues on your Queue Manager :
 a. ( on QMC02 ) Redefine the Local Queue QL.A :
   DEF QL(QL.A) REPLACE
 b. ( on QMC01 ) Create Local Definition of a Remote Queue for the QL.A on QMC02 :
   DEF QR(QRMT02) REPLACE +
    RNAME(QL.A) RQMNAME(QMC02) XMITQ(XQMC02)

9. Use runmqsc to create the WebSphereMQ objects. (cont.)

[E. Test distributed Queueing.]
10. Use amqsput to send messages to the Queue QL.A on the partner Queue Manager :
 # amqsput QRMT02 QMC01

11. Use amqsget or amgsbcg to check for successful arrival of messages from your partner team.
 # amqsget QL.A QMC02 or
 # amqsbcg QL.A QMC02 or
 check the CURDEPTH attribute of the target Queue.
  → ( on QMC02 ) DIS QL(QL.A) CURDEPTH

12. If the messages do not arrive, investigate the possible causes and solve the problem by :
 - Local transmssion Queue is Empty ?
 - Message CHANNEL is running ?
 - Dead Letter Queue of target Queue Manager is Empty ?
 - Inspect the error in both Queue Managers!


======================================================
[F'. Use Triggering in a distributed environment.]
Set up Remote Triggering :
Use the sample program amqsreq to send request messages to the Queue QL.A on the partner Queue Manager QMC02. The Target Queue should be enabled for triggering so that the sample program amqsech is started automatically in order to generate reply messages which are subsequently received by amqsreq.

1. Reactivate the Trigger function for QL.A to handle request messages send to
 your QL.A now by the partner team.
 DEFINE QLOCAL(QL.INITQ_AP) REPLACE

 DEFINE PROCESS(PR.ECHO) REPLACE +
  APPLICID('/mqmtop/samp/bin/amqsech')
 // UNIX Systems

 DEFINE PROCESS(PR.ECHO) REPLACE +
  APPLICID('amqsech')
         // Windows Systems

 DEFINE QMODEL(QM.A_REPLY) REPLACE (這個在QMC01)

 ALTER QL(QL.A) TRIGGER TRIGTYPE(FIRST)
  INITQ(QL.INITQ_AP) PROCESS(PR.ECHO)

2. Restart the Trigger Monitor :
 # runmqtrm -q QL.INITQ_AP -m QMC02

3. Put request messages on QL.A in your partner team Queue Manager.
 # amqsreq QRMT02 QMC01 QM.A_REPLY

4. Check for a reply of each request message.


[G'. Use the CHANEL Initiator to start messages.]
5. Define and modify WebSphereMQ objects to setup automatic CHANNEL operation using a CHANNEL Initiator.

6. Define a CHANNEL Initiator Queue named QL.INITQ_CH :
 DEF QL(QL.INITQ_CH)

7. Enable the Transmission Queue for Triggering :
 ALTER QL(XQMC02) TRIGGER TRIGTYPE(FIRST) +
  TRIGDATA(QMC01.TO.QMC02) INITQ(QL.INITQ_CH)


8. Set the disconnect interval of the CHANNEL to 30 seconds (default is 6000) :
 ALTER CHL(QMC01.TO.QMC02) CHLTYPE(SDR) DISCINT(30)

9. Start the CHANNEL Initiator :
 # runmqchi -m QMC01 -q QL.INITQ_CH

10. Stop and restart the Sender CHANNEL using runmqchi :
 # STOP CHL(QMC01.TO.QMC02)
 # runmqchl -m QMC01 -c QMC01.TO.QMC02

11. Wait until the CHANNEL is terminated by the DISCINT(30).
 (The RUNMQCHL window will disappear after DISCINT(30) elapsed.)
 If the WebSphereMQ Listener is used, you can also watch the Listener window
 on the partners Queue Manager.

  5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED.
  2008/1/15 15:20:47 通道 'QMC01.TO.QMC02' 正在啟動
  2008/1/15 15:21:18 切斷間隔過期。
  2008/1/15 15:21:18 通道程式 'QMC01.TO.QMC02' 已正常終止。

12. Put some messages on the Queue QRMT02 using amqsput :
 # amqsput QRMT02 QMC01

13. The CHANNEL should restart automatically.

14. If the WebSphereMQ Listener is used, you can also watch the Listener window
 on the partner Queue Manager.

15. If the messages do not arrive, investigate the possible cause and solve the problem.

16. Put some messages on the Queue QRMT02 using amqsreq :
 # amqsreq QRMT02 QMC01 QM.A_REPLY

17. Both CHANNELs should restart automatically.

18. Proof that by checking the CHANNEL status on both sides :
 (Be sure that the DISCINT(30) has not elapsed. )
 DIS CHS(QM.*) all

19. When using the WebSphereMQ Listener, you can also watch the Listener windows
 on both Queue Managers.

20. If the messages do not arrive, investigate the possible cause and solve the problem.

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月15日 星期六

.
. IBM WebSphere MQ v6.0
. Chapter 5.2 IBM MQ Administration in a Mixed Environment.
.

=== Three fields in the Message Descriptor ===
1. Encoding :
 - Representation of the numeric data in the message.
 - iSeries, Windows, and so forth
  MQENC_NATIVE
2. CodedCharSetId :
 - Representation of the character data in the message.
  MQCCSI_Q_MGR
3. Format :
 - Indicates the nature of the data in the message.
 - Values MQ ... are reserved for WebSphereMQ


=== Requesting Application Data conversion ===
1. Request data conversion on the MQGET call :
 - MQGMO_CONVERT
 - Encoding and CodedCharSetId
  a. On input, requested representation of the message.
  b. On output, what the application actually receives.
 - Conversion performed, if necessary, on the basis of what is contained in the Format field.
 - A warning, and the message returned in its original form, if the conversion cannot be done.
2. Otherwise, request data conversion at the sending end of a message channel :
 - CONVERT(YES)
 - Unconverted messages are put on the Dead Letter Queue at the sending end.


=== What Application Data Conversion Can Be done ? ===
1. Some formats are built-in, and the data conversion is performed
  by a built-in conversion routine :
 - A message consisting entirely of characters.
 - A message structure definedd by WebSphereMQ.
2. A user written data conversion exit is required when :
 - The format of a message is defined by the application, not by WebSphereMQ.
 - A message with a built-in format fails to convert.
3. There is a WebSphereMQ utility to help write a data conversion exit.
 # crtmqcvx SourceFile TargetFile

Exit 掛勾 : —↓_↑—↓_↑—↓_↑—
 - Security Exit
 - Conversion Exit
 - Compress Exit
 - Message Exit


=== What Applications Should Do ===
1. Put messages with the following values in the Encoding and CodedCharSetId fields :
 - MQENC_NATIVE (for native encoding)
 - MQCCSI_Q_MGR (for the same CCSID as the Queue Manager)
2. Put all messages with a format name :
 - MQFMT_STRING (for a message consisting entirely of characters)
3. Use the MQGMO_CONVERT option on the MQGET call :
 - Check what is delivered by the call.
4. If necessary, use CONVERT(YES) at the sending end of a message channel.


=== Command Server === (MQ V6已經自動與QM啟動)
1. Command Queue :
 - SYSTEM.ADMIN.COMMAND.QUEUE
 - Messages contain Programmable Command Format (PCF) commands.
2. Command server process the messages in the Queue :
 # strmqcsv QMgrName 
 # endmqcsv QMgrName (Ends the command server)
 # dspmqcsv QMgrName (Displays the status of the command server)
3. Enables network administration applications :
 - "Single point of control"


=== Support for PCF Commands ===
1. All Queue Managers have a command server which accepts PCF commands,
 except :
 - WebSphereMQ for z/OS Version 5
2. Administration utilities which issue PCF commands :
 - SupportPacs for WebSphereMQ for UNIX, Linux and Windows.
 - Vendor products.
 - # runmqsc -w  (indirect mode)
3. Application using the WebSphereMQ Administration Interface.


=== Program Example ===
1. Assume a utility to purge any Queues that have existed beyond their retention interval (賞味期...哈).

[ Application ]              [ Command Server ]
  MQPUT →→→→→→→→→→→→→→→→ MQGET
          MQCMD_INQUIRE_Q    Inquire attributes
          - generic quene name     of selected queues
  MQGET ←←←←←←←←←←←←←←←← MQPUT
Determine which    - Qname         Response for each
queues have     - RetentionInterval      matching queue
expired, and for     - CreationDate
each one ...      - CreationTime
  MQPUT →→→→→→→→→→→→→→→→ MQGET
          MQCMD_DELETE_Q    Delete named queue
          - QueueName


=== Indirect Mode ===
1. Each WebSphereMQ command is sent within an Escape PCF command to the command Queue
 of the named Queue Manager :
 - Connects to the default Queue Manager.
 - Escape PCF command processed at the target Qeueu Manager.
2. Waits for the replies :
 - Time limit for the wait.
 - Writes a report based on the replies received.

 # runmqsc -w 5 QMgrName  (WaitTime in seconds specifies the indirect mode)

3. Can also send a WebSphereMQ command to the system-command input Queue
 of a z/OS Queue Manager.
 - -x parameter


=== Instrumentation Events === 提供給Monitor程式用
1. Have a Queue Manager report a problem condition immediately :
 - Number of messages on a Queue is increasing.
 - Get requests are inhibited for a Queue.
 - Message channel has stopped.
2. Enabled events are reort as event messages on event Queues :
 - SYSTEM.ADMIN.QMGR.EVENT
 - SYSTEM.ADMIN.PERFM.EVENT
 - SYSTEM.ADMIN.CHANNEL.EVENT
 - SYSTEM.ADMIN.CONFIG.EVENT  (z/OS only)
 - SYSTEM.ADMIN.COMMAND.EVENT  (z/OS only)
 - SYSTEM.ADMIN.LOGGER.EVENT  (not z/OS)


=== Responding to an Instrumentation Event ===
1. Queue Manager events :
 - Enable a Queue for put or get requests if it is not intentionally disabled.
 - Corrent the authorizations for a Queue, or stop unauthorized users
  trying to put messages on the Queue.
2. Performance events :
 - Start a process to clear the backlog of messages.
 - Syspend a process that is putting too many messages on a Queue.
3. Channel events :
 - Restart a CHANNEL.
 - Process the Dead Letter Queue.
4. Logger events :
 - Archive unneeded log files.


=== Dead Letter Queue ===
1. When a problem relating to a message is detected asynchronously,
  an exception report is generated if one has been requested
  and the report is sent to the specified reply-to Queue.
2. The Feedback field in the message descriptor of the report message
  indecates the reason for the report.
3. The original message is put on the Dead Letter Queue unless
  MQRO_DISCARD_MSG is requested as a report option.
4. If a message cannot be delivered, it is put on the Dead Letter Queue
  at the receiving end of a message CHANNEL, if one is defined.
5. Message-retry at the receiving end of a CHANNEL may be useful
  if the problem is only temporary.
6. If CONVERT(YES) is specified in the CHANNEL definition at the sending end
  of a message CHANNEL and a message cannot be converted,
  the message is put on the Dead Letter Queue at the sending end.
7. If a message cannot be put on the Dead Letter Queue,
  the CHANNEL is stopped and the message remains on the Transission Queue.
  A fast non-persistent message, however, is just discarded in these circumstances
  and the CHANNEL ramains open.


=== Dead Letter Queue Handler ===
1. Rules table contains a set of rules.
 - Each rule consists of pattern matching keywords and an action.
 - For each message on the Dead Letter Queue, each rule whose pattern
  matches the message is attempted in turn.
 - A message can be retried, forwarded, discarded or ingored.
 - A message can be forwarded with, or without the dead letter header.
2. Can have multiple instances, each with a different rules table.
3. Source of a sample Dead Letter Queue handler is supplied as well.

 # runmqdlq < Rules_Table

 DESTQM(QM17) ACTION(FWD) FWDQ(&DESTQ) FWDQM(QM17A)
 MSGTYPE(MQMT_REPORT) FEEDBACK(MQFB_EXPIRATION) ACTION(DISCARD)
 REASON(MQRC_Q_FULL) ACTION(RETRY)
 DESTQ(XYZ*) ACTION(FWD) FWDQ(XYZ_DEADQ) FWDQM(' ')


=== Using Dead Letter Queues ===
1. Create a Dead Letter Queue on all Queue Managers :
 - Use message-retry on message CHANNELs for transient conditions.
 - Consider "return to sender".
2. Use a Dead Letter Queue handler :
 - Trigger when a message arrives on the Dead Letter Queue.
 - Possibly attempt further retries.
 - If unsuccessful, forward to an application Dead Letter Queue associated with :
  a. The distination Queue.
  b. The application specified by the PutApplName field in the message descriptor.
3. Don't allow an application Dead Letter Queue to become full.

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月15日 星期六

.
. IBM WebSphere MQ v6.0
. Chapter 5.1 IBM WMQ Configuration for Distributed Queuing.
.

=== Identifying a Queue in the MQI ===
1. A Queue is identified by :
 - The name of the Queue.
 - The name of the Queue Manager which owns the Queue.
2. A Queue may be referenced in two places :
 - Object descriptor, on an MQOPEN or MQPUT1 call.
  a. ObjectName
  b. ObjectQMgrName
 - Message descriptor, to specify a reply-to Queue.
  a. ReplyToQ
  b. ReplyToQMgr
3. In an object descriptor, if ObjectQMgrName is blank, the Queue with the
 name specified in ObjectName must be defined in one of the following places :
 - The Local Queue Manager.
 - The name service.


=== Assured Delivery ===
1. Whether an application is putting a message on a Local Queue or to a Remote Queue
 is transparent to the applcation.
2. However, an application always gets a message from a Local Queue.




=== Queue Definitions for Distributed Queuing ===
1. Local definition of a Remote Queue (Remote Local Queue) :
  DEFINE QREMOTE(BBB) RNAME(YYY) RQMNAME(QM2)
2. A Transmission Queue must be created at the SENDing end of each message channel :
 - USAGE(XMITQ) indicates its purpose.
 - Otherwise, it may have any of the attributes of a Local Queue.
  DEFINE QLOCAL(QM2) USAGE(XMITQ)
3. As usual, give a Transmission Queue the same name as the Remote Queue Manager.
(只有SENDER端有XMIQ,且通常命名為要傳送那端的QM)

※ 所以想要建立一個 Remote Queue ,必須提供:
1. RQ Name
2. Remote Local Q Name
3. Remote QM Name
4. XMITQ


※ 對應的 Channel :
1. CHLTYPE - Channel Type
2. (SDR) Connection Name
3. XMITQ (與上面的XMIT串接)


=== Message Channel combinations ===
1. A sender can initiate a communications connection with a receiver and then sned message to it. This is the most common combination. A fully defined server may also perform the same role as a sender in this combination.
 QM1 [ SENDER (SERVER) ] → 開connection → [RECEIVER] QM2
                ↘→ 送 messages →↗

2. A requester can initiate a communications connection with a server which then sends messages to the same requester. 
 QM1 [ REQUESTER ] → 開connection(REQ) → [SERVER (channel) ]
         ↖←←←←← 送messages ←←←←←↙
3. A requester can initiate a communications connection with a sender which promptly terminates the connection. The sender then starts a communications connection according to the information in its Channel definition and sends messages to the partner it has started. This combination is know as callback.
 QM1 [REQUESTER ] → (REQ) → [ SENDER ]
                   ↙
   QM3 [RECEIVER] ←Callback←↙



※ 與Client Channel不同點 : SVRCONN, 是client的方式連上.


=== Attributes of a Message Channel ===
1. Required for definition :
 - Channel-Name   (Up to 20 characters)
 - CHLTYPE     SDR, RCVR, SVR, RQSTR, SVRCONN
 - TRTYPE      DESNET, LU62, NETBIOS, SPX, TCP(default)
 - CONNAME(string)  (for SDR and RQSTR only, optional for SVR)
 - XMITQ(string)    (for SDR and SVR only)

※ TRTYPE 預設為 TCP,可省略.
※ CONNAME('127.0.0.1(1414)') 或 CONNAME(host) 亦可,預設 1414 port

2.Required for SNA LU6.2 :
 - MODENAME(string)
 - TPNAME(string)

※ The WebSphere MQ command to define a message channel at one end is :
 - DEFINE CHANNEL
 - ALTER CHANNEL
 - DISPLAY CHANNEL
 - DELETE CHANNEL

※ Attribute not supplied on the DEFINE CHANNEL command are taken from the appropriate default channel object.
 - SYSTEM.DEF.SENDER
 - SYSTEM.DEF.RECEIVER
 - SYSTEM.DEF.SERVER
 - SYSTEM.DEF.REQUESTER


=== DEFINE CHANNEL Example ===
[ QMAA ]
S.1 DEF CHL('QMA_QMB') CHLTYPE(SDR) TRPTYPE(TCP) +
   CONNAME(host1) XMITQ('QMB')

S.2 DEF QL(QMB) USAGE(XMITQ)

S.3 DEF CHL('QMB_QMA') CHLTYPE(RCVR) TRTYPE(TCP)
--- --- --- --- --- ---
[ QMBB ]
R.1 DEF CHL('QMA_QMB') CHLTYPE(RCVR) TRPTYPE(TCP)

R.3 DEF CHL('QMB_QMA') CHLTYPE(SDR) TRPTYPE(TCP) +
   CONNAME(host2) XMITQ('QMA')

R.4 DEF QL('QMA') USAGE(XMITQ)
--- --- --- --- --- ---


=== Choosing a Transmission Queue ===
1. A Local definition of a Remote Queue can specify :
  DEFINE QREMOTE(BBB) RNAME(YYY) RQMNAME(QM2) XMITQ('Express')
2. The name of the Transmission Queue is inferred from the name of the Remote Queue Manager.
3. A default Transmission Queue can be specified by an attribute of the Queue Manager object.
  ALTER QMGR DEFXMITQ(HOST)
4. Error - the MQOPEN fails.


=== Configuring TCP/IP for WebSphereMQ ===
1. [UNIX/Linux] configure the inet daemon, inetd,...
 - /etc/services :
  MQSeries 1414/tcp      # MQSeries Channel Listener
 - /etc/inetd.conf
  WebSphereMQ stream tcp nowait root /usr/mqm/bin/amqcrsta amqcrsta -m QM
  or
  WebSphereMQ stream tcp nowait mqm /opt/mqm/bin/amqcrsta amqcrsta -m QM

 ※ The inet daemon then has to be refreshed.
  - AIX issue # refresh -s inetd
  - HP-UX issue # inetd -c

2. may use the WebSphereMQ Listener, runmqlsr

 ※ The WebSphereMQ command START LISTENER can also be used to start the Listener.
   On iSeries, UNIX Systems and Windows, this command is valid for CHANNELs
   for which TRTYPE is TCP.


=== Starting a Message Channel ===
1. WebSphereMQ commands :
 - PING CHANNEL(QMA_QMB)
 - START CHANNEL(QMA_QMB)
2. Control command :
 - # runmqchl -c QMA_QMB
3. Channel attributes compared :
 - BATCHSZ   (default=50, 若兩邊channel大小不同,以小的為準)
 - MAXMSGL   (也是以小的為準)
 - SEQWRAP   (counter, default=999999999, 必須一致)
 - HBINT     (HeatBeat interval)
 - NPMSPEED  (Non-Persistence, Fast or Normal)

If the SEQWRAP value on a SENDER CHANNEL is different from the value on the RECEIVER,
  what will happen ? => The CHANNEL will not start.
NPMSPEED(FAST) is a parameter on a CHANNEL that causes the message CHANNEL agent to use
  MQGMO_SYNCPOINT_IF_PERSISTENT
CURSEQNO(3)必須一致,但有時不Sync,就必須RESET CHANNEL,清為0
INDOUBT(NO)為正常,若為YES,就必須RESOLVE CHANNEL( ) ACTION COMMITBACKOUT
A sender CHANNEL is defined in a script file with REPLACE.
  The runmqsc control command is run using this script while the CHANNEL is active.
  => The CHANNEL will fail and won't restart without intervention.


=== CHANNEL Initiator === (此為舊的機制)
The CHANNEL Initiator is a special trigger monitor for starting a message channel. It also contains retry logic for use in case of difficulty in starting a channel or after an error on a channel.
1. START CHINIT INITQ('Channel.InitQ')
 Trigger monitor for Trainsmission Queues :
  - Starts an MCA at the sending end of a message channel.
  - UserData attribute of the process object specifies the Channel name.
  - Or, TrigData attribute of the Transmission queue specifies the channel name.
2. Also a control command :
 # runmqchi -q Channel.InitQ
3. Channel control parameters :
 - DISCINT (SDR and SVR)
  (Max time to wait for a message on the Transmission Queue, if it is empty.
  If no message arrives whin this time, the channel closes down.)
 - SHORTRTY, SHORTTMR (SDR and SVR)
  (Short retry count and shot retry time interval to control repeated attempts to
  establish a communications connection.)
 - LONGRTY, LONGTMR (SDR and SVR)
 - MRRTY, MRTMR (RCVR and RQSTR)
  (Message-retry count and message-retry interval when attempting to
  put a message on a distination queue.
  If every attempt fails, the MCA decides that it cannot deliver the message.)
 - MCATYPE (SDR, SVR and RQSTR)
  (The value of this parameter may be THREAD or PROCESS.
  If THREAD is specified, each channel runs a thread within the CHANNEL Initiator process.
  If PROCESS is specified, each channel runs as a separate process.)
 - BATCHINT (SDR and SVR)
  (The period of time during which a channel will keep a batch open
  if there are no messages on the Transmission Queue.
  This should be set to a value considerably less than the value of DISCINT)


=== Channel Status ===
1. The current state of a channel can be determined by using the WebSphereMQ command :
 DISPLAY CHSTATUS


=== Queue Manager Alias ===
1. A Default Transmission Queue allows a message to be delivered through multiple Queue Managers
 [QMC] ←→ □□□□□□    □□□□□□  ←→ [QME]
        □ QMA □ ←→ □ QMB □
 [QMD] ←→ □□□□□□    □□□□□□ ←→ [QMF]

2. A Queue Manager Alias may also be needed :
 - for example, in QMA :
  DEFINE QREMOTE(QMF) RQMNAME(QMF) XMITQ(QMB)

※ Multi-Hopping :
 - 可克服 firewall 限制考量.
 - 可克服轉碼問題 ->[819]--->RCVR channel[1208 ]SDR channel--->[950]->


=== Separating Message Flows ===
  QM1                         QM2
 □□□□□□□□□□□□        □□□□□□□□□□□□□
 □        QM2□→→→→→→→→ □           □
 □           □←←←←←←←← □QM1        □
 □ [X] →→→→ QM2A □→→→→→→→→ □ →→→→ QL.SERV  □
 □  QL.REPLY ←←←□←←←←←←←← □ QM1A ←←←← [Y]  □
 □□□□□□□□□□□□        □□□□□□□□□□□□□


1. Local Def. of Remote Q :
 DEF QR(QR.SERV) RNAME(QSERVE) RQMNAME(QM2) XMITQ(QM2A)
2. Reply_to_Q Alias :
 DEF QR(QR.REPLY) RNAME(QL.REPLY) RQMNAME(QM1)
3. QM alias (Reply Msg) :
 DEF QR(QM1A) RQMNAME(QM1)

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月9日 星期日

.
. IBM WebSphere MQ v6.0
. Ex 3 - IBM WebSphere MQ Recovery
. 讓我們來練習一下 MQ 的 Recovery
.

=== Exercise 3 : Recovery ===
What we will do :
A. Create a Queue Manager with LINEAR logging.
B. Put persistent and non-persistent messages on Local Queues.
C. Stop and restart a Queue Manager.
D. Recover a danaged Local Queue from its media image.
E. Record manually media images to optimize media recovery.


======================================================
[A. Create a Queue Manager with LINEAR logging.]
1. Create a new Queue Manager named QML00A with LINEAR logging :
 # crtmqm -ll QML00A   (QML00A is your Queue Manager)

※ Default is CIRCULAR, so must add -ll
 - 由 /var/mqm/mqs.ini 定義 LogType=CIRCULAR
 - Windows 下
  HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVersion\Configuration\LogDefaults
 - LogType=CIRCULAR 可改成 LogType=LINEAR

※ 檢查方式為 /var/mqm/qmgrs/QML00A/qm.ini, LogType=LINEAR

2. Start the Queue Manager :
 # strmqm QML00A

[B. Put persistent and non-persistent messages on Local Queues.]
3. Prepare two Local Queues, the default persistence of each Queue should be set YES.
 # runmqsc QML00A
 DEF QL(QL.A) DEFPSIST(YES) REPLACE
 DEF QL(QL.B) DEFPSIST(YES) REPLACE


 Prepare two Alias Queues, the default persistence of each Alias Queue should be set NO.
 DEF QA(QA.A) TARGQ(QL.A) DEFPSIST(NO) REPLACE
 DEF QA(QA.B) TARGQ(QL.B) DEFPSIST(NO) REPLACE

 Clear the Local Queues :
 CLEAR QL(QL.A)
 CLEAR QL(QL.B)


4. Using amqsput to PUT a mixture of persistent and nonpersistent messages.
 - Persistent messages naming the Local Queue.
 - Non-Persistent messages aming the Alias Queue.
 # amqsput QL.A QML00A (放入 Persistent messages)
 # amqsput QA.A QML00A (放入 Non-Persistent messages)
 # amqsput QL.B QML00A
 # amqsput QA.B QML00A

5. Using amqsbcg to browse the messages on the Local Queue QL.A
 # amqsbcg QL.A QML00A

[C. Stop and restart a Queue Manager.]
6. Stop the Queue Manager and then start it again.
 # emdmqm [-i] QML00A
 # startmqm QML00A

7. Browse the messages on Queue QL.A by using the amqsbcg application. Check that only the persistent messages are on the Local queue QL.A have survived the restart.
 # amqsbcg QL.A QML00A
  (Non-Persistence Messages will disappear !!! )

[D. Recover a danaged Local Queue from its media image.]
8. Execute rcdmqimg agaist the Queue QL.B . This allows you to see how the record image can force a checkpoint which is useful fir Queues that never (or infrequently) reach a depth of zero where a checkpoint is done automatically.
 # rcdmqimg -m QML00A -t ql QL.B

9. Locate the file implementing Local Queue QL.B within the file system and damage the Queue by deleting the file.
 /var/mqm/qmgrs/QML00A/queues/QL!B/q   (UNIX)
 
 Program Files\IBM\WebSphere MQ\Qmgrs\QML00A\queues\QL!B\Q   (Windows)

10. Display the attributes of Local Queue QL.B using the DISPLAY QUEUE command.
This might still work if the Queue Manager does not need to access the Queue file in order to provide the requested information.
 # runmqsc QML00A
  DISPLAY Q(QL.B)

  DISPLAY Q(QL.B)
   1 : DISPLAY Q(QL.B)
  AMQ8149: WebSphere MQ 物件已損壞。
   [2016, QL.B]
  AMQ8101: 發生 WebSphere MQ 錯誤 (893)。
   [1012, 20]

11. Browse Local Queue QL.B . The Queue Manager should now detect that the Queue has been damaged and report the fact.
 # amqsbcg QL.B QML00A

  AMQSBCG0 - starts here
  **********************
  MQOPEN - 'QL.B'
  MQOPEN failed with CompCode:2, Reason:2101
  MQDISC

[E. Record manually media images to optimize media recovery.]
12. Recover Local Queue QL.B from its media image.
 # rcrmqobj -m QML00A -t ql QL.B

13. Check that you can now again display the attribute of the Queue.
 # runmqsc QML00A
  DISPLAY Q(QL.B)

14. Broswe the Local Queue QL.B again to check if the messages are recovered successfully.
 # amqsgbr QL.B QML00A
 What about the nonpersistent messages ?

15. Get the messages from the Queue.
 # amqsget QL.B QML00A

16. Stop and Delete the Queue Manager.
 # endmqm [-i] QML00A
 # dltmqm QML00A

17. 打完收工! : )

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月9日 星期日

.
. IBM WebSphere MQ v6.0
. Chapter 4.3 IBM MQ Transaction Recovery
.

=== Message Persistence ===
1. Persistent messages are recovered on restart, if necessary.
2. Nonpersistent messages are expressly discarded on restart.
3. Logging has performance impact.
4. DefPersistence attribute of a Queue.
5. Any Queue may store both persistent and nonpersistent messages,
  except a Temporary Dynamic Queue

※ Non-persistent messages can be used for better performance when it is not critical for
  messages to be able to survive a Queue Manager restart.

※ Both persistent and nonpersistent messages may be stored on the same Queue.
 The only exception to this is a Temporary Dynamic Queue which can only store
 non-persistent messages.


=== Types of Log ===
1. CIRCULAR (default) :
 - Log files viewed as a closed loop.
 - Amount of disk space required for the log does not increase with time.
 - 足夠大的Circular Log, 才能作所有的Transaction.
2. LINEAR :
 - Log files viewed as a sequence.
 - Log file never deleted BUT
  -- Becomes inactive when it contains no entries required to restart the Queue Manager.
  -- Can be archived when it becomes inactive.
 - Needed for media recovery.

※ Periodically, the Queue Manager performs a log checkpoint. Information about the last
 checkpoint, including its location in the log, is held in the checkpoint file, amqalchk.fil


=== Recovering Persistent Messages ===
1. If nessary, persistent messages are recovered automatically when the Queue Manager is restarted.
2. A damaged Local queue may only be detected later :
 - Reported as "object damaged".
 - Normally needs to be recovered manually.
3. In order to restart, a Queue Manager only requires :
 - Log records written since the last checkpoint.
 - Log records written by transactions that were still active at the time the Queue Manager stopped.


=== Damaged Objects and Media Recovery ===
1. WebSphere MQ objects can be marked as damaged :
 - Corrupt data in the Queue file.
 - Missing Queue file.
 - Disk failure.
2. Damaged objects can be deleted.
3. A damaged object can be re-created from a LINEAR log :
 - Known as media recovery
 - Media images of some objects are recorded automatically by the Queue manager at certain times.
 - Record the media images of a Local Queue on a regular basis using the control command rcrmqobj

※ The control command to record a media imge is rcdmqimg.
 For example, the following command will record a media image of a Local Queue : 
 # rcdmqimg -m QMgrName -t QLocal QName

※ A damaged object can be re-created by using the rcrmqobj control command.
 For example, the following command will recreate a Local Queue :
 # rcrmqobj -m QMgrName -t QLocal QName


=== Dumping the Log ===
1. Use dmpmqlog to dump a formatted version of the log.
2. Queue Manager must not be running.
3. By default, the dump commences from the head of the log.
 Optionally, the dump can commence from :
  - The base of the log.
  - A log record identified by a specified log sequence number (LSN).
  - A log file identified by a specified extent number (linear logs only)
4. Log records formatted include :
 - Put and get of persistent messages.
 - Transaction events.
 - Creation, alteration, and deletion of MQ objects.


=== Syncpoint Control ===
 MQGET (customer order)
 Update DB
 MQPUT (dispatch request)
 MQPUT (delivery confirmation)
 Commit

1. Option on MQPUT and MQGET calls :
 - NO_SYNCPOINT (message is added or removed immediately)
 - SYNCPOINT (result of an MQPUT or an MQGET call only becomes visible
        when the unit of work is committed.)
2. Default is platform-dependent.
3. Additional option on an MQGET call :
 - SYNCPOINT_IF_PERSISTENT (a message is only got within syncpoint control if it is persistent)

=== Compensating Transactions ===
1. MQSeries Asynchronous Model :
    □□□□□□□       □□□□□□□□
[DB] ← □ (Write)  □        □      □
    □     □       □      □
    □   Put □ → [q] → [Q] → □ Get    □
    □Syncpoint □       □    (Write) □→ [DB]
    □     □       □ Syncpoint  □ 
    □□□□□□□       □□□□□□□□
 => [Q] → [(Get) Syncpoint (Write)] → [DB]


2. Local syncpoint participation = committed changes


=== Coordinating Local Units of Work ===
※ A Local unit of work is one in which the only resource being updated are those
 of the Queue Manager. (QM Scope)

 MQGET message from server queue
 MQPUT extra requests
 MQPUT reply message
 
 if error ...
  MQBACK
 if OK ...
  MQCMIT



=== Internal Coordination of Global Units of Work ===
※ A Global unit of work is one in which the resources of other resource managers
 are also being updated.

 MQBEGIN 
 MQGET
message from server queue
 EXEC SQL INSERT database record
 MQPUT reply message
 
 if error ...
  MQBACK
 if OK ...
  MQCMIT



=== Database Coordination ===
1. Support database managers :
 - Platform with Linux, Sun solaris, AIX, HP-UX, Windows
 - Database with Oracle, DB2, Informix, Sybase
2. Restrictions :
 - An WebSphere MQ client cannot particaipate in a global unit of work. (MQBEGIN call)
 - Only one Queue Manager may participate in a global unit of work.
 - Normally, updates to WebSphere MQ and database resources must be made on the same system. (Database server may be on a different system provided it can supply an XA compliant client feature.)


=== External Coordination of Global Units of Work ===
※ Single phase commit protocol only :
1. AIX :
 - TXSeries
 - BEA Tuxedo
 - BEA WebLogic Server
 - WebSphere Application Server
2. Sun Solaris :
 - TXSeries
 - BEA Tuxedo
 - BEA WebLogic Server
 - WebSphere Application Server
3. Linux :
 - BEA Tuxedo
 - BEA WebLogic Server
 - WebSphere Application Server
4. HP-UX :
 - TXSeries
 - BEA Tuxedo
 - BEA WebLogic Server
 - WebSphere Application Server
5. Compaq NonStop Kernel :
 - TM/MP (TMF)
6. Windows :
 - TXSeries
 - BEA Tuxedo
 - BEA WebLogic Server
 - WebSphere Application Server
 - MTS/COM


=== CICS Transaction ===
1. A CICS transaction may issue MQI calls.
2. A CICS trigger monitor can start a CICS transaction when a message arrives in a Queue.
3. Only one Queue Manager can be assessed at a time from a single CICS region.
 - Using CICS with a two-phase commit protocol.

※ On AIX, HP-UX, Solaris, and Windows , there is a supplied trigger monitor which runs as a CICS transaction. The process object specifies which transaction to start.
 APPLTYPE CICS
 APPLICID Transaction ID
The trigger monitor performs EXEC CICS START and passes MQTMC2 as CICS data.
If the trigger monitor is started withous data, it gets the trigger messages from SYSTEM.CICS.INITIATION.QUEUE

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月9日 星期日
 

.
. IBM WebSphere MQ v6.0
. Chapter 3.3 - IBM WebSphere Publish / Subscribe
.

====== MQ Publish / Subscribe (Topic) ======
※ MQ Messages are the vehicle (傳播媒介) used to transport the information between publishers and subscribers. The subject of that information is called a topic.

※ There is a requirement for a middleman to handle the proper routing of information. This is handled by a broker.

Topics that are related can be grouped into streams; allowing for fewer total items that the broker needs to manage. It also makes access control simpler. If topic does not belong to a particular stream, the broker has a default stream.

Broker configuration can become very complex with many brokers in a network. However - only one broker is allowed per Queue Manager.


====== Setting Up the Broker ======
※ Queues for each broker automatically defined when broker starts if they do not exist :
 - SYSTEM.BROKER.CONTROL.QUEUE
 - SYSTEM.BROKER.DEFAULT.STREAM
 - SYSTEM.BROKER.ADMIN.STREAM
 - SYSTEM.BROKER.MODEL.STREAM
 - SYSTEM.BROKER... (Created by the broker for internal use.)

※ Authorize applications to use these Queues.

※ Update configuration information in qm.ini or broker page of Queue Manager properties in MQ Explorer.


====== Controlling the Broker ======
1. To start a Broker : # strmqbrk (Can be Triggered)
2. To stop a Broker : # endmqbrk
3. To display a Broker : # dspmqbrk
4. To delete a Broker : # dltmqbrk (Broker must be stopped an MQ must active)
5. To clear a Broker : # clrmqbrk
6. To migrate a Broker : # migmqbrk


====== Message Broker Exits ======
※ Allow customization of publications at broker.
 - Can ALTER publication and MQMD

※ Configured in qm.ini or broker page of Queue Manager properties in MQ Explorer.

※ Sample exit provided
 - Changes destination Queue or Queue Manager.

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月9日 星期日

.
. IBM WebSphere MQ v6.0
. Ex2 - Implementing MQ Trigger
. 讓我們來練習一下如何 Implementing MQ 的Trigger
.

====== Exercise 2. Implementing Trigger ======
1. Create an Initiation Queue named QL.INITQ_AP :
 # runmqsc QMC00A (QMC00A is your Queue Manager)
 DEFINE QLOCAL(QL.INITQ_AP) REPLACE

2. Create a Local Queue (named QL.QT1) which is enabled for Triggering :
 DEFINE QL(QL.QT1) REPLACE +
  TRIGGER +
  TRIGTYPE(FIRST) +
  PROCESS(PR.ECHO) +
  INITQ(QL.INITQ_AP)

3. Create a PROCESS (named PR.ECHO) to identify the application to be started. In such a way that amqsech is started synchronously with respect to the execution of the Trigger Monitor.
 DEFINE PROCESS(PR.ECHO) REPLACE +
  APPLICID('/mqmtop/samp/bin/amqsech')
 // UNIX Systems

 DEFINE PROCESS(PR.ECHO) REPLACE +
  APPLICID('amqsech')
         // Windows Systems

4. Use a Dynamic TEMP Queue (named QM.QT1_REPLY) as Reply-to-Queue which is created by a Model Queue :
 DEFINE QMODEL(QM.QT1_REPLY) REPLACE

5. Start the Trigger Monitor using the control command runmqtrm . Name the Initiation Queue.
 # runmqtrm -m QMC00A -q QL.INITQ_AP

 5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED.
 WebSphere MQ 觸發監視器已啟動。
 __________________________________________________
 請等待觸發訊息。



====== Exercise 2.a Test Triggering with amqsinq ======
6. Test Triggering :
 # amqsreq QL.QT1 QMC00A QM.QT1_REPLY
 (打一些字然後按 Enter,會在 Trigger Monitor 視窗)

7. 把 QL(QL.QT1) 設成 TRIGTYPE(EVERY) 再試試看:
 DEFINE QL(QL.QT1) REPLACE +
  TRIGGER +
  TRIGTYPE(EVERY) +
  PROCESS(PR.ECHO) +
  INITQ(QL.INITQ_AP)

8. 把 QL(QL.QT1) 設成 TRIGTYPE(DEPTH) 再試試看:
 DEFINE QL(QL.QT1) REPLACE +
  TRIGGER +
  TRIGTYPE(DEPTH) TRIGDPTH(6) +
  PROCESS(PR.ECHO) +
  INITQ(QL.INITQ_AP)


====== Exercise 2.b Test Triggering with amqsinq ======
9. Create a 2nd PROCESS object for amqsinq :
 DEFINE PROCESS(PR.INQ) REPLACE +
  APPLICID('/mqmtop/samp/bin/amqsinq')
 // UNIX Systems

 DEFINE PROCESS(PR.INQ) REPLACE +
  APPLICID('amqsinq')
 
        // Windows Systems

10. ALTER the QL(QL.QT1) appropriately :
 ALTER QL(QL.QT1) PROCESS(PR.INQ)

11. Run amqsreq again, remembering that amqsinq now expects the application data in each message to contain the name of a Queue. For example, use the names of the following Queues :
 # amqsreq QL.QT1 QMC00A QM.QT1_REPLY
 
 SYSTEM.ADMIN.COMMAND.QUEUE
 QM.QT1_REPLY
 SYSTEM.SAMPLE.REPLY
 QL.QT1
 => Try an invalid Queue name.


===============================
====== 補充:Channel Trigger ======
===============================
※ 不需要 Trigger Monitor,也不需要 Data ,亦可以避免 Channel Expire 的暫停。

[QM1] (Listen : 1414)
 XXX.QR →→→ YYY.QL
 
 QM2.XMITQ ---Trigger
 ---> SYSTEM.CHANNEL.INITQ
 ---> QM1.To.QM2 (SDR)

[QM2] (Listen : 1415)
 YYY.QL
 
 QM1.To.QM2 (RCVR)

  ALTER XMITQ
  TRIGGER Control ON
  TRIGGER TYPE FIRST
  TRIGGER DATA(Channel Name)
  INITIATION QUEUE
  SYSTEM.CHANNEL.INITQ

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月9日 星期日
 

.
. IBM WebSphere MQ v6.0
. Chapter 3.2 - IBM WebSphere MQ Trigger
.

=== Components of Triggering ===
Program A MQPUT A-Q (put a message on an application Queue)--->
 [QM]
  (1)→ Application Queue (which is enabled for triggering)

(If the conditions for triggering are met, a trigger event occurs, and the QM examines the Process Object referenced by the Application Queue)
  (2)→ Process Object

(The QM creates a trigger message whose fields contain information copied from certain attributes of the Process Object and the Application Queue. The QM puts the trigger message on an Initiation Queue.)
  (3)→ Initiation Queue
 [/QM]

(A long running program called a trigger monitor gets the trigger message, examines otscontents, and ...)
  (4)—→ MQGET I-Q (Trigger Monitor)

(... and starts Program B, passing the entire trigger message as a parameter.)
  (5)—→ MQGET A-Q Program B

(Program B opens the Application Queue and gets messages from it.)
  (6)—→ MQGET A-Q Program B


=== Queue Attributes Controlling Triggering ===
※ TRIGGER/NOTRIGGER 是 Queue 的一個參數 :

DEFINE QLOCAL(QL.QT1) TRIGGER +
 PROCESS(ECHO) +
 INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)


 - TRIGGER or NOTRIGGER : Triggering is active or not active respectively.
 - TRIGMPRI(integer) : 可設定Priority多少以上才Triggering.
 - TRIGTYPE(FIRST or DEPTH or EVERY or NONE) : Triggering四種Type.
 - TRIGDPTH(integer) : 對應 TRIGTYPE(DEPTH)
 - TRIGDATA(string) : Data that is copied into the Trigger Message.


=== PROCESS Attributes (定義PROCESS) ===
DEFINE PROCESS(ECHO) +
 APPLICID('/opt/mqm/samp/bin/amqsech')

DEFINE PROCESS(ECHO) REPLACE +
 APPLICID('C:\Program Files\IBM\WebSphere MQ\Tools\c\Samples\Bin\amqsech.exe')

 - APPLICID(string) : Name of the application to be started.
 - APPLTYPE(UNIX or WINDOWS)
 - ENVRDATA(string) : For use by the trigger monitor.
 - USERDATA(string) : For use by the trigger monitor or the started application.

※ MQ commands for PROCESSes :
 DEFINE PROCESS
 ALTER PROCESS
 DELETE PROCESS
 DISDPLAY PROCESS


=== Fields in the Trigger Message (structure MQTMC2) ===
1. Copied from the corresponding attributes of the application Queue :
 - QName
 - TriggerData
 - ProcessName

2. Copied from the corresponding attributes of the process object :
 - ApplType (MQAT_CSIC, MQAT_UNIX, MQAT_WINDOWS)
 - ApplId
 - EnvData
 - UserData

3. QMgrName :


====== 啟動 Trigger Monitor ======
1. To start a trigger monitor :
 # runmqtrm -m QMgrName -q InitiationQName
 (I-Q 預設會用 SYSTEM.DEFAULT.INITIATION.QUEUE )
 例如 : # runmqtrm -m QMC00A -q SYSTEM.DEFAULT.INITIATION.QUEUE

2. Command issued by trigger monitor to start the application :
# (ApplId) "(MQTMC2)" (EnvData)

3. Other trigger monitors :
 - Client trigger monitor
 - CICS


=== Trigger Monitor Errors (狀況處理) ===
1. Messages are produced by Normal activities (正常), for example :
 - Trigger monitor started.
 - Waiting for a trigger message.
 - Trigger monitor ended.

2. Messages are produced by Abnormal conditions (異常) , for example :
 - Initiation Queue could not be opened.
 - Use of trigger monitor not authorized.
 - Error starting triggered application.

3. A message may be written to :
 - The standard output device.
 - An error log.

4. A Trigger Message is written to the Dead Letter Queue if :
 - The Trigger Message structure is not valid.
 - The Trigger Message specifies an unsupported application type.
 - The Trigger monitor is enable to start the specified application.


======Sample Programs======
# amqsreq QName [QMgrName]
1. This program is invoked from a Command Prompt in exactly the same way as amqsput, but accepts three input parameters.
2. The program reads lines of text from the standard input device, converts them to request messages, and puts the messages on the named Queue.
3. Each request message requires a Reply-to-Queue name specified as the third input parm. If it is ommitted, the name defaults to SYSTEM.SAMPLE.RELAY .
(C:\Program Files\IBM\WebSphere MQ\Tools\mqsc\Samples\amqscos0.tst)
4. If the name resolves to Model Queue, a Dynamic Queue will be created.
5. When the input of text is terminated (null line or EOF), the program waits for the reply messages and writes the text whin each reply message to standard output device.

 例如:# amqsreq QL.TQ1 QMC00A

# amqsech
1. This program is designed to be started by a Trigger Monitor and not from a Command Prompt.
2. The program connects to the Queue Manager named in the structure passed to it by the Trigger Monitor and opens the Queue also named in the structure. This is called the Request Queue in the description that follows.
3. The program gets a message from the Request Queue, create a new message containing the same application data as the original message, and puts the new message on the Reply-to-Queue named in the message descriptor of the original message.
4. The program then gets each of the remaining messages on the Request Queue in turn and generates a reply in the same way.
5. When the Request Queue is empty, the program closes the Queue and disconnects from the Queue Manager.

# amqsinq
1. This program is designed to be started by a Trigger Monitor in the same way as amqsech.
2. The program connects to the Queue Manager, opens the Request Queue, gets a message from the Queue, an interprets the application data as the name of a Queue.
3. The program opens this Queue, calls MQINQ to inquire on the values of three of its attributes, constructs a reply message contain these values, and puts the message on the Reply-to-Queue.
4. The program then gets each of the remaining messages on the Request Queue in turn and generates a reply in the same way.
5. When the Request Queue is Empty, the program closes the Queue and disconnects from the Queue Manager.

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月9日 星期日

.
. IBM WebSphere MQ v6.0
. Chapter 3.1 - IBM WebSphere Message Group and Message Segmentation
.

=== 關於 Message and Correlation Identifiers ===
Two fields in the Message Descriptor :
1. MsgID (message identifier ) :
 If an application specifies MQMI_NONE on an MQPUT call, the Queue Manager
 generates a unique message identifier.

2. CorrelID (correlation identifier) :
 In a reply or report message, it is normally copies from the MsgID of the original message.

※ Both fields are treated as bit strings by the Queue Manager.


=== 關於 Retrieving Messages ===
1. With selection criteria :
 - Set MsgID and/or CorrelID prior to an MQGET call
 - Also ensure that MatchOptions in get message options is set to
  MQMO_MATCH_MSG_ID + MQMO_MATCH_CORREL_ID

2. Without selection criteria :
 - Reset MsgID and CorrelID to MQMI_NONE and MQCI_NONE respectively
  before each MQGET call
 - Or, set MatchOptions in get message options to MQMO_NONE

3. On return from an MQGET call, MsgID and CorrelID are set to the values
  for the message retrieved.


=== Order of Retrieving Messages 取出訊息順序 ===
1. Messages on a Queue can be retrieved by an application in the same order
  they were put by another application, provided :
 - The messages all have the same priority.
 - The messages were all put within the same unit of work, or all put outside of a unit of work.
 - No other application is getting messages from the Queue.
 - The Queue is Local to the putting application.
 - But they may be interspersed with messages put by other applications.

2. If the Queue is not Local to the putting application, the order of retrieval is still
  preserved provided :
 - The first three conditions above still apply.
 - Only a single path is configured for the messages.
 - No message is put on a Dead Letter Queue
 - No nonpersistent messages are transmitted over a fast message channel.


=== 關於 Message Group (Guaranteed 機制) ===
[ Message Group ] <= (Logical message 1) + (Logical message 2) + (Logical message 3)

※ A Message Group : Consists of one or more logical messages.

※ A Logical message is :
 - A physical message (unless it is split into segments).
 - Identified by the GroupID and MsgSeqNumber fields in the message desccriptor.

說明:
1. All logical messages belonging to the same group have the same value for the GroupID field.

2. The MsgSeqNumber field has the value 1 for the first logical message, 2 for the second,
 and so on.There is, therefore, an implied ordering to the logical messages within a group.

3. A physical message which does not belong to any group has the value MQGI_NONE in
 the GroupID field, and the value 1 in the MsgSeqNumber field.


=== 關於Message Group 2 個主要用途 ===
1. To ensure ordering on retrieval in circumstances where this is not already guaranteed.
 - An application is able to put a sequence of messages constituting a Message Group on a Queue by specifying the put message option MQPMO_LOGICAL_ORDER. The Queue Manager generates a unique group identifier (GroupID) and assigns a message sequence number (MsgSeqNumber) to each message as it it put on the Queue.
 - Another application is then able to get the messages constituting the group from the Queue, in the same order they were put, by specifying the get message option MQGMO_LOGICAL_ORDER.

2. To allow an application to group together related messages.
 - This may be useful, for example, if it is important for a group of related messages to be processed by the same server instance, or by a particular server instance. By setting the value MQMO_MATCH_GROUP_ID in the MatchOptions filed in get message options, an application can retrieve only those messages with a specified group Identifier.

※ Needed : (Version 5 and 6 Queue Managers only)
 - To ensure ordering on retrieval (Where it is not already guraranteed).
 - To allow an application to group together related messages.


=== 關於 Message Segmentation ===
為了解決以前的程式,Message buffer固定且小的問題。
※ A segment is :
 - A physical message.
 - Identified by the GroupID, MsgSeqNumber, Offset fields in the message descriptor.

※ Segmentation is needed when a message is too large for an application, a Queue, or a Queue Manager.

※ A message can be segmented and reassembled :
 - By the Queue Manager.
 - By an application.

1. To ask the Queue Manager to segment a message if necessary, the putting application simply sets the value MQMF_SEQMENTATION_ALLOWED in the MsgFlags field of the message descriptor and issues one MQPUT call.

Similarly, the getting application simply specifies the get message option MQGMO_COMPLETE_MSG in order to request the Queue Manager only to return a complete logical message on an MQGET call. And if the logical message is segmented, the Queue Manager reassembles it before returning it to the application.

2. If a message is too large for an application to handle in a songle buffer, the application may perform the segmentation itself by issuing an MQPUT call for each segment. Similarly, an application may issue an MQGET call for each segment of a logical message.

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月9日 星期日

.
. IBM WebSphere MQ v6.0
. Chapter 3.1 - IBM WebSphere MQI (Message Queueing Interface)
.

====== MQI Notation ======
1. WebSphere MQ Application Programming Reference :
MQPUT1 (Hconn, ObjDesc, MsgDesc, PutMsgOpts, BufferLength, Buffer, CompCode, Reason)

MQPUT (
Hconn, Hobj, MsgDesc, PutMsgOpts, BufferLength, Buffer, CompCode, Reason
)

MQGET (
Hconn, Hobj, MsgDesc, GetMsgOpts, BufferLength, Buffer, CompCode, Reason
)

2. Equivalent in C :
MQPUT1 (Hconn, &ObjDesc, &MsgDesc, &PutMsgOpts, BufferLength, Buffer, &CompCode, &Reason)

3. Equivalent in COBOL :
CALL "MQPUT1" USING HONN, OBJDESC, MSGDESC, PUTMSGOPTS, BUFFERLENGTH, BUFFER, COMPCODE, REASON)


====== MQI : Connecting and Disconnecting ======
1. Connect Queue Manager :
MQCONN(QMgrName, Hconn, CompCode, Reason)
MQCONNX(
QMgrName, ConnectOpts, Hconn, CompCode, Reason)

2. Disconnect Queue Manager :
MQDISC(Hconn, CompCode, Reason)


====== MQI : Opening and Closing an Object ======
1. Open Object :
MQOPEN(Hconn, ObjDesc, Options, Hobj, CompCode, Reason)

Options = MQOO_INPUT_SHARED + MQOO_FAIL_IF_QUIESCING;

2. Close Object :
MQCLOSE(Hconn, Hobj, Options, CompCode, Reason)


====== MQI : Priority 設定優先權 ======
1. Priority :
 - Field in the message descriptor, set by an application to one of the following :
  a. A value in the range 0 (lowest) to 9 (highest)
  b. MQPRI_PRIORITY_AS_Q_DEF

2. MsgDeliverySequence :
 - Attribute of a Local or Model Queue with values :
  a. MQMDS_PRIORITY : messages returned by MQGET in priority order.
  b. MQMDS_FIFO : messages returned by MQGET in FIFO order.

3. DefPriority :
 - Attribute of a Queue specifying the default message priority.
 - Used when an application sets Priority to MQPRI_PRIORITY_AS_Q_DEF

4. Conventions (公約優先權) :
 - In general, use the default priority.
 - Use the same priority as the original message for a reply or a report.


====== MQI : Common Parameters 常見參數 ======
01. MQCC_ : CompCode [Completion Code] 完成碼
 - MQCC_OK
 - MQCC_WARNING
 - MQCC_FAILED

02. MQRC_ : Reason [Reason Code] 理由

03. MQOT_ : ObjectType
 - MQOT_Q
 - MQOT_PROCESS
 - MQOT_Q_MGR

04. MQOO_ : Open Object
 - MQOO_INPUT_SHARED
 - MQOO_INPUT_EXCLUSIVE
 - MQOO_FAIL_IF_QUIESCING
 - MQOO_BROWSE (for reading messages on a queue and leaving them there.)

05. MQFB_ : FeedBack

06. MQPMO_ : PutMsgOpts [用於 MQPUT]
 - MQPMO_SYNCPOINT
 - MQPMO_FAIL_IF_QUIESCING

07. MQMDS_ : MsgDeliverySequence
 - MQMDS_PRIORITY (messages returned by MQGET in priority order.)
 - MQMDS_FIFO (messages returned by MQGET in FIFO order.)

08. MQGMO_ : GetMsgOpts [用於 MQGET]
 - MQGMO_ACCEPT_TRUNCATED_MSG
 - MQGMO_BROWSE
 - MQGMO_CONVERT (轉碼)

09. MQMT_ : MsgType [Message Type, 用於 Message Descriptor]
 - MGMT_DATAGRAM
 - MGMT_REQUEST
 - MGMT_REPLY
 - MGMT_REPORT

10. MGRO_ : Report Options
 - MGRO_EXCEPTION (例外)
 - MGRO_EXPIRATION (過期)
 - MGRO_COA
 - MGRO_COD
 - MGRO_DISCARD
 - MGRO_PAN
 - MGRO_NAN


====== MQ小撇步 ======
※ Error Code 查詢: # mqrc 2085

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月8日 星期六

.
. IBM WebSphere MQ v6.0
. Chapter 2.2 - IBM WebSphere MQ6指令與MQSC
.


※ 一般小寫是 Control Command /// 一般大寫是 MQSC (runmqsc

------DEFINE指令:定義新的Queue物件------
# runmqsc QMC00A
1. DEFINE QLOCAL(QL.Q1) REPLACE
 (與指令 DEF QL(QL.Q1) REPLACE 相同,可用 DIS QL(QL.Q1) 察看 )
 例如 : DEF QL(QL.Q1)

2. DEF QL(QL.Q1tmp) LIKE (QL.Q1)

 例如 : DEF QL(QL.Q1tmp) LIKE (QL.Q1)

3. DEF QL(QL.Q2) REPLACE DESCR('描述字串')
 例如 : DEF QL(QL.Q2) REPLACE DESCR('This is a test queue2')

※ 用 (+) 號:表示連結,V5之前一行不超過80字元,V5之後無限制.
※ 用 (;) 號:表示結尾.
※ REPLACE:表示如果存在就替換,不存在就建立.
※ LIKE:建立一個 Queue 套用指定的 attributes.

4. DEFINE QLOCAL(QL.Q3) REPLACE +
  DESCR('This is a test queue3') +
  PUT(ENABLED) GET(ENABLED) +
  DEFPSIST(YES) SHARE +
  MAXDEPTH(1000) MAXMSGL(2000) +
  NPMCLASS(HIGH)
※ 系統Default Local Queue 屬性:default is SYSTEM.DEFAULT.LOCAL.QUEUE
※ MAXDEPTH : 最大深度
※ MAXMSGL : 最大 Message Length
NPMCLASS : allows the survival of nonpersistent messages.
 The allowed settings are HIGH(可能遺失MSG) and NORMAL.
 The NPMCLASS can be defined or altered on Local and Model.

------DISPLAY指令:顯示物件------
# runmqsc QMC00A
1. DISPLAY QMGR ALL (顯示目前 QMGR的屬性, 指令 DIS QMGR 相同)


2. DISPLAY QUEUE(*) (顯示所有的 QUEUE, 指令 DIS Q(*) 相同)

3. DISPLAY Q(SYSTEM*) ( * 只能放在尾巴)

4. DIS Q(QL.Q1) ALL (顯示 Q1.QL 的所有屬性)

5. DIS Q(QL.Q1) DESCR GET PUT

6. DIS Q(QL.Q1) MAXDEPTH CURDEPTH (查詢 Q1.QL 最大深度 與 現在深度 )

7. DIS QLOCAL(*) (顯示所有的 LOCAL QUEUE)
 DIS QALIAS(*)
 DIS QMODEL(*)
 DIS QREMOTE(*)


------DEFINE指令2:定義其他Queue物件------
1. DEFINE QALIAS(QA.Q1) TARGQ(QL.Q1)

2. DEFINE QREMOTE(QR.Q1) RNAME(QL.Q1) RQMNAME(QMC00B)

3. DEFINE QMODEL(ANSQ) DEFTYPE(TEMPDYN)
※Model Queue :
 - TEMPDYN, dynamic queue deleted when closed.
 - PERMDYN, dynamic queue may hold persistent messages.

※ 可以測試看看 ALIAS Queue 與實際 Queue 有什麼差別?
範例:DEF QL(QL.Q4) REPLACE
範例:DEF QA(QA.Q4) TARGQ(QL.Q5) REPLACE
範例:ALTER QA(QA.Q4) PUT(DISABLED)
範例:DIS QL(QL.Q4) PUT CURDEPTH
範例:試著在Command Line : amqsput QL.Q4 QMC00A (可塞)
範例:試著在Command Line : amqsput QA.Q4 QMC00A (不可塞)
(MQPUT ended with reason code 2051 , 表示QA.Q4無法塞入,但QL.Q4可以)


範例:DEF QL(QL.Q5) REPLACE
範例:DEF QA(QA.Q5) TARGQ(QL.Q5) REPLACE
範例:ALTER QL(QL.Q5) PUT(DISABLED)
範例:DIS QL(QL.Q5) PUT CURDEPTH
範例:試著在Command Line : amqsput QL.Q5 QMC00A (不可塞)
範例:試著在Command Line : amqsput QA.Q5 QMC00A (不可塞)
(MQPUT ended with reason code 2051 , 表示皆無法塞入)


------ALTER指令:修改新的物件------
1. ALTER QLOCAL(QL.Q1) MAXDEPTH(8888)

2. ALTER QLOCAL(QL.Q1) PUT(DISABLED)

3. ALTER QALIAS(QA.Q1) TARQ(QL.Q1tmp)

4. ALTER QMGR DESCR('New description')


------DELETE指令:刪除物件------
1. DELETE QLOCAL(QL.Q1) (注意:只有在 Queue 沒用時才可以用)

2. DEL QL(QL.Q1) PURGE (強制刪除 Queue )

3. DELETE QREMOTE(QR.Q1)


------DELETE all messages on the Local Queue------
1. CLEAR QLOCAL(QL.Q1) (不是 In Use 才能清空QL,另一方式是用TOOL去GET掉)
 例如 : CLEAR QL(QL.Q5) (=> AMQ8022: 已清除 WebSphere MQ 佇列。)


------關於DEAD LETTER QUEUE------
1. DEFINE QLOCAL(DLQ) REPLACE (與 DEF QL(DLQ) REPLACE 指令相同)

2. ALTER QMGR DEADQ(DLQ) (指定 DLQ 為 QM 的 DEAD LETTER QUEUE)


------結束runmqsc------
※ Windows : Ctrl+Z (END)
※ UNIX / Linux : Ctrl+D (END)


 

======Sample Programs======
# amqsput QName [QMgrName] (把Message放到QMgrNameQName

, EOF結束) (The program connects to the Queue Manager and opens the Queue for output, reads lines of text form the standard input device, generates a message from each line of text and puts the messages on the named queue. After reading a null line or EOF character from the standard input device, it close the Queue, and disconnects from the Queue Manager)

 例如:# amqsput QL.Q1 QMC00A
 (塞完之後可以在 runmqsc 用 DISPLAY QL(QL.Q1) CURDEPTH 看結果)


# amqsget QName [QMgrName] (把Message從到QName取出)
(The program connects to the Queue Manager, opens the Queue for input, gets all the messages from the Queue, write the text within the message to the standard output device, waits 15 seconds in case any more messages are put on the Queue and, if none arrive, closes the Queue and disconnects from the Queue manager)
(※※※ 但注意 amqsget 的 get buffer只有100bytes)
 例如:# amqsget QL.Q1 QMC00A > QLQ1.msg


# amqsbcg QName [QMgrName]

(Display messages, including message descriptors) (The program connects to the Queue Manager, opens the Queue for browsing, browses all the messages on the Queue, and writes their contents, in both hex and character format, to the standard output device. It also displays, in a readable format, the fields in the message descriptor for each message. It then closes the Queue and disconnects from the Queue Manager)


amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月8日 星期六

.
. IBM WebSphere MQ v6.0
. Chapter 2.1 - IBM WebSphere Queue Manager(QM)指令
.


※ 一般小寫是 Control Command /// 一般大寫是 MQSC (runmqsc)


======Create Queue Manager (創建新的QM)======
# crtmqm -q QMgrName
 例如:# crtmqm -q QMC00A
 -q : specifies the default Queue Manager (-q 表示建的是 default QM)
 -lc : Circular logging is to be used. This is the default logging method.
 -ll : Linear logging is to be used. Linear logging is needed for recovery from media failures.
 -lf LogFileSize : The size of each of the log files expressed as a multiple of 4 KB.
    (因為乘以4KB,所以如果是 32MB,則設定 -lf 8192 )
 -ld LogPath : The directory to be used to hold the log files.
 -u DeadLetterQueue.



======啟動 Queue Manamer======
# strmqm QMgrName
 例如:# strmqm QMC00A

======結束End Queue Manager======
# endmqm -c QMgrName (等 connected)
 (Controlled (or quiesced), Allows connected applications to end, but no new ones.)

# endmqm -i QMgrName (等 MQI calls)
 (Completes all current MQI calls, but no new ones.)

# endmqm -w QMgrName (CTRL+D)
 (Controlled(wait), End programs in the same manner as the CTRL+D option.)

# endmqm -p QMgrName (暴力停,但QM可能掛掉!)
 (Preemptive mode.)

======Delete Queue Manager (刪除QM)======
# dltmqm QMgrName

======執行 MQ Script Command======
# runmqsc QMgrName
 例如:# runmqsc QMC00A
 -e : Don't copy the source text to the output report. (silence mode)
 -v : Perform a syntax check only. (不會真正執行,只Verify)

# runmqsc QMgrName < amqscoma.tst
 (將 amqscoma.tst 匯入執行,V6.0才有效)

# runmqsc < mqsc.in > mqsc.out
 (對 default Queue Manager 執行 mqsc.in )

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年12月8日 星期六

.
. IBM WebSphere MQ v6.0
. Chapter 1.0 - IBM WebSphere MQ6 基本觀念
.


===關於Queue Manager===
1. Generally one Queue Manager per system. (基本上一個系統一個QM)
2. A Queue Manager owns and manages Queues.
3. Family of application programming interfaces :
 ---> Message Queue Interface (MQI)
 ---> Java Messaging Service (JMS)


===Queue 基本種類 TYPES===
1. Local Queue ( QL ) : store messages
2. Alias Queue (QA) : is not a Queue, but an object that you can use to access another Queue.
3. Remote Queue (QR) : identifies a Queue belonging to another Queue Manager.
4. Model Queue and Dynamic Queue : Temporary Queue


※ Queue 基本上是 FIFO (First-In-Fist-Out),
※ WebSphere MQ Version 6.0 support Queues over 2 GB in size.


===關於Alias Queue===
Alias Queue is not a Queue, but an object that you can use to access another Queue.
 (可用來指定別名,以及屬性限制設定。)


===關於Model Queue and Dynamic Queue===
1. Define a Model Queue with a set of attributes in the same way that you define a Local Queue.

2. Model Queues and Local Queues have the same set of attributes, except that on Model Queues you can specify whether the dynamic queues created are temporary or permanent.
(Permanent queues are maintained across queue manager restarts, temporary ones are not.)

3. A Model Queue defines a set of Queue attributes that are used as a template for creating a dynamic queue. Dynamic queues are created by the Queue Manager when an application issues an MQOPEN request specifying a Queue name that is the name of a Model Queue.

4. The dynamic queue that is created in this way is a Local Queue whose attributes are taken from the Model Queue definition. The dynamic queue name can be specified by the application, or the Queue Manager can generate the name and return it to the application.

5. Dynamic queues defined in this way can be temporary Queues, which do not survive product restarts, or permanent Queues, which do.


===Special LOCAL QUEUES介紹===
1. DEAD LETTER QUEUE :
 a. One per queue manager.
 b. Designated queue for messages that cannot be delivered.
 c. Always set up a dead letter queue.
2. INITIATION QUEUE : Used for Triggering
3. TRANSMISSION QUEUE : are queues that temporarily store messages that are desined for a remote queue messagers.
4. COMMAND QUEUE : SYSTEM.ADMIN.COMMAND.QUEUE -> send MQSC commands
5. EVENT QUEUE : can be monitored by a system management application which a can get message put on the queue and take the appropriate action.
6. DEFAULT QUEUES : 4 types of local, alias, remote, model can have its default queue.


===關於Message CHANNEL===
CHANNELs are objecs that provide a communication path from one queue manager to another.

A MESSAGE CHANNEL is a one way link between two queue managers for the transmission of messages.
It consists of an MCA (Message Channel Agent) at the sending end, an MCA at the receiving end, and a communications connection between the two.


[ (MQPUT) ---> tQ ---> (MCA) ] ----------> [ (MCA) ---> Q ---> (MQGET) ]



===MQI Calls 基本架構===
1. MQCONN ---> (Queue Manager)
 2. QMOPEN ---> (Queue)
  3. MQPUT / MQGET / MQINQ / MQSET
  MQBEGIN
   MQPUT / MQGET
   IF successful -> MQCMIT
   ELSE MQBACK
  4. MQCLOSE ---> (Queue)
 5.MQDISC ---> (Queue Manager)
===關於Message===
A message consists of two parts :
1. Message descriptor
2. Application data
===關於Message Persistence===
Message 在 Persistence方面,又分成
1. Persistent message
2. Nonpersistent message (想快且不甚重要,但重開會消失,例如應用在 Broadcast)
===關於Listener===
AIX amqcrsta ---> root 起,為 inet TCP/IP 的 Demon,是 [ process listener ]
AIX / WIN runmqlsr ---> 不需 root,但port必須大於 1024,是 [ threaded listener ]
client 產生 SVRCONN
===MQ Object命名長度限制===
Channels ---> Max 20 characters.
其他Object ---> Max 48 characters.


===安裝MQ Installation===
AIX : SMIT
NCR UNIX : sysadm or pkgadd
Compaq OpenVMS : VMSINSTAL
HP-UX : swinstall
OS/2 Warp : INSTALL, CID enabled
Linux : rpm
SINIX and DC/OSx : pkgadd (DC/OSx), sysadm (SINIX)
Sun Solaris : pkgadd
Windows :


===權限問題===
Authority for executing WMQ control commands (crtmqm, strmqm, endmqm, dltmqm...etc.):
UNIX :
 user:group = mqm:mqm => all control commands, all MQI calls.
 user:group = *:mqm => runmqsc, all MQI calls. (Exception: change owner of MQI dirs.)
Windows :
 Member of LOCAL Administrator / mqm group
 (if domain accounts are used, they must be added into LOCAL Administrator/mqm group)
 

amzshar 發表在 痞客邦 留言(0) 人氣()

2007年11月28日 星期三
 


大概是因為公司以後要把 IBM MQueue Centralize
MQ集中之後可能由某部門接收管理,
所以將來MQ會變成一個龐然大物,
於是這三天被派去上 IBM MQueue 的訓練課程,

課程代號:MQ15 - MQSeries System Administration
聽說上課費用是 NT$ 18,000 (含稅),不過我ㄉ應該是用點數ㄉ要 36 點
公司出錢,ㄏㄏㄏ,這時候覺得公司還不錯耶~~~
可是我們 BEA WebLogic Team,生意是越作越大ㄌ ...


然而,這三天11/26(一)~11/28(三)大概是我今年最最忙ㄉ三天了,
因為一、三晚上我還有研究所ㄉ課要上,行程變得非常非常的趕,

行程預定表:
11/26(一) 桃園 -> 台北MQ -> 新竹研究所ㄉ課 -> 桃園
11/27(二) 桃園 -> 台北MQ -> 桃園
11/28(三) 桃園 -> 台北MQ -> 新竹研究所參加meeting -> 住新竹姊

------>>>>>> 鬧鐘在鬼叫 可是我還不想起床 <<<<<<------

星期一大清早七點,從桃園開車到 台北市襄陽路9號12樓 (IBM教育訓練中心),
伴隨著"米塔颱風"共伴豪雨的襲擊,加上PDA "趴趴造" 亂指一通,
害我一大早就過得非常驚險,尤其是不能左轉ㄉ地方,導航硬是ㄍㄞ要左轉,
雨天視線不好,都是到ㄌ路口才判斷要不要上或下交流道,
"趴趴造"跟路標指示的,有時候又不太一樣,
只能靠臨場反應,猜上猜下,靠左靠右,

結果喵ㄉ勒,每次照導航結果都是 "路線重新規劃" ,真ㄉ是他媽ㄉBX(X=央) ...
早知道直接一高下重慶北路,直接殺到襄陽路左轉就搞定ㄌ,
沒事繞到五股、新莊、三重、忠孝橋 ...,沿路塞到爆炸 ...
果然 "最佳路徑" 也不一定是最好的 Solution ... XD

當然啦,第一天給它遲到ㄌ, 開了快兩個鐘頭的車,
只好隨便把車停到姓揚的人開的"信陽停車場",機械式ㄉ,
第一小時 100元,第二小時 50元 ...
二十四小時內上限 300元,
後來算算,最後一個選項還不賴,後面兩天也就停在那邊ㄌ,

第一天 MQ 教了一些基本常識,什麼是WebSphere MQ
什麼是 QM(Queue Manager)?什麼是 Q(Queue)?
Installation and Configuration?
以前只知道 Message-Driven Bean 、
JMS (Java Message Service)之類ㄉ去連MQ,
終於知道MQ裡面ㄉ實際運作原理與物件(Object),
比想像還簡單,還蠻開心的。 :)

上完MQ,就南下回交大上"計算機架構(Computer Architecture)",
今天講的是 Memoey Hierarchy Design,這個就有點硬了,
上完課,就繼續跟"米塔颱風"搏鬥,順利回到桃園。

------>>>>>> 每天起床 都希望今天會是個好日子 <<<<<<------

第二天行程算是"比較"簡單ㄉ了,不過今天教的MQ"不簡單!!!",
講了一些 Message Queue Interface (MQI) 以及 Triggering,
Trigger 主要是因為以前RAM很貴,所以盡量讓Queue沒事的時候多休息,
多休息沒事,沒事多休息 ... 才不會浪費Resource的機制,
聽說現在新的規劃就比較少用到ㄌ,
但是,有一些小撇步,是不可少的,
不然,將來系統一大,再大的Resource也不夠。

上完MQ,週二ㄉ晚上就會比較輕鬆了,(一路上是這樣告訴自己ㄉ)

一回到家,開電腦,挖勒,登!登!登!
獨孤木跟王公建興 MSN 來ㄌ,說要調整新裝的三台PC Server,

話說這三台PC Server,是用來加強獨孤木的Web2.0 殺手級網站 用的,
我用了2007/11/8才剛出的 Red Hat Fedora 8 熱騰騰的版本
建興說要用 JDK6 踹,那就來裝 1.6 吧,

AaA : 會不會太慘忍了一點?
迷之音:不會!
AaA : 那 就 再 慘 忍 一 點 !!!

於是裝了

[amzshar@X5 ~]# java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)



所以我也索性配置ㄌApache 2.2.6 與 Tomcat 6.0.14讓它更發光發熱。
然而 Fedora8修改了一些設定,倒是多花了我一些時間來改我以前寫的 Shell,
不過,還好,薑還是老的辣,難不倒我~ lol
但是這樣一搞,就被搞到半夜一點多快兩點 ... Orz ...

------>>>>>> 靠夭,今天早上又被自己帥醒了! <<<<<<------

第三天,就是今天啦!
有了前兩天的教訓,今天就直接從一高下重慶北路,殺到襄陽路,
本來想說順便在館前路來個水溝蓋跑法進入停車場,
不過那邊沒有水溝蓋,也就算ㄌ,呵呵~~~

今天MQ上的是 Distributed Queue management 、MQ Cluster以及一些 SuportPac,
不過 MQ Cluster 倒是令我驚訝ㄚ,
怎麼那麼...
算了,就當我沒說,ㄎㄎㄎ,
不過,比V5.3好很多了,他們講ㄉ,不代表本人立場。

下午上到四點多結訓了,我就回到交大跟其他同學、學長、教授 meeting
=> 非同步電路設計(Asynchronous Circuit Design) 的論文研討 ...
不過今天報告ㄉ比較快,八點多就搞定ㄌ。耶!還不賴!

------>>>>>> 有人對我說 你好神 <<<<<<------

本來 Hank 跟 LH 說要吃宵夜,打ㄌ電話給他們都說剛吃飽,
好吧!五萬精兵猶存,來日再戰必勝!!! 改天再吃ㄅ~~~

那你/妳問我現在在幹嘛?當然是在寫 BLOG 囉 ... lol
阿你/妳不是正在看Blogㄇ? ㄏㄏ

等我有空玩一玩MQ,再把心得寫出來,跟大家分享與討論。

amzshar 發表在 痞客邦 留言(0) 人氣()