Archive by Author | santosh_nair

Distributed Two Way MQ Communication — Part2

Refer the Below Link for more details on Distributed MQ communication Part 1:
http://webspherepundit.com/?p=1608

Requirement : To set up a minimal steps for a Two Way MQ communication between two queue managers ie From QMC01 to QMC02 & From Qmc02 to QMC01

Architecture :
OS : Linux Redhat 5.6
MQ Version : 7.0

Infrastructure Diagram :

HighLevel Steps for Two Way Distributed Communication with Two Queue Manager :

Quick References commands for Two Way MQ Communication :

ON Queue Manager QMC01
As mqm user
—– Create the Queue Manager QMC01
bash-3.2$crtmqm QMC01—–Start Queue Manager QMC01
bash-3.2$strmqm QMC01

—–Launch MQSC prompt for QMC01
bash-3.2$runmqsc QMC01

—–Create the Transmission Queue as the same name as Dest Qmgr as a best practice
DEF QL(QMC02) REPLACE USAGE(XMITQ)

—–Create the Sender Channel from QMC01 to QMC02 where 9002 is the listening port on Dest Qmgr QMC02
DEF CHL(QMC01.QMC02) CHLTYPE(SDR) REPLACE TRPTYPE(TCP) CONNAME(‘10.0.0.20(9002)’) XMITQ(QMC02)

—–Create a Receiver channel from QMC02 to QMC01 (we are creating a two way communication)
DEF CHL(QMC02.QMC01) CHLTYPE(RCVR) REPLACE TRPTYPE(TCP)

—–Create a Local Queue as the Dead Letter Queue
DEF QL(DLQ) REPLACE

—–Modify the DEADQ attribute of qmgr to use the Qlocal created above
ALTER QMGR DEADQ(DLQ)

—–Create Listener on Qmgr QMC01 with listen port as 9001
DEFINE LISTENER(QMC01.LISTENER) TRPTYPE(TCP) PORT(9001) IPADDR(10.0.0.20)

—–Start the listener on QMC01
START LISTENER(QMC01.LISTENER)

—–DISPLAY the listener Status on QMC01
DISPLAY LSSTATUS (QMC01.LISTENER)

—–Start Sender Channel QMC01.QMC02
START CHL(QMC01.QMC02)

—–Check Ping Status
PING CHL(QMC01.QMC02)

—–Check Channel Status
DISPLAY CHSTATUS(QMC01.QMC02)
DISPLAY CHSTATUS(QMC02.QMC01)

—–Define Remote Queue Definitions (QRMT02) to Local Queue QL.A which is on QMC02
DEF QR(QRMT02) REPLACE RNAME(QL.A) RQMNAME(QMC02) XMITQ(QMC02)

—–Define Local Queue QL.B for the messages put from QMC02
DEF QL(QL.B) REPLACE

###############################################################

ON Queue Manager QMC02

—– Create the Queue Manager QMC01
bash-3.2$crtmqm QMC02

—–Start Queue Manager QMC01
bash-3.2$strmqm QMC02

—–Launch MQSC prompt for QMC01
bash-3.2$runmqsc QMC02

—–Create the Transmission Queue as the same name as Dest Qmgr as a best practice
DEF QL(QMC01) REPLACE USAGE(XMITQ)

—–Create the Sender Channel from QMC02 to QMC01 where 9001 is the listening port on Dest Qmgr QMC01
DEF CHL(QMC02.QMC01) CHLTYPE(SDR) REPLACE TRPTYPE(TCP) CONNAME(‘10.0.0.20(9001)’) XMITQ(QMC01)

—–Create a Receiver channel from QMC02 to QMC01 (we are creating a two way communication)
DEF CHL(QMC01.QMC02) CHLTYPE(RCVR) REPLACE TRPTYPE(TCP)

—–Create a Local Queue as the Dead Letter Queue
DEF QL(DLQ) REPLACE

—–Modify the DEADQ attribute of qmgr to use the Qlocal created above
ALTER QMGR DEADQ(DLQ)

—–Create Listener on Qmgr QMC02 with listen port as 9002
DEFINE LISTENER(QMC02.LISTENER) TRPTYPE(TCP) PORT(9002) IPADDR(10.0.0.20)

—–Start the listener on QMC02
START LISTENER(QMC02.LISTENER)

—–DISPLAY the listener Status on QMC02
DISPLAY LSSTATUS (QMC02.LISTENER)

—–Start Sender Channel QMC02.QMC01
START CHL(QMC02.QMC01)

—–Check Ping Status
PING CHL(QMC02.QMC01)

—–Check Channel Status
DISPLAY CHSTATUS(QMC01.QMC02)
DISPLAY CHSTATUS(QMC02.QMC01)

—–Define Local Queue QL.A for the messages put from QMC01
DEF QL(QL.A) REPLACE

—–Define Remote Queue Definitions (QRMT01) to Local Queue QL.B which is on QMC01
DEF QR(QRMT01) REPLACE RNAME(QL.B) RQMNAME(QMC01) XMITQ(QMC01)

###############################################################

###############################################################
Testing for Two Way MQ communication

—–On QMC01 Put message on QRemote QRMT02
bash-3.2$/opt/mqm/samp/bin/amqsput QRMT02 QMC01

—–On QMC02 get message on Qlocal QL.A
bash-3.2$/opt/mqm/samp/bin/amqsget QL.A QMC02

—–On QMC02 Put message on QRemote QRMT01
bash-3.2$/opt/mqm/samp/bin/amqsput QRMT01 QMC02

—–On QMC01 get message on Qlocal QL.B
bash-3.2$/opt/mqm/samp/bin/amqsget QL.B QMC01

Troubleshooting

Step 1: Ensure that Sender Channel in the Source Qmgr and Listener and Reciever Channel in the Destination Qmgr is started and running

Step 2: The Sender channel Name in the Source Qmgr the Receiver channel Name in the destination Qmgr should have the same name

Step 3: The Listener port shouldn’t be used by any other application

Step 4: Recheck the configurations done

Step 5: Check if the message is there in the transmission queue

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

Distributed MQ Channel Setup – Single Way communication

Jul17

Requirement : To set up a minimal steps for a Single way MQ communication between two queue managers ie From QMC01 to QMC02

Architecture :
OS : Linux Redhat 5.6
MQ Version : 7.0
Source Qmgr : QMC01
Destination Qmgr : QMC02 ( Both the Qmgrs on same IP)

Infrastructure Diagram :

High level Steps create the Single WAY MQ communication between QMGRs :

Destination QMGR
Step1: Create the Destination QMGR
Step2: Create Local queue where the message needs to be received
Step3: Define Listener and Start the Listener
Step4: Creating Receiver Channel with same name as the Sender channel
Step5: Start the Receiver Channel

Source QMGR
Step1: Create the qmgr
Step2: Define Transmission Queue
Step3: Creating Sender Channel
Step4: Create Remote Queue Definitions
Step5: Start the Sender Channel

######################################################################################
Detailed Steps
######################################################################################

Destination QueueManager
Step1: Create a Destination Queue Manager QMC02

bash-3.2$ crtmqm QMC02

Step2: Start the Queue Manager QMC02

bash-3.2$ strmqm QMC01

Step3: Enter the Mqsc prompt of QMC02

bash-3.2$ runmqsc QMC01

Step4: Create the Local Queue in the Dest Qmgr where the message is to be received from the Source Qmgr Qmc01

DEFINE QLOCAL(QL.A)

Step5: Define Listener for Source Qmgrs to connect to Dest Qmgrs

DEFINE LISTENER(QMC02.LISTENER) TRPTYPE(TCP) PORT(1414) IPADDR(192.168.111.128)

Step6: Start Listeners (QMC02.LISTENER) on the Dest Qmgr QMC02

START LISTENER(QMC02.LISTENER)

NOTE : Listener can be started by the command line to as mentioned below

/opt/mqm/bin/runmqlsr -r -m QMC02 -t TCP -p 1414 -i 192.168.111.128

Step7: Define the Receiver Channel CHL(QMC01.QMC02)

DEFINE CHL(QMC01.QMC02) CHLTYPE(RCVR) REPLACE TRPTYPE(TCP)

Step8: Start the Receiver Channel

START CHANNEL(QMC01.QMC02)

Step9: Display Listener Status

DISPLAY LSSTATUS (QMC02.LISTENER)

Step10: Display Receiver Channel Status

DISPLAY CHSTATUS(QMC01.QMC02)

Step11: Check if the listener is running on the Destination Qmgr server

ps -ef | grep runmqlsr

Screenshots for commands

######################################################################################

Source QueueManager
Step1: Create the source queue manager QMC01

bash-3.2$ crtmqm QMC01

Step2: Start the Queue Manager QMC01

bash-3.2$ strmqm QMC01

Step3: Enter the MQSC prompt of the QMC01

bash-3.2$ runmqsc QMC01

Step4: Create the Transmision Queue : QMC02.XMITQ

DEFINE QLOCAL(QMC02.XMITQ) REPLACE USAGE(XMITQ)

Step5: Create the Sender Channel QMC01.QMC02 with these details
a) CHLTYPE and TRPTYPE ( as we are using TCP protocol for connection )
b) CONNAME ( Use the Ip address of the Destination QMgr and the port of the Dest Listener)
c) XMITQ ( Use the Transmission Queue for the senders channel )

NOTE : The Sender Channel Name created here should be same as the Receive Channel created for the Destination QMgr QMC02

Usually the naming convention is source.to.destination for ease of understanding the infra

DEFINE CHANNEL(QMC01.QMC02) CHLTYPE(SDR) REPLACE TRPTYPE(TCP) CONNAME(‘192.168.111.128(1414)’) XMITQ(QMC02.XMITQ)

Step6: Define the Remote Queue Definitions with Remote Queue Name and Remote Qmgr Name

DEFINE QREMOTE(QRMT02) RNAME(QL.A) RQMNAME(QMC02) XMITQ(QMC02.XMITQ)

Step7: Start the Sender Channel QMC01.QMC02
NOTE: As the receiver channel is still not created and started, … the sender channel will still not be in the running status

START CHANNEL(QMC01.QMC02)

Step8: Display the Channel Status QMC01.QMC02

display chstatus(QMC01.QMC02)

Screenshots for commands

######################################################################################

Testing

######################################################################################

Step1: Ensure that the listeners is started and running on the Dest Qmgr Server QMC02

START LISTENER(QMC02.LISTENER)

Step2: Check the Status of Listeners on Qmgr QMC02

DISPLAY LSSTATUS (QMC02.LISTENER)

Step3: Ensure the Receiver channel is started on the Destination Qmgr Server QMC02

START CHANNEL(QMC01.QMC02)

Step4: Display the Receiver Channel Status on the Destination Qmgr Server QMC02

DISPLAY CHSTATUS(QMC01.QMC02)

Step5: Ensure that the Sender Channel is started and running on the Source Qmgr Server QMC01

START CHANNEL(QMC01.QMC02)

Step6: Display the channel Status QMC01.QMC02 on the Source Qmgr Server QMC01

DISPLAY CHSTATUS(QMC01.QMC02)

Step7: Check the Queue Depth of the Dest Queue ie QL.A

bash-3.2$echo “DISPLAY QLOCAL(QL.A) CURDEPTH ” | runmqsc QMC02 | grep CURDEPTH

Step8: Put the message in the Source Qmgr using the “./amqsput [Remote Queue Def] [Source Qmgr] “

bash-3.2$/opt/mqm/samp/bin/amqsput QRMT02 QMC01

MQcommunication5

I put the message “This is a Remote Test” in the Remote Queue Definition QRMT02 in the source Qmgr QMC01 .

So if the configurations are proper then this message should be received by the Destination Queue QL.A on Qmgr QMC02

So the Message would flow internally from

Step9: View the Queue Depth of Destination Queue QL.A

bash-3.2$echo “DISPLAY QLOCAL(QL.A) CURDEPTH ” | runmqsc QMC02 | grep CURDEPTH

MQcommunication6

The Message has successfully arrived at the destination Queue ie QL.A

Step10: Browser the messages from the QL.A using “./amqsgbr [Dest Queue] [Dest Qmgr]” or get the message using “./amqsget [Dest Queue] [Dest Qmgr]”

bash-3.2$/opt/mqm/samp/bin/amqsgbr QL.A QMC02

Put some messages form the Source Qmgr and see if the messages is recived in the Destination Qmgrs and in Queue specified

######################################################################################

Troubleshooting

######################################################################################

Step1: Ensure that Sender Channel in the Source Qmgr and Listener and Reciever Channel in the Destination Qmgr is started and running

Step2: The Sender Channel Name in the Source Qmgr and the Receiver Channel Name in the destination Qmgr should have the same Name

Step3: The Listener port shouldn’t be used by any other application

Step4: Recheck the configurations done

Step5: Check if the message is there in the transmission queue

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

Quick Reference For MQ Triggering

Jul16

For More detailed information MQ TRIGGERING click below

http://webspherepundit.com/?p=1605

These are the quick references for setting up simple TRIGGERING with few different examples for FIRST , EVERY and DEPTH Modes

Example1 :To start the http process on a First message put in the Queue

NOTE : The method to stop/start http as mqm is not covered in this tutorial .
Http Process is just used for example .. you can use any process as per your requirement ( Ensure that mqm user should be able to stop/start those processes)

——- Start QMgr
bash-3.2$ strmqm QMC01
bash-3.2$ runmqsc QMC01

——- Create Initiation Queue
DEFINE QL(TRIGGER.INITIATION.QUEUE) like SYSTEM.DEFAULT.INITIATION.QUEUE

——- Create Local Queue with Triggering Options with TRIGTYPE(FIRST)
DEFINE QLOCAL(TRIGGER.Q) TRIGGER TRIGDPTH(1) TRIGTYPE(FIRST) INITQ(TRIGGER.INITIATION.QUEUE) PROCESS(TRIG.PROCESS)

——- Create Process with APPLICID ( /etc/init.d/httpd start ) It can be any process as per env
DEFINE PROCESS (‘TRIG.PROCESS’) APPLTYPE(UNIX) APPLICID(‘/etc/init.d/httpd start’)

——- Display QueueDepth before testing to ensure there are no messages in the QUEUE
bash-3.2$ echo “DISPLAY QL(TRIGGER.Q) CURDEPTH TRIGGER ” | runmqsc QMC01

——- Run runmqtrm command on the Initiation Queue
bash-3.2$ runmqtrm -m QMC01 -q TRIGGER.INITIATION.QUEUE

——- Put Messages using amqsput
bash-3.2$/opt/mqm/sampl/bin/amqsput TRIGGER.Q QMC01

——- On the first message put to the QUEUE the triggering would be fired , view the putty console where runmqtrm is running .. here we will see if the trigger event is run and triggering invoked and http process started

——- Display QueueDepth
bash-3.2$ echo “DISPLAY QL(TRIGGER.Q) CURDEPTH TRIGGER ” | runmqsc QMC01

——- Check if the http Process is saterted by the just putting the Message in Queue
bash-3.2$ps –ef | grep http

Example2: Enable triggering to start a unix script with a receipt of a message .
In this example we will be running a script instead of starting a process with trigerring set for FIRST( ie On the arrival of the first message )

——- Make the script executable
bash-3.2$ chmod 755 /var/mqm/testscript.sh

——- Start Queue Manager
bash-3.2$ strmqm QMC01
bash-3.2$ runmqsc QMC01

——- Create an Initiation Queue
DEFINE QL(TRIGGER.INITIATION.QUEUE) like SYSTEM.DEFAULT.INITIATION.QUEUE

——- Create a Local Queue where Triggering is enabled with TRIGTYPE(FIRST)
DEFINE QLOCAL(TRIGGER.Q) TRIGGER TRIGDPTH(1) TRIGTYPE(FIRST) INITQ(TRIGGER.INITIATION.QUEUE) PROCESS(TRIG.PROCESS)

——- Create Process with APPLICID /var/mqm/testscript.sh ie run testscript.sh on triggering
DEFINE PROCESS (‘TRIG.PROCESS’) APPLTYPE(UNIX) APPLICID(‘/var/mqm/testscript.sh‘)

——- Run runmqtrm command for the Initiation Queue
bash-3.2$ runmqtrm -m QMC01 -q TRIGGER.INITIATION.QUEUE

——- Display QueueDepth before testing to ensure there are no messages in the QUEUE
bash-3.2$ echo “DISPLAY QL(TRIGGER.Q) CURDEPTH TRIGGER ” | runmqsc QMC01 | grep CURDEPTH

——- Put Messages using amqsput
bash-3.2$/opt/mqm/sampl/bin/amqsput TRIGGER.Q QMC01

——- On the first message put to the QUEUE the triggering would be fired and and the script testscript.sh is run . view the putty console where runmqtrm is running .. here we will see if the trigger event is run and triggering invoked
Also The script.log will let us know if it has run properly and triggering invoked.

——- Display QueueDepth
bash-3.2$ echo “DISPLAY QL(TRIGGER.Q) CURDEPTH TRIGGER ” | runmqsc QMC01 | grep CURDEPTH

——- Check the script.log for ensuring the testscript.sh has run properly due to triggering
bash-3.2$tail -f /var/mqm/script.log

Example3 :We will Test the Triggering method for EVERY Message instead of the FIRST message entering the Trigger queue

——- Create a script when run will browse the message using amqsgbr and redirect to a script.log
bash-3.2$ vi /var/mqm/testscript.sh
############################
echo `date` >> /var/mqm/script.log
/opt/mqm/samp/bin/amqsgbr TRIGGER.Q QMC01 | grep “[1-9] <” >> /var/mqm/script.log
echo “==========================” >> /var/mqm/script.log
############################——- Make the script executable
bash-3.2$ chmod 755 /var/mqm/testscript.sh——- Start Queue Manager
bash-3.2$ strmqm QMC01
bash-3.2$ runmqsc QMC01——- Create an Initiation Queue
DEFINE QL(TRIGGER.INITIATION.QUEUE) like SYSTEM.DEFAULT.INITIATION.QUEUE

——- Create Process with APPLICID /var/mqm/testscript.sh ie run testscript.sh on triggering
DEFINE PROCESS (‘TRIG.PROCESS’) APPLTYPE(UNIX) APPLICID(‘/var/mqm/testscript.sh‘)

——- Create a Local Queue where Triggering is enabled with TRIGTYPE(EVERY)
ALTER QLOCAL(TRIGGER.Q) TRIGGER TRIGDPTH(1) TRIGTYPE(EVERY) INITQ(TRIGGER.INITIATION.QUEUE) PROCESS(TRIG.PROCESS)

——- Run runmqtrm command for the Initiation Queue
bash-3.2$ runmqtrm -m QMC01 -q TRIGGER.INITIATION.QUEUE

——- Display QueueDepth before testing to ensure there are no messages in the QUEUE
bash-3.2$ echo “DISPLAY QL(TRIGGER.Q) CURDEPTH TRIGGER ” | runmqsc QMC01 | grep CURDEPTH

——- Put Messages using amqsput , Put 3 messages to test
/opt/mqm/sampl/bin/amqsput TRIGGER.Q QMC01

——- For every Message put in the Queue TRIGGER.Q , a trigger event would start and the script would run 3 times and the output captured in script.log . View the putty console where runmqtrm is running .. here we will see if the trigger event is run and triggering invoked

——- Display QueueDepth before testing to ensure there are no messages in the QUEUE
bash-3.2$ echo “DISPLAY QL(TRIGGER.Q) CURDEPTH TRIGGER ” | runmqsc QMC01 | grep CURDEPTH

——- Check the script.log for ensuring the testscript.sh has run properly due to triggering
bash-3.2$tail -f /var/mqm/script.log

Example4 :We will test the triggering for the Depth of the Queue ie when the QUEUE Depth reaches the defined setting a triggering should be fired

——- Make the script executable
bash-3.2$ chmod 755 /var/mqm/testscript.sh

——- Start Queue Manager
bash-3.2$ strmqm QMC01
bash-3.2$ runmqsc QMC01——- Create an Initiation Queue
DEFINE QL(TRIGGER.INITIATION.QUEUE) like SYSTEM.DEFAULT.INITIATION.QUEUE

——- Create Process with APPLICID /var/mqm/testscript.sh ie run testscript.sh on triggering
DEFINE PROCESS (‘TRIG.PROCESS’) APPLTYPE(UNIX) APPLICID(‘/var/mqm/testscript.sh‘)

——- Create a Local Queue where Triggering is enabled
ALTER QLOCAL(TRIGGER.Q) TRIGGER TRIGDPTH(3) TRIGTYPE(DEPTH) INITQ(TRIGGER.INITIATION.QUEUE) PROCESS(TRIG.PROCESS)

——- Run runmqtrm command for the Initiation Queue
bash-3.2$ runmqtrm -m QMC01 -q TRIGGER.INITIATION.QUEUE

——- Display QueueDepth before testing to ensure there are no messages in the QUEUE
bash-3.2$ echo “DISPLAY QL(TRIGGER.Q) CURDEPTH TRIGGER ” | runmqsc QMC01 | grep CURDEPTH

——- Put 3 Messages in the TRIGGER.Q using amqsput
/opt/mqm/sampl/bin/amqsput TRIGGER.Q QMC01

——- Display QueueDepth before testing to ensure there are no messages in the QUEUE
bash-3.2$ echo “DISPLAY QL(TRIGGER.Q) CURDEPTH TRIGGER ” | runmqsc QMC01 | grep CURDEPTH

——- Only onces the Depth of the QUEUE has reached to the TRIGDPTH ie “3” messages the triggering will be invoked. It can be seen from the putty console of “runmqtrm” and also visible from the /var/mqm/script.log the triggering result

——- Check the script.log for ensuring the testscript.sh has run properly due to queue depth triggering
bash-3.2$tail -f /var/mqm/script.log

——- After the triggering is fired the Triggering for the QUEUE “TRIGGER.Q” in the Example , It gets disabled ..

——- It needs to be Re-Enabled using below command or use MQSET to renable the TRIGERR from the Application.

——- So for every time trigger is invoked due to QUEUE DEPTH ( TRIGDPTH ) the Triggering needs to be enabled again

——- Reenable the Triggering for the TRIGGER.Q
bash-3.2$ echo “ALTER QLOCAL(TRIGGER.Q) TRIGGER ” | runmqsc QMC01

Example4 :Runmqtrm as a SERVICE

——- Start Queue Manager
bash-3.2$ strmqm QMC01
bash-3.2$ runmqsc QMC01

——- Define Service for TRIGGER Monitor
DEFINE SERVICE(TRIGMON) CONTROL(QMGR) SERVTYPE(SERVER) +
STARTCMD(‘+MQ_INSTALL_PATH+bin/runmqtrm’) +
STARTARG(‘-m +QMNAME+ -q SYSTEM.DEFAULT.INITIATION.QUEUE’) +
STOPCMD(‘+MQ_INSTALL_PATH+bin/amqsstop’) +
STOPARG(‘-m +QMNAME+ -p +MQ_SERVER_PID+’) STDOUT(‘/tmp/TrigMon.stdout’) +
STDERR(‘/tmp/TrigMon.stderr’)

——- Start the Service
START SERVICE(TRIGMON)

——- View the Services attributes
DISPLAY SVSTATUS(TRIGMON)

——- Triggering Std Out and Error
bash-3.2$ ls -lt /tmp/Trig*
-rw-r–r– 1 mqm mqm 239 2014-03-20 13:18 /tmp/TrigMon.stdout
-rw-r–r– 1 mqm mqm 0 2014-03-20 13:18 /tmp/TrigMon.stderr

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

Create Cell, Custom, Dmgr & App Server Profile in WebSphere with ManageProfile

Jun23

NOTE:
a) Ensure that necessary permissions are available for the user running manageprofile.sh
b) Ensure that the filesystem has sufficient space for the creation of the profile
c) Please select the appropriate ProfileName , Directory path , CellName, NodeName etc as per your requirement

Cell Profile :
1) Cell profiles are actually two profiles in one profile creation method .
2) It has a deployment manager profile and a federated application server profile.
3) The federation is also automatically done by the profile creation wizard
4) An Application sever “server1” is also created by default
5) The profile can be created on the same host only and cannot span multiple physical servers
6) Its used to create a fast dev or a test environment for the development team

Steps to create a Cell Profile:
Step1 : Navigate to WAS_HOME/bin directory

[root@mercury MyServer]# cd /opt/IBM/WebSphere/AppServer/bin

Execute ./manageprofile.sh

Cell Profile with Minimal Parameters

[root@mercury bin]#./manageprofiles.sh -create -profileName Dmgr02 -adminUserName wasadmin -adminPassword p@ssword -enableAdminSecurity true -cellName mercuryCell01 -nodeName mercuryCellManager01 -profilePath /opt/IBM/WebSphere/AppServer/profiles/Dmgr02 -nodeProfilePath /opt/IBM/WebSphere/AppServer/profiles/AppSrv01 -appServerNodeName mercuryNode02 -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/cell/dmgr

Cell Profile with advanced options ( Custom Ports , Certificates )

[root@mercury bin]#./manageprofiles.sh -create -profileName Dmgr02 -adminUserName p@sswordwasadmin -adminPassword p@ssword -nodePortsFile /opt/IBM/WebSphere/AppServer/logs/manageprofiles/123_cellNode_portdef.props -enableAdminSecurity true -cellName mercuryCell01 -nodeName mercuryCellManager01 -portsFile /opt/IBM/WebSphere/AppServer/logs/manageprofiles/123_cellDmgr_portdef.props -personalCertDN cn=mercury.com,ou=mercuryCell01,ou=mercuryCellManager01,o=IBM,c=US -profilePath /opt/IBM/WebSphere/AppServer/profiles/Dmgr02 -nodeProfilePath /opt/IBM/WebSphere/AppServer/profiles/AppSrv01 -appServerNodeName mercuryNode02 -enableService false -signingCertDN cn=mercury.com,ou=Root Certificate,ou=mercuryCell01,ou=mercuryCellManager01,o=IBM,c=US -hostName mercury.com -personalCertValidityPeriod 1 -signingCertValidityPeriod 15 -keyStorePassword WEBAS -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/cell/dmgr

Step2: Checks to ensure proper profile creation
a) Should get an INSTCONSUCCESS message for manageprofile in the <WAS_HOME>/logs/manageprofiles/<ProfileName>_create.log
b) Navigate to the dmgr and appserver profile folders ie /opt/IBM/WebSphere/AppServer/profiles/Dmgr02 & /opt/IBM/WebSphere/AppServer/profiles/AppSrv01
c) Get the admin console ports from AboutThisProfile.txt or serverindex.xml file for dmgr
d) Start the DMgr, Nodeagent and the server1
e) Check the logs for errors
=====================================================================================
=====================================================================================

Custom Profile
1) A custom profile defines an empty node on a system.
2) The main purpose of this profile is to define a node on a system which can be federated to a cell for management using the DMGR.
3) This profile needs to be federated to the dmgr cell during the profile creation or later using “./addNode.sh dmgr_host soap_port”
4) Before you can federate the custom profile to a cell, you will need to have a running deployment manager.

Steps to create a Custom Profile

Step1 : Navigate to WAS_HOME/bin directory

[root@mercury MyServer]# cd /opt/IBM/WebSphere/AppServer/bin

Execute ./manageprofile.sh

[root@mercury bin]# ./manageprofiles.sh -create -defaultPorts -profileName Custom01 -profilePath /opt/IBM/WebSphere/AppServer/profiles/Custom01 -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/managed -hostName mercury.com -nodeName mercuryNode01 -federateLater true

Step2: Checks to ensure proper profile creation
a) Should get an INSTCONSUCCESS message for manageprofile in the <WAS_HOME>/logs/manageprofiles/<ProfileName>_create.log
b) Navigate to the /opt/IBM/WebSphere/AppServer/profiles/Custom01
c) Federate the Custom Profile node to the dmgr cell using “./addNode.sh dmgr_host soap_port”
d) Create Application Servers from the dmgr admin console

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

Deployment Manager Profile

1) The DMGR is a single administration in websphere application server,
2) Whenever we create a dmgr by default we will get one node, cell and adminconsole,
3) It is mainly used to do the administrative and configuration activities.
4) The application and cutom server profile has to be federate with the dmgr,
5) Once federation process has been done we can manage the servers from dmgr admin console

Steps to create a Deployment Manager Profile

Step1 : Navigate to WAS_HOME/bin directory

[root@mercury MyServer]# cd /opt/IBM/WebSphere/AppServer/bin

Execute ./manageprofile.sh

[root@mercury bin]# ./manageprofiles.sh -create -profileName Dmgr01 -profilePath /opt/IBM/WebSphere/AppServer/profiles/Dmgr01 -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/management -serverType DEPLOYMENT_MANAGER -cellName Cell01 -nodeName Dmgr01 -hostName mercury.com -enableAdminSecurity true -adminUserName wasadmin -adminPassword passw0rd

Step2 : Checks to ensure proper profile creation
a) Should get an INSTCONSUCCESS message for manageprofile in the <WAS_HOME>/logs/manageprofiles/<ProfileName>_create.log
b) Navigate to the /opt/IBM/WebSphere/AppServer/profiles/Dmgr01
c) Start Dmgr using ./startManager.sh from /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin
d) Check logs for Error

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

Application Server Profile
1) This Profile is used to create a stand alone application server .
2) It will have its independent runtime JVM environment where we can deploy the application etc
3) This Profile can be later federated a DMGR cell to become part of a bigger deployment environment

Steps to create a Application Server Profile

Step1 : Navigate to WAS_HOME/bin directory

root@mqnode bin]#cd /opt/IBM/WebSphere/AppServer/bin

Execute ./manageprofile.sh

[root@mercury bin]# ./manageprofiles.sh -create -profileName MYPROFILE -profilePath /appprofiles/MYPROFILE -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/default -serverName TEST_SERVER -nodeName MYPROFILENode1 -hostName mercury.com -enableAdminSecurity true -adminUserName wasadmin -adminPassword wasadmin@12

Step2: Checks to ensure proper profile creation
a) Should get an INSTCONSUCCESS message for manageprofile in the <WAS_HOME>/logs/manageprofiles/<ProfileName>_create.log
b) Navigate to the profile folder ie /appprofiles/MYPROFILE
c) Start application server using ./startServer.sh TEST_SERVER
d) Check SystemOut.logs for Error

More details on Application Server profile Click here
http://webspherepundit.com/?p=1242

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

Setting up MQ Triggerring

Jun10

MQ Triggering
WebSphere MQ provides a feature that enables an application or channel to be started automatically when there are messages available to retrieve from a queue

1) A message is put to a queue defined as triggered.
2) If a series of conditions are met, the queue manager sends a trigger message to an initiation queue.
3) This is called a trigger event.
4) A trigger monitor reads the trigger message and takes the appropriate action based on the contents of the message, which is typically to start a program to process the triggered queue.
5) Trigger monitors may be built-in or user defined

Some links for more elaborate details on triggering
https://hursleyonwmq.wordpress.com/2007/02/09/triggering-checklist/
http://blog.niklasottosson.com/?p=598
http://www-01.ibm.com/support/docview.wss?uid=swg27039569
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg27008375
http://www-01.ibm.com/support/docview.wss?uid=swg27041673&aid=1

Types of triggering:
1. Channel Triggering
2. Application Triggering
3. Client Triggering

Modes of Triggering
Trigger on first message- Call a program when depth of queue goes from 0 to 1
Trigger on every message- Call a program for every message entering the queue
Trigger on depth- Call a program when depth of queue gets to a certain number like on 10 messages

In this tutorial I will display the minimal steps to start the application triggering

High level steps for Application triggering
a) Create an initiation queue or use the default SYSTEM.DEFAULT.INITIATION.QUEUE.
b) Create a process definition.
c) Create or alter a local or model queue.
d) Associate the initiation queue and process definition with the local queue, and specify the trigger attributes .

Environment Details :
MQ Version : 7.0
OS : Redhat Linux
TYPE : Application Triggering
MODE : FIRST,EVERY,DEPTH

For a QUICK REFERENCE on TRIGGERING refer to http://webspherepundit.com/?p=1699

######################################################################################
######################################################################################

Example 1
Trigerring Scenario : To start the http process on a First message put in the Queue

Assumption
a) The http process can be started an stopped using mqm user ( the method to stop/start http as mqm is not covered in this tutorial .. may be for some other day
NOTE : It can be any process/script which you want to start , I used it to get the proper understanding of starting a process using trigerring
b) Your queue manager is created and started
NOTE : create a queue manager : crtmqm QMC01
Start the queue manager : strmqm QMC01

Step1 : Start the queue manager QMC01
As user mqm .. start the queue manager QMC01

bash-3.2$ strmqm QMC01

Step2 : Launch the MQSC prompt for the queue manager QMC01 using runmqsc

bash-3.2$ runmqsc QMC01

Step3 : Initiation Queue : Create an Initiation queue which the trigger monitor process will monitor

DEFINE QL(TRIGGER.INITIATION.QUEUE) like SYSTEM.DEFAULT.INITIATION.QUEUE

Step4 : Local Queue with Trigerring: Define a Local queue where you want the triggering to be set

NOTE : We will set the MODE as FIRST ie on the First message which the queue receives the trigger will be enabled and for the subsequent message the trigger will not be fired

DEFINE QLOCAL(TRIGGER.Q) TRIGGER TRIGDPTH(1) TRIGTYPE(FIRST) INITQ(TRIGGER.INITIATION.QUEUE) PROCESS(TRIG.PROCESS)

Step5 : Process Definition : Define the Process which needs to be started by the trigger
In this case its ‘/etc/init.d/httpd start’

DEFINE PROCESS (‘TRIG.PROCESS’) APPLTYPE(UNIX) APPLICID(‘/etc/init.d/httpd start’)

Complete Sample

Testing for Example 1
Step1 : Stopping httpd as mqm to simulate the testing

Step2 : Check the Message depth of the Trigger Queue .. it will be zero now

bash-3.2$ echo “DISPLAY QL(TRIGGER.Q) CURDEPTH TRIGGER ” | runmqsc QMC01

Step3 : Start the MQ triggering Process which will monitor the initiation queue

bash-3.2$ runmqtrm -m [QMGR Name] -q [INITIATION QUEUE]

It can be run in the background using

bash-3.2$ runmqtrm -m [QMGR Name] -q [INITIATION QUEUE] &

runmqtrm can be run as a service too in MQ & It will be covered later in this blog

bash-3.2$ runmqtrm -m QMC01 -q TRIGGER.INITIATION.QUEUE

Step4 :
Open another Putty session and Put the Message to the TRIGGER.Q and see the response of the runmqtrm on the other session
Put a message in TRIGGER.Q using ./amqsput TRIGGER.Q

Step5 : Check the TRIGGER.Q depth count it will be “1”

bash-3.2$ echo “DISPLAY QL(TRIGGER.Q) CURDEPTH TRIGGER ” | runmqsc QMC01

mqtriggering10

Step6 : Check the http process .. it should be started now using ps –ef | grep http

######################################################################################
######################################################################################

Example 2
Trigerring Scenario : Enable triggering to start a unix script with a receipt of a message

In this example we will be running a script instead of starting a process with trigerring set for FIRST( ie On the arrival of the first message )

Step1 : Create a test script as per the sample below (It can be any script of your choice)
This script will use amqsgbr output and send it to a file /var/mqm/script.log

Create a script file testscript.sh

bash-3.2$ vi /var/mqm/testscript.sh
############################
echo `date` >> /var/mqm/script.log
/opt/mqm/samp/bin/amqsgbr TRIGGER.Q QMC01 | grep “[1-9] <” >> /var/mqm/script.log
echo “==========================” >> /var/mqm/script.log
############################

mqtriggering12

Step2 : Change the permission to make it executable

bash-3.2$ chmod 755 /var/mqm/testscript.sh

Step3 : Testing the script : Test this script works

bash-3.2$ cd /opt/mqm/samp/bin
bash-3.2$ ./amqsput TRIGGER.Q QMC01
Sample AMQSPUT0 start
target queue is TRIGGER.Q
This is Script TestSample AMQSPUT0 end
bash-3.2$bash-3.2$ /var/mqm/testscript.sh
bash-3.2$
bash-3.2$ tail -f /var/mqm/script.log
Thu Jun 11 12:47:23 IST 2015

Enabling Triggering to run this script

Now that we know the script works , Put it for triggering

Step1 : We will use the same example1 only we will alter the process definition with APPLICID(‘ /var/mqm/testscript.sh’)
we will alter APPLICID(‘/etc/init.d/httpd start’)” with APPLICID(‘ /var/mqm/testscript.sh’)

ALTER PROCESS (‘TRIG.PROCESS’) APPLTYPE(UNIX) APPLICID(‘/var/mqm/testscript.sh’)

Step2 : Check the Queue Depth of Trigger Queue .. IT should be “Zero”

bash-3.2$ echo “DISPLAY QL(TRIGGER.Q) CURDEPTH TRIGGER ” | runmqsc QMC01 | grep CURDEPTH

Step3 : Run the “runmqtrm” command

bash-3.2$ runmqtrm -m QMC01 -q TRIGGER.INITIATION.QUEUE

Testing for Example 2

NOTE: use ./amqsget TRIGGER.Q or CLEAR TRIGGER.Q to clear the messages in TRIGGER.Q before starting the test

Step1: Put a message in the TRIGGER.Q

mqtriggering16

Step2 : View the runmqtrm console

Step3 : Tail the script has run by seeing the logs

Now even if we put more messages in the Queue TRIGGER.Q the trigger will only happen once ( ie the First message ie when the Queue Depth goes from Zero to One .

For eg : The initial queue depth of “TRIGGER.Q” is zero .. Then I put 3 messages in it

mqtriggering20

mqtriggering22

But with the runmqtrm we see that the script only ran only ONCE.

mqtriggering21

With this we have simulated a situation wherein the only the first message to a queue ( Queue depth Zero to One) will trigger the script to run

######################################################################################

Example 3

Trigerring Scenario : We will Test the Trigerring method for EVERY Message instead of the FIRST message entering the Trigger queue.
I will use the same object created in the previous Example 2

bash-3.2$ runmqsc QMC01

Step1 : Alter the Definitions of the TRIGGER.Q with TRIGTYPE(EVERY)

ALTER QLOCAL(TRIGGER.Q) TRIGGER TRIGDPTH(1) TRIGTYPE(EVERY) INITQ(TRIGGER.INITIATION.QUEUE) PROCESS(TRIG.PROCESS)

Step2 : Run the runmqtrm for the Initiation Queue

bash-3.2$ runmqtrm -m QMC01 -q TRIGGER.INITIATION.QUEUE

Testing for Example 3

Step1 : Check the Current Depth of the TRIGGER.Q its “Zero”
NOTE: use ./amqsget TRIGGER.Q or CLEAR TRIGGER.Q to clear the messages in TRIGGER.Q

Step2 :Clear the script logs

Step3 :Put 4 messages using amqsput TRIGGER.Q . So if our configurations are corrent for each message the trigger monitor will execute the testsctipt.sh

Step4 :Check the output of the trigger ie runmqtrm. You will see for each message the testscript.sh is run

Step5 : Check the Logs to ensure the script has run for each trigger

bash-3.2$ tail -f /var/mqm/script.log

bash-3.2$ echo “DISPLAY QL(TRIGGER.Q) CURDEPTH TRIGGER ” | runmqsc QMC01 | grep CURDEPTH

######################################################################################

Example 4
Trigerring Scenario : We will test the triggering for the Depth of the Queue ie when the QUEUE Depth reaches the defined setting a triggering should be fired

We will use the same Example 2 for this test

Step1 : Clear the queue TRIGGER.Q of the messages

bash-3.2$ ./amqsget TRIGGER.Q QMC01
bash-3.2$ >/var/mqm/script.log

mqtriggering32

Step2 : Alter the Queue definitions for TRIGDPTH(3) TRIGTYPE(DEPTH)

ALTER QLOCAL(TRIGGER.Q) TRIGGER TRIGDPTH(3) TRIGTYPE(DEPTH) INITQ(TRIGGER.INITIATION.QUEUE) PROCESS(TRIG.PROCESS)

mqtriggering33

Step3 : Run the runmqtrm for the Initiation Queue

bash-3.2$ runmqtrm -m QMC01 -q TRIGGER.INITIATION.QUEUE

Testing for Example 4

Step1 : Put 3 messages in the Queue TRIGGER.Q .. Observe that until we put 3 messages in the TRIGGER.Q the triggering is not fired

Step2 :The trigger is run only one when the Queue Depth reaches 3 messages
Check the output of the script which writes to the logs script.log to ensure that the script has run only once when the Depth is 3

One thing to observe is that once the triggering is fired for TRIGTYPE( DEPTH) the triggering is disabled for the Queue

Here we can see that the Triggering is disabled “NOTRIGGER” onces the triggering is fired

mqtriggering39

We need to enable TRIGGERING Again for the TRIGGER.Q as below

bash-3.2$ echo “ALTER QLOCAL(TRIGGER.Q) TRIGGER ” | runmqsc QMC01

NOTE : An Application can use MQSET within it to re-enable the Triggering the QUEUE

######################################################################################

Runmqtrm as a SERVICE

Instead of running runmqtrm from the putty prompt , A better way to runmqtrm is as a service
Step1 : Define Service

DEFINE SERVICE(TRIGMON) CONTROL(QMGR) SERVTYPE(SERVER) +
STARTCMD(‘+MQ_INSTALL_PATH+bin/runmqtrm’) +
STARTARG(‘-m +QMNAME+ -q SYSTEM.DEFAULT.INITIATION.QUEUE’) +
STOPCMD(‘+MQ_INSTALL_PATH+bin/amqsstop’) +
STOPARG(‘-m +QMNAME+ -p +MQ_SERVER_PID+’) STDOUT(‘/tmp/TrigMon.stdout’) +
STDERR(‘/tmp/TrigMon.stderr’)

Step2 :Start the Service

START SERVICE(TRIGMON)

Step3 :View the Services attributes

DISPLAY SVSTATUS(TRIGMON)

Step4 : Notice that the output files defined for the trigger monitor are created:

STDOUT(‘/tmp/TrigMon.stdout’)
STDERR(‘/tmp/TrigMon.stderr’)

Step5 : List the OutPut files

bash-3.2$ ls -lt /tmp/Trig*
-rw-r–r– 1 mqm mqm 239 2014-03-20 13:18 /tmp/TrigMon.stdout
-rw-r–r– 1 mqm mqm 0 2014-03-20 13:18 /tmp/TrigMon.stderr

bash-3.2$ cat /tmp/TrigMon.stdout
5724-H72 (C) Copyright IBM Corp. 1994, 2011. ALL RIGHTS RESERVED.
03/20/2014 01:18:24 PM : WebSphere MQ trigger monitor started.
__________________________________________________
03/20/2014 01:18:25 PM : Waiting for a trigger message

At this point, notice that the trigger monitor has not handled any messages yet:

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

Deploy / Config Changes when the Websphere DMGR is Down

Jun6

There could be instances when your Websphere Deployment Manager server is crashed / down due any reasons .
It could be due to
a) Hardware issues
b) OS issues
c) Filesystem corruption
d) Configuration Issues etc ..

Consider a scenario wherein your DMGR is down, and at the same time there is an urgent configuration change / deployment / upgrade you need to do to your application .

In this case you may need to do the changes directly to the Application server node using wsadmin commands

NOTE : This is not a recommended way

NOTE : WHENEVER THE DMGR IS UP AND RUNNING THE CHANGES WILL BE LOST DURING THE NODE SYNC Process .

NOTE :Once the DMGR is started, you would need to make the changes which you made on Application Server again to the DMGR and do a complete Sync

NOTE :For a Clustered Environment ,, the below changes needs to be one on each of the Cluster Nodes

Following are the highlevel steps to deploy the application when the DMGR is down

Step 1 : To simulate that scenario of DMGR Crashed, I have stopped the DMGR using ./stopManager.sh

And the Application Servers is started

Step 2 : Login to the Application Server Node as the owner of the WAS installation .

Step 3 : Launch the wsadmin.sh from the APP_SRV_PROFILE/bin

[root@mercury bin]# cd /opt/IBM/WebSphere/AppServer/profiles/Custom01/bin

Execute wsadmin.sh

[root@mercury bin]# ./wsadmin.sh

We will get an Error
“WASX7023E: Error creating “SOAP” connection to host “mercury.com”; exception information: com.ibm.websphere.management.exception.ConnectorNotAvailableException: [SOAPException: faultCode=SOAP-ENV:Protocol; msg=; targetException=java.net.MalformedURLException]”

The reason being that the wsadmin.properties file in the /opt/IBM/WebSphere/AppServer/profiles/Custom01/properties folder still refers to the DMGR hostname and DMGR Soap Port

We need to modify the values of the com.ibm.ws.scripting.port and com.ibm.ws.scripting.host values to match the hostname of Application Server Node

Step 4 : Modify the wsadmin.properties file

[root@mercury bin]# cd /opt/IBM/WebSphere/AppServer/profiles/Custom01/properties

Edit the wsadmin.properties

[root@mercury properties]# vi wsadmin.properties

Currently the port 8879 is the SOAP port of the DMGR ..

Change the com.ibm.ws.scripting.port and com.ibm.ws.scripting.host values to the values of the Application Server Node

Here 8884 is the Soap Port of My application Server “MyServer”

Save the Changes in the wsadmin.properties file

Step 5 : Now execute the wsadmin.sh from the Application Server Node

[root@mercury properties]# cd /opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/

[root@mercury properties]# ./wsadmin.sh -lang jython -conntype NONE

Step 6 : Deploy the application using wsadmin
In the wsadmin Prompt execute the below command . The DefaultApplication.ear is located in /opt/IBM/WebSphere/AppServer/installableApps/

NOTE : You can use wsadmin interactive Steps to deploy the application too

wsadmin>AdminApp.install(‘/opt/IBM/WebSphere/AppServer/installableApps/DefaultApplication.ear’, ‘[-server MyServer]’)

Save the configurations using AdminConfig.save

wsadmin>AdminConfig.save()

NOTE : You can use wsadmin commands to manipulate other configurations also of the Application Server

NOTE : These changes will get lost when the dmgr is started

Step 7 : Ensure the wc_default and wc_default_secure port of Application Server is available in the virtualhost.xml .

On the Application Server Node

[root@mercury properties]# cd /opt/IBM/WebSphere/AppServer/profiles/Custom01/config/cell/Cell01

Search for wc_default port in virtualhost.xml

[root@mercury properties]# cat virtualhost.xml | grep 9082

Search for wc_default_secure port in virtualhost.xml

[root@mercury properties]# cat virtualhost.xml | grep 9445

Where 9082 & 9445 are wc_default and wc_default_secure port of the Applicatioin server “MyServer”

NOTE : If the wc_default and wc_default_secure port of your Application Server is not present in the virtualhost.xml you will get the error
“A WebGroup/Virtual Host to handle /snoop has not been defined
SRVE0255E: A WebGroup/Virtual Host to handle localhost:80 has not been defined.”

Step 8 : Start the applications using wsadmin or Restart the application server .. depending on the changes which you have done

[root@mercury properties]# cd /opt/IBM/WebSphere/AppServer/profiles/Custom01/bin

[root@mercury bin]# ./stopServer.sh MyServer

[root@mercury bin]# ./startServer.sh MyServer

Step 9 : Validate if the application has been deployed only to the application node and not the DMGR .

Validation 1 : Check the Application Server SystemOut.log after the Application server / Application is started.

Check the systemOut.log to see if the Application DefaultApplication has started properly .

Also check if the web containers are mapped to the proper ports ..
Refer the screenshot of SystemOut.log

Validation 2 : Check the serverindex.xml of both Application Server Node and Dmgr Node

Application Node

[root@mercury mercuryNode01]# cat /opt/IBM/WebSphere/AppServer/profiles/Custom01/config/cells/Cell01/nodes/mercuryNode01/serverindex.xml

Here we can see the Application which we deployed ie DefaultApplication.ear.ear in the serverindex.xml

Dmgr Node

[root@mercury mercuryNode01]# cat /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/Cell01/nodes/mercuryNode01/serverindex.xml

Similarly in the Dmgr Node’s Serverindex.xml we can not see the deployed application :DefaultApplication.ear.ear

Validation 3 : Check the <Profile_Home>/config/cells/Cell01/applications folder for the deployed application

Application Server Node

[root@mercury mercuryNode01]# ls -l /opt/IBM/WebSphere/AppServer/profiles/Custom01/config/cells/Cell01/applications

We can see the DefaultApplication.ear.ear in this folder

Dmgr Node

[root@mercury mercuryNode01]# ls -l /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/Cell01/applications

There is no DefaultApplication.ear.ear

Step 10 : Check the deployed application using the browser

url : http://IP of the Application Server:wc_default/snoop

As I have deployed the DefaultApplication I will be testing if the application snoop is accessible now on the applicaiton server when the DMGR is down

This shows we can deploy the application directly on the Application Server Node when the DMGR is down

NOTE : As mentioned above these changes will get overwritten when the Node sync happens when the DMGR is started

NOTE :Once the DMGR is started, you would need to make the changes which you made on Application Server again to the DMGR and do a complete Sync

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

Changing Inactive Session TimeOut for WAS Admin console

Jun4

There may be a requirement for changing the Inactive Session Timeout for the Websphere Admin Console .
The default Session timeout of WAS Console is 30 minutes.

We cannot change the session timeout from directly from the Admin console but there are two methods to do it

Method 1 : Using the wsadmin Script

This is the Recommended way to change the Session Expiration timeout value

Step 1 : The session timeout is saved in the deployment.xml file within the isclite.ear
a) Navigate to the <ProfileHome>/cells/CellName/applications/isclite.ear/deployments/isclite

[root@mercury isclite]# cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/Cell01/applications/isclite.ear/deployments/isclite

b) Check the Existing Session timeout value in the deployment.xml
Open the file deployment.xml and search for the parameter “invalidationTimeout”
Here “invalidationTimeout=30” Indicates the session timeout is 30 minutes

Step 2 : Copy the below following script into a file in the server in any location . I have saved this script in /root/sessiontimeout.jacl

set dep [$AdminConfig getid /Deployment:isclite/]
set appDep [$AdminConfig list ApplicationDeployment $dep]
set sesMgmt [$AdminConfig list SessionManager $appDep]# check if existing sesMgmt there or not, if not then create a new one, if exist then modify it
if {$sesMgmt == “”} {
# get applicationConfig to create new SessionManager
set appConfig [$AdminConfig list ApplicationConfig $appDep]
if {$appConfig == “”} {
# create a new one
set appConfig [$AdminConfig create ApplicationConfig $appDep {}]
# then create a new SessionManager using new Application Config just created
set sesMgmt [$AdminConfig create SessionManager $appConfig {}]
} else {
# create new SessionManager using the existing ApplicationConfig
set sesMgmt [$AdminConfig create SessionManager $appConfig {}]}
}# get tuningParams config id
set tuningParams [$AdminConfig showAttribute $sesMgmt tuningParams]
if {$tuningParams == “”} {
# create a new tuningParams
$AdminConfig create TuningParams $sesMgmt {{invalidationTimeout <timeout value>}}} else {
#modify the existing one
$AdminConfig modify $tuningParams {{invalidationTimeout <timeout value>}}}# saving the configuration changes
$AdminConfig save

Step 3 : Change the on the two lines of this file to the new session expiration value which you want and save the changes to the file. I have specified10 min as session expiration

This number specifies the number of minutes the console preserves the session during inactivity

Step 4 : Run the wsadmin.sh ( you may have to specify the credentials if security is enabled )

bash-3.2$[root@mercury isclite]# cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/

Execute wsadmin.sh -lang jacl -f FileName

bash-3.2$[root@mercury bin]# ./wsadmin.sh -lang jacl -f /root/sessiontimeout.jacl

Step 5 : Once the script is run check the deployment.xml to ensure the changes are reflected in it

Here the changes ie invalidationTimeout=”10″ is updated in deployment.xml file of isclite.ear

Step 6 : Restart the Dmgr or the Appserver ( in case of Stand Alone Server)

bash-3.2$[root@mercury isclite]# cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/

Stop Deployment Manager

bash-3.2$[root@mercury isclite]# ./stopManager.sh

Start Deployment Manager

bash-3.2$[root@mercury isclite]# ./startManager.sh

Step 7 : Test the session expiry after 10 min of Inactivity in the Websphere Admin console
Method 2: Modifying the deployment.xml

Step 1 : The session timeout is saved in the deployment.xml file within the isclite.ear
a) Navigate to the <ProfileHome>/cells/CellName/applications/isclite.ear/deployments/isclite

[root@mercury isclite]# cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/Cell01/applications/isclite.ear/deployments/isclite

b) Check the Existing Session timeout value in the deployment.xml
Open the file deployment.xml and search for the parameter “invalidationTimeout”
Here “invalidationTimeout=30” Indicates the session timeout is 30 minutes

Step 2 : Logout of the WAS admin console if you are allready logged in .

Step 3: Backup the existing deployment.xml file within the isclite.ear to some other location outside the WAS directory structure. This will ensure you wll be able to revert to the original setting if any issues occurs.

[root@mercury isclite]# cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/Cell01/applications/isclite.ear/deployments/isclite

I have saved the deployment.xml.org in /root as deployment.xml.org

[root@mercury isclite]# cp deployment.xml /root/deployment.xml.org

Step 4: Navigate to Go to the following directory,
<ProfileHome>/cells/CellName/applications/isclite.ear/deployments/isclite

Step 5 : Modify the deployment.xml file any editor and update setting the value of the “invalidationTimeout” parameter to the desired value (In minutes)

Here the I have update the invalidationTimeout=”10″ in deployment.xml file

Step 6 : Restart the Dmgr or the Appserver ( in case of Stand Alone Server)

bash-3.2$[root@mercury isclite]# cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/

Stop Deployment Manager

bash-3.2$[root@mercury isclite]# ./stopManager.sh

Start Deployment Manager

bash-3.2$[root@mercury isclite]# ./startManager.sh

Step 7 : Test the session expiry after 10 min of Inactivity in the Websphere Admin console

Update Trial License of WebSphere MQ to Prod License

May28

There are many cases wherein you have installed the Trial version of WebSphere MQ.
Later you purchased the fully supported version and would like to install the Licenced version without affecting the current MQ infrastructure which you have configured and running.

When you Create or Start a Queue Manager in the Trial MQ Installation you will get a message
“There are 90 days left in the trial period for this copy of WebSphere MQ”

The evaluation trial version license will soon expire after 90 days and you will not be able to use the MQ later .

So you would need to Purchase a license for WebSphere MQ from your IBM sales representative and update the Trial License

Activity : Update the Production License of MQ on Trial Websphere MQ version MQ 7.1 on Linux

Prerequisites : Installed version of Trail Webspsphere MQ . In this activity i have installed
“Trial Websphere MQ version MQ 7.1 on Linux”

Get the PROD License :
1) Use the CD which you have got
2) Download the Same version of MQ product from the Passport Advantage site

Background :
“setmqprd” command is used to update the PROD license over the existing Trial Version of MQ

For UNIX: setmqprd {PATH_TO_NEW_CODE}/licenses/amqpcert.lic
For Windows: setmqprd {PATH_TO_NEW_CODE}\licenses\amqpcert.lic

NOTE : Ensure that you have same version purchased as to the trial version which you have installed

The license is named amqXcert.lic, where X is the license type.

• amqtcert.lic – is a trial license
• amqbcert.lic – is a beta license
• amqpcert.lic – is a full production license

Steps to update the MQ Trial License to PROD

Step 1 : Stop the Running queue managers in the Installation using endmqm

Step 2 : Extract the Production License for MQ 7.1
a) Use the MQ Product CD which you have received
OR
b)Download the Same version of MQ product from the Passport Advantage site

I have extracted the Complete Version of MQ 7.1 in /IBMSoftware/mq/. Within this there is a “licenses” folder .
In the license folder there is a amqpcert.lic file which represents the Production MQ License

Step 3 : Run “setmqprd”

#setmqprd {PATH_TO_NEW_CODE}/lib/amqpcert.lic

[root@mercury ~]# /opt/mqm/bin/setmqprd /IBMSoftware/mq/licenses/amqpcert.lic

Step 4 : Once you run the setmqprd the prod license file amqpcert.lic gets saved in /opt/mqm/lib/ .

If amqtcert.lic file also exists in the /opt/mqm/lib/ along with the amqpcert.lic .
Then Delete the MQ Trial Licence file (amqtcert.lic) from the /opt/mqm/lib/ folder

bash-3.2$ cd /opt/mqm/lib/

bash-3.2$ rm amqtcert.lic

NOTE : If you dont delete the MQ Trial Licence file (amqtcert.lic) from the /opt/mqm/lib/ folder . You might get the error ” AMQ7155 : Licence file not found or not valid.”

Click HERE to get more Information about this error

Step 5: Start the queue managers now using “strmqm”

bash-3.2$ strmqm test

We are not receiving the message “There are 90 days left in the trial period for this copy of WebSphere MQ”

This indicates that the License has been updated to PROD

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

MQ Error : AMQ7155: License file not found or not valid

May27

After we update the Trial License of MQ with the Production License of the MQ .

Sometimes we may get the error “AMQ7155: License file not found or not valid” when we start the Queue Manager

Click HERE for the details to update the Prod MQ License

Some reasons for this error

Step 1: License File missing : Check if the amqpcert.lic file is available in “/opt/mqm/lib”

Step 2: Permission Issue : Check if the permissions is proper in “/opt/mqm/lib” for the .lic files in it

Step 3: Multiple License file Available : When we run the setmqprd command the /opt/mqm/lib may also have the Trail MQ license file amqtcert.lic .

As the “/opt/mqm/lib” has both the Trail MQ license file (amqtcert.lic) and Prod MQ license file (amqpcert.lic) . The MQ is not able to identify which one it should use and hence gives an error

Step 4 : Remove the Trail MQ license file (amqtcert.lic) from the “/opt/mqm/lib” folder. The Queue Manager will pick up the changes once it is started back up.

bash-3.2$ cd /opt/mqm/lib/

bash-3.2$rm amqtcert.lic

Step 5: Start the Queue Manager and check if starts properly

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

Find IBM Java version used by the WAS

May15

Below are the few methods to find out the Java version which is used by the Installed WAS Instance
1.From the System Out Logs
2.Using java -version
3.Using Wsadmin Script
4.Using VersionInfo.sh

Method 1: From the System Out Logs
a) Navigate to the Folder where the SystemOut.log is available .
Eg : /opt/IBM/WebSphere/AppServer/profiles/wp_profile/logs/WebSphere_Portal

b) Open the SystemOut.log file and see the First Few lines of the Logs

Highlighted in YELLOW is the JDK Version used by the Installed WAS instance .. ie IBM SDK 1.6

Method 2: Using java -version

a) Navigate to $WAS_HOME/java/bin/ ie /opt/IBM/WebSphere/AppServer/java/bin

b) Run “java -version” from /opt/IBM/WebSphere/AppServer/java/bin

[root@mercury bin]#cd /opt/IBM/WebSphere/AppServer/java/bin

[root@mercury bin]# ./java -version

Highlighted in yellow is the JDK version used by WAS Installation ie IBM SDK 1.6 and its 32 bit

Method 3: Using Wsadmin Script

a) Navigate to the $Profile/bin directory
for eg :

[root@mercury WebSphere_Portal]# cd /opt/IBM/WebSphere/AppServer/profiles/wp_profile/bin

b) Invoke wsadmin.sh with jython language type ( you can use both jacl or jython )

./wsadmin.sh -lang jython

c) Execute the getServerSDK for to get the SDK version of the Server

wsadmin>AdminTask.getServerSDK(‘[-serverName <Server Name> -nodeName <Node Name>]’)

My Server Name for my environment is : WebSphere_Portal
Node Name for my environment is : mercuryNode

wsadmin>AdminTask.getServerSDK(‘[-serverName WebSphere_Portal -nodeName mercuryNode]’)

Here the output is SDKNAME 1.6_32

d) Execute getAvaliableSDKsOnNode to get the avaliabe SDKs which are installed on the specific node.

wsadmin>AdminTask.getAvailableSDKsOnNode(‘[-nodeName mercuryNode]’)

As we have only one SDK installed on this node its displaying the SDK version ‘1.6_32’

Method 4: Using VersionInfo.sh

a) Navigate to “$WAS_HOME/bin” folder and execute the ./verisonInfo.sh Command
For eg

[root@mercury bin]# cd /opt/IBM/WebSphere/AppServer/bin/

[root@mercury bin]# ./versionInfo.sh

b) Under the “Installed Features” we see the JAVA Version ie “IBM 32-bit SDK for Java, Version 6”

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts.. Please subscribe to the site http://webspherepundit.com And also like the Facebook Page https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts.. Please subscribe to the site http://webspherepundit.com And also like the Facebook Page https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts.. Please subscribe to the site http://webspherepundit.com And also like the Facebook Page https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts.. Please subscribe to the site http://webspherepundit.com And also like the Facebook Page https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts.. Please subscribe to the site http://webspherepundit.com And also like the Facebook Page https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts.. Please subscribe to the site http://webspherepundit.com And also like the Facebook Page https://www.facebook.com/webspherepundit

Steps to update the MQ Trial License to PROD

To get automated mail updates of my Posts.. Please subscribe to the site http://webspherepundit.com And also like the Facebook Page https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts.. Please subscribe to the site http://webspherepundit.com And also like the Facebook Page https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts.. Please subscribe to the site http://webspherepundit.com And also like the Facebook Page https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit

To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit