Wednesday, February 17, 2010

Deploying a data access application in websphere (jdbc access)

Steps involved in this are:



•Create a JDBC source

•Create a J2C alias

•Create a Data source

•Deploy Application

Creating a JDBC Provider

The JDBC provider object provides the actual JDBC driver implementation class for access to a specific database type, that is, Oracle, SQL Server, DB/2 etc. We associate a data source with a JDBC provider and data source provides the connection to the database.



•In the administration console

Resources -> JDBC -> JDBC Provider



•Here we need to select the scope, at which the jdbc provider will be available like CELL/NODE etc. Scope specifies the level at which the resource definition is visible





•Then click new

•select database type, Provider, Implementation type and Name



•Click Next to go to the database classpath screen



•Click next, shows the summery of your respones. then click finish to create your new jdbc provider

Creating J2C Alias

If a database has security enabled, we need to provide the username and password for the connection. By creating a J2C alias, we can create an authentication resource independent from the provider and data source



•In the administration console

security -> global security -> Authentication ->Java Authentication and Authorization Service ->J2C authentication data



•on the next screen provide, Alias name, DB user name and password

•and then apply->Save

Creating Data Source

•In the administration console

Resources -> JDBC -> DataSource



•Select the scope

•On the next page, be asked to fill out the data source information



•Enter the value for Data source name field and JNDI name field. and proceed to next page



•Select the JDBC provider that we created, using the above steps

•Click Next, and in the next screen…enter the database URL field and click next

•here, you have option to select the authentication for resource type

•Component-managed Use when the resource configured in the EJB’s deployment descriptor res-auth property is set to Application.

•Container-managed Use when the resource configured in the EJB’s deployment descriptor res-auth property is set to Container.

•Select the appropriate value and click next to see the summery of your responses.

•Once they are confirmed, click finish to create the data source.

Deploying application (you can refere previous post also for details)



•Goto Applications ->install new application

•select enterprise application and browse the archive (EAR) file

•Select the install method

•Map the modules to servers

•choose the deployment options (detailed was chosen here to show all the options)

•Map shared libraries, if required

•Map resource references to resources

•Mapping virtual hosts for web modules (by default, default_host will be there)

•Map the context root for the application

•Review all the steps and options you provided

•and finish the application deployment

•start the application and test it


http://josephamrithraj.wordpress.com/2010/02/05/656/

WebSphere Application Server Introduction

WebSphere Application Server Introduction

Simplify the delivery and management of business applications and services to speed response and reduce costs. The current market scenario is about cutting costs as industry is badly hit by recession. This is not just about an industry like banking, but across industries that are like retail, insurance, automobile and every industry that has an IT need is trying to cut down /postpone costs on IT Assets and investments.


This is leading to an enormous amount of job cuts/ layoffs by all the IT companies, this is because the companies are trying to remove the extra employees they have on the bench as well as remove the software programming staff. Lot of people are there on roads searching for jobs.


Isn’t there any light for getting a new job, if we look around every problem brings an opportunity to someone else. Now this problem created necessity for companies to make sure that their current applications running in production environments as websites and enterprise software are running without any problem.


This created jobs for people who make sure that these applications are taken care of. These people are the administrators of the production environments. People who are in these roles are called Application Administrators.

In all the administration that is to be done, there are very few people available on Websphere Application Server in the current job market where as requirements are ample. This opens up a lot of opportunity for people who know or are trained on Websphere Application Server.

What is Websphere Application Server (WAS)?

IBM – WAS is an Application Server from IBM to serve highly complex and mission critical applications of different enterprises irrespective of whether they are from banking or pharmacy or any other business. IBM – WAS runs on the J2EE platform of Java and is a very well designed and organized product which give lot of importance to enterprise needs like security

, high performance, failsafe techniques which are essential for the growing business of the enterprise.


Why IBM Websphere Application Server is a career option?

WebSphere Application Server is the most preferred Application Server worldwide and is used by huge number of companies where there is a lot of need for administration of the Websphere.

There are very less people available on Websphere platform in the job market.

Even if people are trained on Websphere, what the production environment demands is ability of the candidate to be able to troubleshoot a problem within minutes of identification and make sure that very minimum of such kind of things happen. For this the right kind of training is very essential.

Application Server components


WebSphere Application Server relies on following server components to provide enterprise level environment


•Web Browser: The end user uses a Web browser to interact with the deployed applications. The administrator makes use of browser to access the WebSphere Application Server Administration Console

•IP Sprayer: IP sprayer is normally a hardware unit that seats in front of your web server and distributes user requests among different HTTP server. If you dont use IP sprayer instead point the application URL to HTTP Server then that server becomes single point of failure also if you have a big user load then you might want to distribute users requests among different HTTP server which in turn would distribute user requests to different WAS server. The IP sprayer can either randomly distribute requests between different HTTP Servers or they can be sophisticated things like if the user request particular application then forward that request to high performance/ powerful server

•Load balance: The end user of WAS, normally points to the load balance, which takes care of distributing the user requests between different HTTP servers. The load balancer makes sure that no individual server is overwhelemed with the requests while other servers are idel.

•HTTP Server and Web Server Plugin: THe HTTP server is used for two things first is to server static content and in addition to that it also makes use of WebSPhere Plugin to distribute requests among different servers where the application is configured (Usually different servers in cluster). The HTTP server is normally configured to use either weighted round robin scheduling algorith, where the first request is distributed to a random application server, which servers as a starting point and then the subsequent requests are distributed according to the assigned weights of the application server. You can also configure plugin to use random system in which case the server weightage is not taken into consideration and the requests are distributed randomly. The HTTP server also takes care of session affinity, which makes sure that the request from the client goes to same server which served last request for that client

•Firewall: A firewall is a hardware and software system that manages the flow of information between the Internet and your companies network. It takes care of things like blocking user access to only few predefined ports, it can block virus and denial of service attacks.

•Database server: Most of the enterprise applications use RDBMS for data storage and retrieval functionality. The Application developers decide what database to use, there structure,.. The WebSPhere application server does not store any configuration data in db, that data is stored in .xml files on the file system

•Websphere MQ: WebSPhere MQ is messaging backbone that is used for exchanging point-to-point message and publish-and-subscribe messaegs with applications that reside a WebSphere MQ network.




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

Generate a (new) SSL Certificate for https [IBM HTTP Server]

Generate a (new) SSL Certificate for https [IBM HTTP Server]
[FOR HTTPS/SSL BETWEEN CLIENT AND WEBSERVER]
To generate a new CA-Signed SSL-Certificate for use with the IBM HTTP Server you need to start the iKeyman-Utility first. The iKeyman is the Key Management Tool from IBM.

1. Navigate to the /bin-directory of your IHS-Installation
2. execute
./ikeyman
to open the Key Management Tool
3. Use "Key Database File > Open" to open your password-protected Key-Database

4. After the Key-Database is loaded switch to "Personal Certificate Requests" (under "Key database content").
5. Click New and fill out the certificate request dialog. Depending on your CA-Provider (VeriSign,...) you may need to fill out the dialog in a special way (VeriSign demands the common name to be the domain)

6. Click "OK" to save the certificate request in a file.
7. now you need to provide the content of the certificate request file to your Ceritifcate Authority (e.g.: VeriSign). You will receiving a new certificate file from them.
8. If you received the certificate switch back to "Personal Certificates" (under "Key database content").
9. Click Receive and navigate to the certificate file. Click Ok to import the certificate file.

10. Open the httdp.conf-File of your IHS and replace the SSL-Cert-Name (new one will be displayed after the import of the new certificate in iKeyman). Usally the SSL-Cert is definded within a virtual host:
Example:

ServerName www.test.com
SSLEnable
SSLClientAuth 0
SSLServerCert ihssslcert
AllowEncodedSlashes On

Options Indexes MultiViews
Order allow,deny
Allow from all



DocumentRoot /usr/IBM/HTTPServer/www-doc-root/


11. Restart the IHS-Server (/bin/apachectl stop --> /bin/apachectl start)

Shell scripting step by step

http://bash.cyberciti.biz/guide/Main_Page

Unix commands

Files


ls -l --- lists your files in 'long format', which contains lots of useful information, e.g. the exact size of the file, who owns the file and who has the right to look at it, and when it was last modified.

ls -a --- lists all files, including the ones whose filenames begin in a dot, which you do not always want to see.

ls -altr - a option is to show the hidden files

more filename --- shows the first part of a file, just as much as will fit on one screen. Just hit the space bar to see more or q to quit. You can use /pattern to search for a pattern.
emacs filename --- is an editor that lets you create and edit a file.

rm -f file name to delete files without interation


cp file1 file2 copies file1 to file2

chmod 777 filename ------- to give all permissions (read 4, Write 2, execute 1)
chmod 644 filename to give write permissions

diff filename1 filename2 --- compares files, and shows where they differ
wc filename --- tells you how many lines, words, and characters there are in a file


Directories:

mkdir dirname --- make a new directory

cd dirname --- change directory. You basically 'go' to another directory, and you will see the files in that directory when you do 'ls'. You always start out in your 'home directory', and you can get back there by typing 'cd' without arguments. 'cd ..' will get you one level up from your current position. You don't have to walk along step by step - you can make big leaps or avoid walking around by specifying pathnames

rm -r dirname to delete directory

pwd --- tells you where you currently are.



File Compression:

Making Archive file:

tar -cvf tarfilename(samlogserver).tar file1 file2.. to make tar file of files1,file2........


gzip filename --- compresses files, so that they take up much less space. Usually text files compress to about half their original size, but it depends very much on the size of the file and the nature of the contents. There are other tools for this purpose, too (e.g. compress), but gzip usually gives the highest compression rate. Gzip produces files with the ending '.gz' appended to the original filename.

gunzip filename --- uncompresses files compressed by gzip.

gzcat filename --- lets you look at a gzipped file without actually having to gunzip it (same as gunzip -c). You can even print it directly, using gzcat filename | lpr

gzcat tarfilename tar-xvf

gzip tarfilename ( Compresses the archived tar file)

gunzip gzfilename

jar -tvf jar file name --- it shows list of classes in the jar file

zip filename.zip filename - zipping a file and opening a file in windows



Printing:

lpr filename --- print. Use the -P option to specify the printer name if you want to use a printer other than your default printer. For example, if you want to print double-sided, use 'lpr -Pvalkyr-d', or if you're at CSLI, you may want to use 'lpr -Pcord115-d'. See 'help printers' for more information about printers and their locations.

lpq --- check out the printer queue, e.g. to get the number needed for removal, or to see how many other files will be printed before yours will come out

lprm jobnumber --- remove something from the printer queue. You can find the job number by using lpq. Theoretically you also have to specify a printer name, but this isn't necessary as long as you use your default printer in the department.

genscript --- converts plain text files into postscript for printing, and gives you some options for formatting. Consider making an alias like alias ecop 'genscript -2 -r \!* | lpr -h -Pvalkyr' to print two pages on one piece of paper.

dvips filename --- print .dvi files (i.e. files produced by LaTeX). You can use dviselect to print only selected pages. See the LaTeX page for more information about how to save paper when printing drafts.


Disk Size:

du -hs file name/directory ----------- to get the size of the file/directory
df -h ------ size of each mount
du -hs SUNWam -------- to get the size of SUNWam file/directory



Finding things

ff --- find files anywhere on the system. This can be extremely useful if you've forgotten in which directory you put a file, but do remember the name. In fact, if you use ff -p you don't even need the full name, just the beginning. This can also be useful for finding other things on the system, e.g. documentation.


grep string filename(s) --- looks for the string in the files. This can be useful a lot of purposes, e.g. finding the right file among many, figuring out which is the right version of something, and even doing serious corpus work. grep comes in several varieties (grep, egrep, and fgrep) and has a lot of very flexible options. Check out the man pages if this sounds good to you

find ./ -name 'direcorty or file name' ----------------- finds the given direcorty or file name.

find . -name *.log -exec grep -il oracle {} ;

find . name *.* -exec grep -il 'Enter new PIN, containing 4 to 8 characters' {};

find . | xargs grep "p-level Policy Admin Role,ou=role,dc=dupont,dc=com,amsdkdn=cn"

find . | xargs grep stg








:1,$s/^M//g ------- to remove ^M character from vi editor

:%s/^M//g --------------to remove ^M character from vi editor















Miscellanious:


lsof | grep slapd | grep LISTEN --------- to find portnumber of the various slapd instances

lsof | grep ldaprole | grep LISTEN -------- to find portnumber of various ldaprole instances

ps -ef | grep slapd ---- to find the DS Instances are running or not

export PATH=$PATH:/opt/sfw/bin -------------- to export the bin path



























kill -9 PID
Kill PID



nohup Run the command in the background

& Run the command even if Putty gets logged out


gzip -dc "filename.tar.gz" | tar -xof - ( For


Roles:

id to get the current ID
sudo su - eisadmin to get eisadmin permissions
sudo stop/start
sudo -l to get the list of sudo permissions
sudo su - root ------ to get the root permissions
sudo su - ldaprole to get ldaprole permission


About other people:

w --- tells you who's logged in, and what they're doing. Especially useful: the 'idle' part. This allows you to see whether they're actually sitting there typing away at their keyboards right at the moment.

who --- tells you who's logged on, and where they're coming from. Useful if you're looking for someone who's actually physically in the same building as you, or in some other particular location.

finger username --- gives you lots of information about that user, e.g. when they last read their mail and whether they're logged in. Often people put other practical information, such as phone numbers and addresses, in a file called .plan. This information is also displayed by 'finger'.

last -1 username --- tells you when the user last logged on and off and from where. Without any options, last will give you a list of everyone's logins.

talk username --- lets you have a (typed) conversation with another user

write username --- lets you exchange one-line messages with another user

elm --- lets you send e-mail messages to people around the world (and, of course, read them). It's not the only mailer you can use, but the one we recommend. See the elm page, and find out about the departmental mailing lists (which you can also find in /user/linguistics/helpfile).






About your self

whoami --- returns your username. Sounds useless, but isn't. You may need to find out who it is who forgot to log out somewhere, and make sure *you* have logged out.


finger & .plan files
of course you can finger yourself, too. That can be useful e.g. as a quick check whether you got new mail. Try to create a useful .plan file soon. Look at other people's .plan files for ideas. The file needs to be readable for everyone in order to be visible through 'finger'. Do 'chmod a+r .plan' if necessary. You should realize that this information is accessible from anywhere in the world, not just to other people on turing.

passwd --- lets you change your password, which you should do regularly (at least once a year). See the LRB guide and/or look at help password.

ps -u yourusername --- lists your processes. Contains lots of information about them, including the process ID, which you need if you have to kill a process. Normally, when you have been kicked out of a dialin session or have otherwise managed to get yourself disconnected abruptly, this list will contain the processes you need to kill. Those may include the shell (tcsh or whatever you're using), and anything you were running, for example emacs or elm. Be careful not to kill your current shell - the one with the number closer to the one of the ps command you're currently running. But if it happens, don't panic. Just try again :) If you're using an X-display you may have to kill some X processes before you can start them again. These will show only when you use ps -efl, because they're root processes.

kill PID --- kills (ends) the processes with the ID you gave. This works only for your own processes, of course. Get the ID by using ps. If the process doesn't 'die' properly, use the option -9. But attempt without that option first, because it doesn't give the process a chance to finish possibly important business before dying. You may need to kill processes for example if your modem connection was interrupted and you didn't get logged out properly, which sometimes happens.

quota -v --- show what your disk quota is (i.e. how much space you have to store files), how much you're actually using, and in case you've exceeded your quota (which you'll be given an automatic warning about by the system) how much time you have left to sort them out (by deleting or gzipping some, or moving them to your own computer).

du filename --- shows the disk usage of the files and directories in filename (without argument the current directory is used). du -s gives only a total.

last yourusername --- lists your last logins. Can be a useful memory aid for when you were where, how long you've been working for, and keeping track of your phonebill if you're making a non-local phonecall for dialling in.



Connecting to the outside world

nn --- allows you to read news. It will first let you read the news local to turing, and then the remote news. If you want to read only the local or remote news, you can use nnl or nnr, respectively. To learn more about nn type nn, then \tty{:man}, then \tty{=.*}, then \tty{Z}, then hit the space bar to step through the manual. Or look at the man page. Or check out the hypertext nn FAQ - probably the easiest and most fun way to go.

rlogin hostname --- lets you connect to a remote host

telnet hostname --- also lets you connect to a remote host. Use rlogin whenever possible.

ftp hostname --- lets you download files from a remote host which is set up as an ftp-server. This is a common method for exchanging academic papers and drafts. If you need to make a paper of yours available in this way, you can (temporarily) put a copy in /user/ftp/pub/TMP. For more permanent solutions, ask Emma. The most important commands within ftp are get for getting files from the remote machine, and put for putting them there (mget and mput let you specify more than one file at once). Sounds straightforward, but be sure not to confuse the two, especially when your physical location doesn't correspond to the direction of the ftp connection you're making. ftp just overwrites files with the same filename. If you're transferring anything other than ASCII text, use binary mode.

lynx --- lets you browse the web from an ordinary terminal. Of course you can see only the text, not the pictures. You can type any URL as an argument to the G command. When you're doing this from any Stanford host you can leave out the .stanford.edu part of the URL when connecting to Stanford URLs. Type H at any time to learn more about lynx, and Q to exit



date --- shows the current date and time.

cal --- shows a calendar of the current month. Use e.g., 'cal 10 1995' to get that for October 95, or 'cal 1995' to get the whole year




VI Editor Commands:

Saving a file:

:w write current contents to file named in original vi call
:w newfile write current contents to a new file named newfile
:w! prevfile write current contents over a pre-existing file named prevfile


Exit vi:

:x quit vi, writing out modified file to file named in original invocation
:wq quit vi, writing out modified file to file named in original invocation
:q quit (or exit) vi
:q! quit vi even though latest changes have not been saved for this vi call


Moving the Cursor:


j or [or down-arrow] move cursor down one line
k [or up-arrow] move cursor up one line
0 (zero) move cursor to start of current line (the one with the cursor)
$ move cursor to end of current line
:0 or 1G move cursor to first line in file
:$ or G move cursor to last line in file



Screen Manipulation:

^f move forward one screen
^b move backward one screen



Text Editor:

u UNDO WHATEVER YOU JUST DID; a simple toggle
i insert text before cursor, until hit
I insert text at beginning of current line, until hit
a append text after cursor, until hit
A append text to end of current line, until hit
o open and put text in a new line below current line, until hit
O open and put text in a new line above current line, until hit
r replace single character under cursor (no needed)
x delete single character under cursor
dd delete entire current line
D delete the remainder of the line, starting with current cursor position
yy copy (yank, cut) the current line into the buffer
p put (paste) the line(s) in the buffer into the text after the current line
/string search forward for occurrence of string in text
?string search backward for occurrence of string in text

Crontab

Crontab
cron is a unix, solaris utility that allows tasks to be automatically run in the background at regular intervals by the cron daemon. These tasks are often termed as cron jobs in unix , solaris.
Crontab (CRON TABle) is a file which contains the schedule of cron entries to be run and at specified times.

2. Crontab Commands
__________
export EDITOR=vi ;to specify a editor to open crontab file.

crontab -e Edit your crontab file, or create one if it doesn't already exist.
crontab -l Display your crontab file.
crontab -r Remove your crontab file.
crontab -v Display the last time you edited your crontab file. (This option is only available on a few systems.)

3. Crontab file
___________
Crontab syntax :-
A crontab file has five fields for specifying day , date and time followed by the command to be run at that interval.
* * * * * command to be executed
- - - - -
| | | | |
| | | | +----- day of week (0 - 6) (Sunday=0)
| | | +------- month (1 - 12)
| | +--------- day of month (1 - 31)
| +----------- hour (0 - 23)
+------------- min (0 - 59)


* in the value field above means all legal values as in braces for that column.
The value column can have a * or a list of elements separated by commas. An element is either a number in the ranges shown above or two numbers in the range separated by a hyphen (meaning an inclusive range).

Note: The specification of days can be made in two fields: month day and weekday. If both are specified in an entry, they are cumulative meaning both of the entries will get executed

minute hour dom month dow user cmd

minute This controls what minute of the hour the command will run on,
and is between '0' and '59'
hour This controls what hour the command will run on, and is specified in
the 24 hour clock, values must be between 0 and 23 (0 is midnight)
dom This is the Day of Month, that you want the command run on, e.g. to
run a command on the 19th of each month, the dom would be 19.
month This is the month a specified command will run on, it may be specified
numerically (0-12), or as the name of the month (e.g. May)
dow This is the Day of Week that you want a command to be run on, it can
also be numeric (0-7) or as the name of the day (e.g. sun).
user This is the user who runs the command.
cmd This is the command that you want run. This field may contain
multiple words or spaces.

If you don't wish to specify a value for a field, just place a * in the
field.

e.g.
01 * * * * root echo "This command is run at one min past every hour"
17 8 * * * root echo "This command is run daily at 8:17 am"
17 20 * * * root echo "This command is run daily at 8:17 pm"
00 4 * * 0 root echo "This command is run at 4 am every Sunday"
* 4 * * Sun root echo "So is this"
42 4 1 * * root echo "This command is run 4:42 am every 1st of the month"
01 * 19 07 * root echo "This command is run hourly on the 19th of July"


4. Crontab Example
_______

A line in crontab file like below removes the tmp files from /home/someuser/tmp each day at 6:30 PM.
30 18 * * * rm /home/someuser/tmp/*
Changing the parameter values as below will cause this command to run at different time schedule below :
min hour day/month month day/week Execution time
30 0 1 1,6,12 * -- 00:30 Hrs on 1st of Jan, June & Dec.
:
0 20 * 10 1-5 --8.00 PM every weekday (Mon-Fri) only in Oct.
:
0 0 1,10,15 * * -- midnight on 1st ,10th & 15th of month
:
5,10 0 10 * 1 -- At 12.05,12.10 every Monday & on 10th of every month
:
Note : If you inadvertently enter the crontab command with no argument(s), do not attempt to get out with Control-d. This removes all entries in your crontab file. Instead, exit with Control-c.
5. Crontab Environment
___________
cron invokes the command from the user's HOME directory with the shell, (/usr/bin/sh).
cron supplies a default environment for every shell, defining:
HOME=user's-home-directory
LOGNAME=user's-login-id
PATH=/usr/bin:/usr/sbin:.
SHELL=/usr/bin/sh

Users who desire to have their .profile executed must explicitly do so in the crontab entry or in a script called by the entry.

6. Disable Email
____________
By default cron jobs sends a email to the user account executing the cronjob. If this is not needed put the following command At the end of the cron job line .

>/dev/null 2>&1

7. Generate log file
________________
To collect the cron execution execution log in a file :

30 18 * * * rm /home/someuser/tmp/* > /home/someuser/cronlogs/clean_tmp_dir.log
Examples
to run at crontab at a specific first day of the month, you cant just put 0 for sunday as example, because it would run on all sundays in that month so i believe you need to include from 1-7 for your day of Month parameter. that would rule out any specific day's running twice.
so for the first sunday of every month:
at 1 30 pm

30 13 1-7 * 0

if you want to run every other sunday, you just change it like this:

30 13 1-7,15-21 * 0

for the first, third and last sunday of a month

1-7,15-28

How do i run this job on alternate days ?
0 8 1,2,3,4,5,6,7 * 0 cmd

Merging plugin-cfg.xml files from multiple nodes

Problem(Abstract)
Merging plugin-cfg.xml files from multiple nodes for releases of IBM® WebSphere® Application Server version 5 and version 6.



Resolving the problem
Merging two plugin-cfg.xml files

1.The tag is the root element in the plugin-cfg.xml file. There should be only one element in the merged file.


2.Copy the element from any of the two merging files, and modify the Name, if required.


3.Copy all the elements from both the files. The VirtualHostGroup name must be unique; if the names are not unique, prepend the node name to the VirtualHostGroup name to make it unique.

When serving a request, the plug-in searches for the VirtualHost and URI, so the combination of these must be unique. If it is not, you receive unexpected results. As a precautionary step, make sure that the VirtualHost name is unique. Avoid having an asterisk ( * ) in the virtual host name; instead, explicitly specify the server name and port number.


4.Copy all elements from both the files. Normally they are unique because the host name is included in the name; however, make the names unique if necessary.


5.Server Name must be unique across all clusters. From WebSphere Application Server version 5.0.1 or higher, host or node name is included in server name. If you are at version 5.0, then you might have to prepend the host name to the server name to make it unique.


6.In the element, the properties keyring and stashfile should use the same location for all the Application Servers in the merged file.


7.Copy all the elements from both nodes. Normally these are unique because a server cluster name is included; however, make the names unique if necessary.


8.Copy all the elements and apply any changes that you have made to the names of VirtualHostGroup, ServerCluster or URIGroup.


9.Make sure that resources are unambiguously specified. Especially when merging two servers containing applications with similar context-root. You may want to consider utilizing virtual host aliases in Administrative Console to unambiguously route the requests to specific application server.


10.Make sure that the Web server points to the new plugin-cfg.xml file.

Websphere MQ Quick reference


MQSC: indicates a runmqsc command, which can be executed while in runmqsc [QmgrName] or as one line command using:
echo command runmqsc [QmgrName]
on Unix platforms add double quotes:
echo “command” runmqsc [QmgrName]


MQ Display commands

MQ start-Stop commands

MQ status verification commands

backup queue manager in Websphere mq

backup queue manager in Websphere mq

Creating a backup queue manager
========================
1. Create a backup queue manager for the existing queue manager using the control command crtmqm. The backup queue manager requires the following:
* To have the same attributes as the existing queue manager, for example the queue manager name, the logging type, and the log file size.
* To be on the same platform as the existing queue manager.
* To be at an equal, or higher, code level than the existing queue manager.
2. Take copies of all the existing queue manager’s data and log file directories, including all subdirectories, as described in Backing up queue manager data.
3. Overwrite the backup queue manager’s data and log file directories, including all subdirectories, with the copies taken from the existing queue manager.
4. Execute the following control command on the backup queue manager:
strmqm -r BackupQMName
This flags the queue manager as a backup queue manager within WebSphere® MQ, and replays all the copied log extents to bring the backup queue manager in step with the existing queue manager.

starting a backup queue manager
=======================
1. Execute the following control command to activate the backup queue manager:
strmqm -a BackupQMName
The backup queue manager is activated. Now active, the backup queue manager can no longer be updated.

2. Execute the following control command to start the backup queue manager:
strmqm BackupQMName

3. Restart all channels

Note: stop the existing Qmgr using endmqm -w, before copying the qmgr date to backup qmgr

Logging in MQ

=> MQ log are also known as transaction logs.

=> MQ logs consists of two parts
- Data log file (named S0000000.LOG - S9999999.LOG)
- Control log file (named amqhlctl.lfh)

=>Transaction logs are created when you create the Queue Manager. When you choose the default locations, the logs will goes to
- /var/mqm/logs/Queue_Manager in unix
-c:/program files/IBM/log/Queue_Manager in windows
=> These MQ logs/ Transaction logs holds the following information
- Transaction activity known as Unit Of Work
- Persistant messages
- Internan data about queue manager objects
- Persistant channel status

=> Type of logging
MQ provides 2 type of logging options 1. Circular (default) 2. Linear

Circular Logging
- Good performance
- Esay administration
Linear logging
- Media Recovery
- Ability to archive/backup

=> Configuring Logging
Logging configuration will have direct effect on the performance of MQ. Some of the configuration parameters of logging can be changed after creating Queue Manager but some can not be changed.

Primary Logs are the initial and minimum logs.
Secondary logs can be created when the primary logs become full.

Default minimum Max (unix) Max (Win)
Primary 3 2 510 254
Secondary 2 1 509 253

=> Maximum of primary/secondary logs have a constraint of 511 on unix and 255 on windows platforms. These are the active logs

=> Log file size is a multiple of 4KB log file page size. This can not be changed after creating the Queue Manager.

=> Log file size details table
pages filesize Max
Default Win 256 1MB 256MB
Default unix 1024 4MB 2GB
Minimum Win 32 128KB 32MB
Minimum Win 64 256KB 128MB
Maximum 65535 256MB 64GB(win)/128GB(unix)

=> Log buffer size specifies number of 4KB pages MQ uses to beffer log file writes.
- Default is 128 which is specified by 0 in MQ configuration file
- Minimum is 18 and maximum is 4096

=> Log write integrity is the algorithm used to ensure the integrity of the logs.
- Default algorithm is triple write.
- This can be changed from QM configuration file

=> Logging Configuration files
- mqs.ini is the config file for MQ level settings
- qm.ini is the config file for effective/QM lelvel settings

Examples:

-mqs.init
Log Defaults:
LogPrimaryFiles=3
LogSecondaryFiles=2
LogFilePages=1024
LogType=CIRCULAR
LogBufferPages=0
LogDefaultPath=/var/mqm/logs

-qm.ini
LogPrimaryFiles=3
LogSecondaryFiles=2
LogFilePages=1024
LogType=CIRCULAR
LogBufferPages=0
LogDefaultPath=/var/mqm/logs
LogWriteIntegrity=TrippleWrite

=> Log Management
- Circular logging do not need manual log management
- Linear logging needs manual backup/cleaning

=> Some logging related MQ codes
- AMQ7467 Old log file required for queue manager start
- AMQ7468 old log file required for Queue Manager media recovery

- AMQ5037 Queue manager task ‘LOG-FORMAT’ started
- AMQ5037 Queue Manager task ‘LOGGEREU’ stared
- AMQ5037 Queue Manager task ‘LOGGER-IO’ started

=> Media Recording and Recovery
- Recording media images
rcdmqimg command will record the image of the queue manager specified.
- Recovery
is required when a powerloss/reboot/QM failure occurs
When the recovery is performed
- Queues are restored to their comitted state at the time of failure
- Persistant data is not lost
- non-persistant messages will be discarded

=> Log Recovery scenarios
- Disk Failures
In case of circular logging, restore QM and logs from backup
Rebuild QM using support pac MS03
In case of linear logging, restored damaged objects using rcrmqobj

=> Log recovery summary
- In case of circular logging, no recovery is available
- In case of linear logging, use rcrmqobj to recover/recreate the objects fron media image

MQ Queue Manager Clusters

=> CLUSTERING
===========
Clustering is a way to logically group WebSphere MQ queue managers
- reduced system administration due to fewer channel, remote queue, and transmission queue definitions
- increased availability and workload balancing.

=> Basic Cluster setup
===============
> Step-1
Determine which queue manager should hold full repositories
A full repository contains a complete set of information about every queue manager and object in the cluster
You will need at least one, preferably two
> Step-2
Alter the queue manager definitions to add repository definitions
ALTER QMGR REPOS(cluster_name)
> Step-3
Define the CLUSRCVR channels
Every queue manager in the cluster needs a CLUSRCVR with a conname pointing to itself.
DEFINE CHANNEL(channel_name) CHLTYPE(CLUSRCVR) TRTYPE(TCP) CONNAME(‘my_ip_name_or_address(port)’) CLUSTER(cluster_name)
> Step-4
Define the CLUSSDR channels
Define one CLUSSDR to a full repository queue manager. The channel name must match that of the CLUSRCVR on the full repository
DO NOT define a CLUSSDR to point to a partial repository.
DEFINE CHANNEL(channel_name) CHLTYPE(CLUSSDR) TRPTYP(TCP) CONNAME(‘remote_ip_name_or_address(port)’) CLUSTER(cluster_name)
> Step-5
Define a cluster queue
DEFINE QLOCAL(qname) CLUSTER(cluster_name)
Other queue managers in the cluster can send message to it without making remote-queue definitions for it.
Only the local queue manager can read messages from an instance of the cluster queue
You can use a sample program to test putting messages to clustered queues

=> Cluster Commands
===============
DISPLAY QMGR REPOS REPOSNL QMID
AMQ8408: Display Queue Manager details.
QMNAME(QM1) QMID(QM1_2005-07-12_17.14.38) REPOS(QMCLUS)REPOSNL( )
QMID is an internally generated unique name that consists of the queue manager name plus the time the queue manager was created

DISPLAY CLUSQMGR(*) ALL
Display cluster Queue managera details

dis chstatus(*) all
Display channel status details

DISPLAY QCLUSTER(*) ALL
It displays information about clustered queues only.
A cluster queue will not be displayed on a partial repository until an application has opened it.

DISPLAY QUEUE(*) CLUSINFO
This command displays information about queues with TYPE(QCLUSTER)

=> Work load balancing
================
When a cluster contains more than one instance of the same queue, workload balancing determines the best queue manager to route a message to
- At its simplest, workload management results in a round-robin effect
MQ V6 has additional parameters that can be used to influence the results of the algorithm.
- Queues: CLWLPRTY, CLWLRANK, CLWLUSEQ
- Queue Managers: CLWLUSEQ, CLWLMRUC
- Channels: CLWLPRTY, CLWLRANK, CLWLWGHT, NETPRTY
For workload balancing to occur:
- open the queue with the MQOO_BIND_NOT_FIXED open option
- open with the default MQOO_BIND_AS_Q_DEF and with DEFBIND(NOTFIXED) set in the queue definition
- Leave MQMD.ObjectQMgrName blank to allow the queue manager to chose the queue instance
- To force the message to a specific instance of the clustered queue, specify that queue manager’s name in ObjectQmgrName

=> Namelists in clusters
================
- A queue manager may be a member of more than one cluster. List those clusters in a NAMELIST.
- You can alter a full repository QMGR to use REPOSNL(namelist) rather than REPOS.
- For channels and queues, you can specify CLUSNL(namelist) rather than specifying the CLUSTER parameter.

=> REFRESH CLUSTER
===============
- REFRESH CLUSTER removes and rebuilds locally held information about a cluster.
- REFRESH CLUSTER(clustername) REPOS(NO)
- REFRESH CLUSTER(clustername) REPOS(YES), also refreshes information about full repository queue managers and may not be issued from a full repository.
- REFRESH CLUSTER(*)

=> RESET CLUSTER
=============
RESET CLUSTER is issued from a full repository queue manager. It forcibly removes a queue manager or specific QMID from a cluster.
- RESET CLUSTER(clustername) QMNAME(qmname) ACTION(FORCEREMOVE) QUEUES(NO)
- RESET CLUSTER(clustername) QMID(qmid) ACTION(FORCEREMOVE) QUEUES(NO)

=> Troubleshooting
=============
- Is the repository manager still running?
Check the AMQERRxx.log or CHIN joblog.
- Are channels able to run in both directions?
Display CLUSQMGR and CHSTATUS information.
- Are the SYSTEM.CLUSTER.* queues enabled?
Issue DISPLAY QUEUE(SYSTEM.C*) ALL
- Are there messages on
SYSTEM.CLUSTER.COMMAND.QUEUE or
SYSTEM.CLUSTER.TRANSMIT.QUEUE?
- Are there duplicate QMIDs for a given QMGR?
Issue DISPLAY CLUSQMG(*) QMID.
- DISPLAY CLUSQMGR may show CLUSQMGR names starting with SYSTEM.TEMP.
The queue manager has not received all necessary information from the full repository.

Websphere MQ Triggering

MQ Trigering
=========
=> What is 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.

=> How it works?
- A message is put to a queue defined as triggered.
- If a series of conditions are met, the queue manager sends a trigger message to an initiation queue. This is called a trigger event.
- 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.
- Trigger monitors may be built-in, supplied by a SupportPac, or user written.

=> Types of Trigger (TRIGTYPE)
- FIRST: A trigger event occurs when the current depth of the triggered queue changes from 0 to 1.
Use this type of trigger when the serving program will process all the messages on the queue (i.e. until MQRC_NO_MSG_AVAILABLE).
- EVERY: A trigger event occurs every time a message arrives on the triggered queue.
Use this type of trigger when the serving program will only process one message at a time.
- DEPTH: A trigger event occurs when the number of messages on the triggered queue reaches the value of the TRIGDPTH attribute.
Use this type of trigger when the serving program is designed to process a fixed number of messages (i.e. all replies for a certain request).

=> Trigger interval (TRIGINT)
- TriggerInterval or TRIGINT is a time interval specified on the QMGR definition for use by queues defined as TRIGTYPE=FIRST.
- Situations may occur when messages are left on the queue. New messages will not cause another trigger message. To help with this situation, a trigger message will be created when the next message is put if TriggerInterval has elapsed since the last trigger message was created for the queue.

=> Trigget setup
- Create an initiation queue or use the default SYSTEM.CHANNEL.INITQ.
- Create a process definition (optional). TriggerData may be specified in lieu of a process definition.
- Create or alter a transmission queue.
- Associate the initiation queue and the process definition (if applicable) with the transmission queue, and specify the trigger attributes.
=> Triggering Example1
- DEFINE QLOCAL(QM2) REPLACE USAGE (XMITQ) TRIGGER TRIGTYPE(FIRST) TRIGDATA(QM1.TO.QM2) INITQ (SYSTEM.CHANNEL.INITQ)
- QM2 is the name of the XMITQ
- QM1.TO.QM2 is the name of the channel to be started when a message hits the XMITQ
- SYSTEM.CHANNEL.INITQ is the initq monitored by the channel initiator
=> Triggering Example2
- DEFINE QLOCAL(QM4) TRIGGER INITQ(SYSTEM.CHANNEL.INITQ) PROCESS(P1) USAGE (XMITQ) ? DEFINE PROCESS(P1) USERDATA(QM3.TO.QM4)
- The XMITQ definition has PROCESS instead of TRIGDATA
- The channel name is in USERDATA

=> Application Triggering
- Create an initiation queue or use the default SYSTEM.DEFAULT.INITIATION.QUEUE.
- Create a process definition.
- Create or alter a local or model queue.
- Associate the initiation queue and process definition with the local queue, and specify the trigger attributes .
APPLICID is the name of the application executable file, e.g.
- For APPLTYPE(UNIX):
APPLICID (’/u/admin/test/IRMP01′)
- For APPLTYPE(WINDOWSNT):
APPLICID(‘c:\appl\test\irmp01.exe.’)
- On UNIX® systems, ENVRDATA can be set to the ampersand character to make the started application run in the background.
- The application can receive a parm list with an MQTMC2 containing USRDATA and ENVRDATA.

=> Application Trigger Example1
- DEFINE QLOCAL (‘IQ’) REPLACE
- DEFINE PROCESS (PROC) REPLACE APPLTYPE (’CICS’) APPLICID (’PAYR’) USERDATA (’Payroll data’)
- DEFINE QLOCAL (Q1) REPLACE INITQ (‘IQ’) PROCESS (‘PROC’) TRIGGER TRIGTYPE (FIRST)
- Note: If using TRIGTYPE(DEPTH) then TRIGDEPTH must also be specified.
=> Application Trigger Example2
- CRTMQMQ QNAME(initq_name)
- CRTMQMPRC PRCNAME(proc_name) APPID(lib/pgm) ENVDATA (‘JOBNAME(trigapl) JOBD(lib/jobd)’)
- CRTMQMQ QNAME(lclq_name) PRCNAME (proc_name) TRGENBL(*YES) TRGTYPE(*FIRST) INITQNAME(initq_name)
- Note: If using TRGTYPE(*DEPTH) then TRGDEPTH must also be specified.

=> Trigger Conditions
- A trigger message is sent to the initiation queue when all of the following conditions are satisfied:
1. A message is put on a transmission or local queue.
2. The message’s priority is greater than or equal to the TriggerMsgPriority of the queue.
3. The number of messages on queue was previously
- Zero for trigger type FIRST
- Any number for trigger type EVERY or *ALL
- TriggerDepth minus 1 for trigger type DEPTH
4. For trigger type FIRST or DEPTH, no program has the trigger queue open for GETs (Open input count=0).
5. The Get enabled attribute is set to YES on the triggered queue.
6. A Process name is specified and exists, or for transmission queues, TriggerData contains the name of a channel.
7. An Initiation queue is specified and exists and GETs and PUTs are enabled for the initiation queue.
8. The trigger monitor has been started and has the initiation queue open for GETs
9. The TriggerControl attribute is set to YES on the triggered queue.
10. The TriggerType attribute is not set to NONE.
11. For Trigger Type FIRST, the queue was not previously empty, but the TriggerInterval set for the QMGR has elapsed.
12. The only application serving the queue issues MQCLOSE and there are still messages on the queue that satisfy Conditions 2 and 6-10.
13. Certain trigger attributes of the triggered queue are changed, such as
- NOTRIGGER to TRIGGER
- PUT or GET DISABLED to ENABLED
- or a trigger monitor opens the Initiation queue.
14. MSGDLVSQ is set correctly relative to the priority of the messages and the TriggerMsgPriority setting.

=> Triggering Problem determination
- If the setup is brand new or any configuration changes have been made, verify all the definitions are complete and correct.
- If the setup is brand new or has worked before, verify all the conditions for a trigger event are satisfied.
- If channel triggering, verify the correct channel name is specified and the channel is not in a STOPPED state.
- If application triggering
- verify the application name is correct and exists
- verify the application is coded correctly
- verify the correct authorizations are in place.
- Verify a trigger message can be delivered.
- Verify a trigger monitor is active.
- Verify trigger type and application design match.
- Try manually starting the triggered application to see if it is able to run.
- Stranded messages may occur when the triggered application fails to remove one or more messages
- for TriggerType FIRST, use TriggerInteval as a “safety net”, because a trigger event only occurs when depth goes from 0 to 1.
- for TriggerType EVERY, if the triggered application only does one MQGET, manual intervention will be required to process the messages. Otherwise, the application will only read the oldest message on the next successful trigger and the queue depth will remain non-zero.
- If there is a loop or high CPU:
- Change the triggered application to specify a WaitInterval on its MQGET.
- Check the BackoutCount in the MQMD

=> TIPS
- For trigger EVERY, if the trigger monitor ends prematurely, no matter how many messages reside on the queue only one trigger message will be created on restart.
- RUNMQTRM will not get another trigger message until the application completes. To prevent trigger messages from accumulating
- Run multiple trigger monitors or
- Run the applications in the background
- A trigger message is put to the dead letter queue when
- The queue manager can not put a trigger message on the INITQ
- RUNMQTRM detects an error in the trigger message structure
- RUNMQTRM detects an unsupported application type
- RUNMQTRM can not start the application
- RUNMQTRM detects a data conversion error
- Trigger messages are non-persistent.
- Conditions for a trigger event are “persistent”, so, if a trigger message is lost a trigger message will be created when the conditions are met.
- Trigger messages take on the default priority of the INITQ.
- Trigger monitors can not retrieve messages that are part of a unit of work until the unit of work completes (applies whether it is committed or backed out).
- The queue manager counts both committed and uncommitted messages on the trigger queue when assessing the conditions for a trigger event.
- After recycling the queue manager or trigger monitor, a trigger message may be created if the triggered queue has messages on it and provided the trigger conditions are met.
- When triggering channels, trigger type FIRST or DEPTH is recommended.
- Disabling triggering is not under syncpoint control so triggering can not be re-enabled by backing out a unit of work. If a program backs out a unit of work or abends, triggering for DEPTH must be reenabled by MQSET, ALTER or CHGMQMQ.

MQ Problem determination - Queue Manager Diagnostics

Problem determination - Queue Manager Diagnostics

=> Error Reporting
- when connected to Queue Manager, all the logs routed to /var/mqm/qmgrs/QM_NAME/errors
- all other messages routed to /var/mqm/errors

=>Error message components
- message always include an identifier and basic text
- message contains date/date/pid/user/program/exception message/suggested action/source file which generated it
=> Log Rollover
- current message are always appended to the first error log
- rollover occurs when the log reaches ~256k
- this size setting can be changed by setting the following
-queue manager
ErrorLogSize=1048576 #1Mb error log file
-for System error logs
export MQMAXERRORLOGSIZE=1048576

=> Suppression of messages
- Allows non-critical messages to be suppressed
- can be set using the ini stanza
example
QMErrorLog:
ExcludeMesssage=9001,9002,9999 #don’t write these
SuppressMessage=9508 #only write once
Suppressinterval=30 #in any 30secs

=> Error log Recomandations
- save all error logs after a serious error occurs as well as the qm.ini
- be sure to note the time you observed the problem
- look for related messages before and after the time of the error
- try to correlate error log message with other diagnostics

=> FFST
- FFST is first failure support technology
- FFST are files written to /var/mqm/errors
- FFST file names format is AMQ[PID].x.FDC
- all threads in a process will append their FFSTs to the same file

=> FFST layout
-The header
this includes date/time/hostname/pids/probeID/builddate/user/program/process/thread/QM/probetype/monitcode etc…
-The Function stack
every thread executing MQ code has a thread control block which contains stack for MQ functions. this stack shows context in which error occured
-The Trace history
the trace shows sequence of events leading up to a failure
-The component dumps
shows the commom services control blocks
-Environment
includes all user settings at time of error

=> Base MQ tracing
- Tracing records the sequence of events in a program
- MQ supports tracing on all queue managers and clients
- Trace are binary files which requir formatting
- MQ shipps programs for starting/stopiing/formatting traces
-strmqtrc
-endmqtrc
-dspmqtrc
- traces are written to /var/mqm/trace
- trace contains a header with extended process information, then each line of trace contains pid/tid/trace data.

Migrating WebSphere MQ queue manager clusters

MQ Migration
========
Migrating queue managers is generally a simple process, because WebSphere MQ is designed to automatically migrate objects and messages, and support mixed version clusters. However, when planning the migration of a cluster, you need to consider a number of issues, which are described below.

Forward migration involves upgrading an existing queue manager to a later version and is supported on all platforms. You may wish to forward migrate in order to take advantage of new features or because the old version is nearing its end-of-service date.
Testing
———-
It is important when making any system changes to test the changes in a test or QA environment before rolling out the changes in production, especially when migrating software from one version to another. Ideally, an identical migration plan would be executed in both test and production to maximise the chance of finding potential problems in test rather than production. In practice, test and production environments are unlikely to be architected or configured identically or to have the same workloads, so it is unlikely that the migration steps carried out in test will exactly match those carried out in production. Whether the plans and environments for test and production differ or not, it is always possible to find problems when migrating the production cluster queue managers

Plan
—–
When creating the migration plan, you need to consider general queue manager migration issues, clustering specifics, wider system architecture, and change control policies. Document and test the plan before migrating production queue managers. Here is an example of a basic migration plan for a cluster queue manager:

1. Suspend queue manager from the cluster.
* Issue SUSPEND CLUSTER
* Monitor traffic to the suspended queue manager. The cluster workload algorithm can choose a suspended queue manager if there are no other valid destinations available or an application has affinity with a particular queue manager.
2. Save a record of all cluster objects known by this queue manager. This data will be used after migration to check that objects have been migrated successfully.
* Issue DISPLAY CLUSQMGR(*) to view cluster queue managers.
* Issue DISPLAY QC(*) to view cluster queues.
3. Save a record of the full repositories view of the cluster objects owned by this queue manager. This data will be used after migration to check that objects have been migrated successfully.
* Issue DISPLAY CLUSQMGR on the full repositories.
* Issue DISPLAY QC(*) WHERE(CLUSQMGR EQ ) on the full repositories.
4. Stop queue manager.
5. Take a backup of the queue manager.
6. Install the new version of WebSphere MQ.
7. Restart queue manager.
8. Ensure that all cluster objects have been migrated successfully.
* Issue DISPLAY CLUSQMGR(*) to view cluster queue managers and check output against the data saved before migration.
* Issue DISPLAY QC(*) to view cluster queues and check output against the data saved before migration.
9. Ensure that the queue manager is communicating with the full repositories correctly. Check that cluster channels to full repositories can start.
10. Ensure that the full repositories still know about the migrated cluster queue manager and its cluster queues.
* Issue DISPLAY CLUSQMGR on the full repositories and check output against the data saved before migration.
* Issue DISPLAY QC(*) WHERE(CLUSQMGR EQ ) on the full repositories and check output against the data saved before migration.
11. Test that applications on other queue managers can put messages to the migrated cluster queue manager’s queues.
12. Test that applications on the migrated queue manager can put messages to the other cluster queue manager’s queues.
13. Resume the queue manager.
* Issue RESUME CLUSTER
14. Closely monitor the queue manager and applications in the cluster for a period of time.

Backout plan
—————-
A backout plan should be documented before migrating. It should detail what constitutes a successful migration, the conditions that trigger the backout procedure, and the backout procedure itself. The procedure could involve removing or suspending the queue manager from the cluster, backwards migrating, or keeping the queue manager offline until an external issue is resolved.

Websphere MQ FFST

What is FFST?
FFST stands for First Failure Support Technology, and is technology within WebSphere MQ designed to create detailed reports for IBM Service with information about the current state of a part of a queue manager together with historical data.
What are they for?
They are used to report unexpected events or states encountered by WebSphere MQ. (Alternatively, they can be generated upon request).


Note that return codes are used for application programmers to inform them of expected states or errors in a WebSphere MQ application. There are exceptions to this rule, but as a rule of thumb, FFSTs are used to report something that will need to be actioned by:
• system administrators - such as where FFSTs report resource issues such as running low on disk space
• IBM - where FFSTs report a potential code error in WebSphere MQ that (unless already identified and corrected in existing maintenance) may need correcting
Where are they?
On UNIX systems, they are written to /var/mqm/errors
They are contained in files with the extension .FDC
The file name will begin with AMQ followed by the process id for the process which reported the error. e.g /var/mqm/errors/AMQ12345.0.FDC - is the first FFST file produced by a process with ID 12345

What do they contain?
FFST files are text files containing error reports for a single process.
If a single process produces more than one error report, these are all included within the same FFST file for that process, in the order in which they were generated.
How should I look at these files?
FFST files are just text files, so your favorite text editor is normally the best place to start.
The tool ffstsummary is also useful - it produces a summary of FFST reports in the current directory, sorted into time order. This can be a good place to start to see the errors reported in your errors directory.
For example:
[mqm@test~]$ cd /var/mqm/errors
[mqm@test errors]$ ffstsummary
AMQ21433.0.FDC 2007/04/10 10:05:45 amqzdmaa 21433 2 XC338001 xehAsySignalHandler xecE_W_UNEXPECTED_ASYNC_SIGNAL OK
AMQ21429.0.FDC 2007/04/10 10:05:45 amqzmur0 21429 2 XC338001 xehAsySignalHandler xecE_W_UNEXPECTED_ASYNC_SIGNAL OK
AMQ21469.0.FDC 2007/04/10 10:05:45 runmqlsr 21469 2 XC338001 xehAsySignalHandler xecE_W_UNEXPECTED_ASYNC_SIGNAL OK
AMQ21422.0.FDC 2007/04/10 10:05:45 amqzfuma 21422 2 XC338001 xehAsySignalHandler xecE_W_UNEXPECTED_ASYNC_SIGNAL OK
AMQ21424.0.FDC 2007/04/10 10:05:45 amqzmuc0 21424 2 XC338001 xehAsySignalHandler xecE_W_UNEXPECTED_ASYNC_SIGNAL OK
AMQ21431.0.FDC 2007/04/10 10:05:45 amqrrmfa 21431 2 XC338001 xehAsySignalHandler xecE_W_UNEXPECTED_ASYNC_SIGNAL OK
AMQ21449.0.FDC 2007/04/10 10:05:45 amqzlaa0 21449 2 XC338001 xehAsySignalHandler xecE_W_UNEXPECTED_ASYNC_SIGNAL OK
AMQ21434.0.FDC 2007/04/10 10:05:45 amqzmgr0 21434 2 XC338001 xehAsySignalHandler xecE_W_UNEXPECTED_ASYNC_SIGNAL OK
AMQ21452.0.FDC 2007/04/10 10:05:45 runmqchi 21452 2 XC338001 xehAsySignalHandler xecE_W_UNEXPECTED_ASYNC_SIGNAL OK
AMQ21417.0.FDC 2007/04/10 10:05:45 amqzxma0 21417 4 XC338001 xehAsySignalHandler xecE_W_UNEXPECTED_ASYNC_SIGNAL OK
[mqm@testerrors]$
The columns in the output above show:
• filename - which FDC file contains the FFST report
• time and date of the report
• process name - name of the process which produced the report
• process and thread ids - for the process which produced the report
• probe id
• component - part of WebSphere MQ where the report was produced
• error code - major errorcode and minor code
What does an FFST report contain?
I’ve added some numbers on the left to mark out points worth noting…
Sample FFST Report:
+—————————————————————————–+
| |
| WebSphere MQ First Failure Symptom Report |
| ========================================= |
| |
(1) | Date/Time :- Wednesday Feb 02 13:25:56 IST 2008 |
(2) | Host Name :- joseph.joseph.com (Linux 2.6.9-42.0.10.EL) |
| PIDS :- 5724H7207 |
(3) | LVLS :- 6.0.2.0 |
| Product Long Name :- WebSphere MQ for Linux (POWER platform) |
| Vendor :- IBM |
(4) | Probe Id :- XC338001 |
| Application Name :- MQM |
(5) | Component :- xehAsySignalHandler |
(6) | SCCS Info :- lib/cs/unix/amqxerrx.c, 1.214.1.4 |
| Line Number :- 737 |
| Build Date :- Sep 21 2007 |
| CMVC level :- p600-200-060921 |
| Build Type :- IKAP - (Production) |
(7) | UserID :- 00011243 (mqm ) |
( | Program Name :- runmqlsr |
| Addressing mode :- 64-bit |
(9) | Process :- 16337 |
| Thread-Process :- 16337 |
(10) | Thread :- 2 |
| ThreadingModel :- PosixThreads |
(11) | Major Errorcode :- xecE_W_UNEXPECTED_ASYNC_SIGNAL |
| Minor Errorcode :- OK |
| Probe Type :- MSGAMQ6209 |
| Probe Severity :- 3 |
(12) | Probe Description :- AMQ6209: An unexpected asynchronous signal (2 : |
| SIGINT) has been received and ignored. |
| FDCSequenceNumber :- 0 |
| Arith1 :- 2 2 |
(13) | Comment1 :- SIGINT |
| Comment2 :- Signal sent by pid 0 |
| |
+—————————————————————————–+

(14) MQM Function Stack
xehAsySignalMonitor
xehHandleAsySignal
xcsFFST

(15) MQM Trace History
{ xppInitialiseDestructorRegistrations
} xppInitialiseDestructorRegistrations rc=OK
{ xehAsySignalMonitor
-{ xcsGetEnvironmentInteger
–{ xcsGetEnvironmentString
–} xcsGetEnvironmentString rc=xecE_E_ENV_VAR_NOT_FOUND

(16) Process Control Block
0×80006ad890 58494850 000029E8 00003FD1 00000004 XIHP..)…?…..
0×80006ad8a0 00000000 10029F70 00000000 10033A50 …….p……
0×80006ad8b0 00000000 00000000 00000000 00000000 …………….
0×80006ad8c0 to 0×80006ad900 suppressed, 5 lines same as above
0×80006ad910 00000000 00000001 00000000 00000000 …………….
0×80006ad920 00000000 00000000 00000000 00000000 …………….
0×80006ad930 to 0×80006ad9d0 suppressed, 11 lines same as above
0×80006ad9e0 00000000 00000000 00000001 00568001 ………….V..
0×80006ad9f0 00FB8000 00000000 00000080 00760000 ………….v..
0×80006ada00 00000000 00000000 00000000 00000000 …………….
0×80006ada10 to 0×80006ae9f0 suppressed, 255 lines same as above
0×80006aea00 00000000 FFFFFFFF FFFFFFFF 00000000 …………….
0×80006aea10 00000000 00000000 00000001 FFFFFFFE …………….
0×80006aea20 00000001 00000000 00000000 00000000 …………….
0×80006aea30 00000080 0069A380 00000000 00000000 …..i……….
0×80006aea40 00000000 00000000 00000000 00000000 …………….

etc

(17) Environment Variables:
MANPATH=/opt/csm/man:
HOSTNAME=joseph.joseph.com
TERM=xterm
SHELL=/bin/bash
HISTSIZE=1000
SSH_CLIENT=::ffff:9.20.94.90 2625 22
QTDIR=/usr/lib/qt-3.3
OLDPWD=/root
SSH_TTY=/dev/pts/1
USER=root
LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40…
KDEDIR=/usr
MAIL=/var/spool/mail/root
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/opt/csm/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:…
INPUTRC=/etc/inputrc
PWD=/var/mqm/errors
LANG=en_GB.UTF-8
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
SHLVL=1
HOME=/root
LOGNAME=root
SSH_CONNECTION=::ffff:9.20.94.90 2625 ::ffff:9.20.63.20 22
LESSOPEN=|/usr/bin/lesspipe.sh %s
G_BROKEN_FILENAMES=1
_=/usr/bin/runmqlsr
1. Date and time that this report was produced
For many problems, this is the most useful piece of information - allowing an error report to be correlated with other known events.
2. hostname for the machine where this report was produced
3. Version and maintenance level for WebSphere MQ
This is useful when comparing an error report against a documented known problem.
4. Probe ID
This is an internal method of identifying the error report. It identifies a single point in the WebSphere MQ source code where the report was produced (consisting of two letters giving a component code, a three digit function code, and a three digit probe identifier).
This often makes it the best way to uniquely identify the error that the report is describing. More on this a bit later…
5. Component
this is the bit of WebSphere MQ which produced the report. As with the source information below, it is generally more useful to us than it is to users, although the name can sometimes give a useful hint as to the nature of the error report. For example, in this case where the report is the result of my using Control-C to generate an interrupt signal, you can see that the component which produced the report was a signal handler.
6. source information
Although this isn’t information isn’t useful to users, I thought it might be interesting to highlight that an FFST will identify exactly where it was produced, down to the source code file, line number and version
7. User id that was running the process which produced the report This is useful to confirm whether a problem was the result of insufficient user privileges.
8. process name of process which produced the report
9. process id for the process which produced the report
10. thread id for the process which produced the report
11. error codes for the report
12. a longer description of the error code for the report
This is a textual (English) description containing information that a WebSphere MQ developer thought might be helpful if the situation were to occur. Sometimes this information may be useful to users, such as messages identifying an operating system function which has failed and what the error code was. Other times, it will only useful to IBM Service.
13. additional comment information
14. function stack for the process at the time of the report
15. a history of function calls made by the process leading up to the report
16. A series of dumps

In the WebSphere MQ source code, functions can register data items that may be of interest. If it has something that could be useful (such as in diagnosing or debugging a problem), it can register it with the engine that produces FFST reports. This means that in the event of an FFST being produced, this data will be included. These items are deregistered when a function completes.
This is normally of more use to IBM Service than users, however there may be times - such as when some message data is included - when you will recognise some of the data here.
17. environment variables for the the environment of the process which produced the report

What can I do if I have an FFST report?
Monitoring for the production of FDC files is an important part of handling the occurrence of errors in a WebSphere MQ system. Prompt handling of a problem can be key to a timely resolution.
If an FDC file is created, the next step is probably to determine if this is something that requires you to take an action, and if so how urgent is it. A number of factors will influence this, including:
• Are queue managers running?
• Are applications still working?
• Does the probe description give any insight into why the FFST was generated?
• Does the time and date of the FFST correspond with any other known events or occurrences at the same time which may explain the error?
If the FFST identifies a resource issue, such as low disk space, then this will normally give enough information for a system administrator to identify and correct the source of the problem.
If you are unable to determine an explanation for the FFST, then a useful next step is to look to see if others have seen this FFST before, and if so what they found it to mean and needed to do.
This is where the probe id from the FFST is very useful. In the majority of cases (for one notable exception, see my discussion on signals below), this will be a unique eye-catcher for the issue being reported. This means that you can search for this short string on the WebSphere MQ support site on ibm.com or in the IBM Support Assistant. Often, this will reveal cases where someone has encountered this FFST before and the fix that resulted.
Beyond this point, you will most likely need to raise a PMR with IBM Service. It is useful to send all FFSTs from your system (rather than just the one that you believe to be of interest), as following the history can be key to resolving an issue. It is also useful to send the WebSphere MQ system (/var/mqm/errors/AMQ*.LOG) and queue manager (/var/mqm/qmgrs/errors/AMQ*.LOG) error logs, together with a clear description of what you are seeing and the impact on the system and your business.
Signal handling
Generally find the probe id to be a unique identifier for a specific problem. While this is usually true, one notable exception is FFSTs produced by the signal and exception handlers.
The signal handler component produces FFSTs to report signals sent to WebSphere MQ processes. This means that the information in the FFST (such as the probe id and source code file, line number, etc.) is about the signal handler which caught the signal, not whatever it was that caused or created the signal.
This is less of a problem if the signal was generated externally to WebSphere MQ, such as the SIGINT that I generated with Ctrl-C in the example above. The FFST contains information about the process which was sent the signal and the time and date of the signal.
It can be more complex if the signal is generated from elsewhere within WebSphere MQ, such as a SIGSEGV from a segmentation fault in another WebSphere MQ process. The exception handler will generate an FFST to record the SIGSEGV, however it is important to bear in mind that any such FFST contains a report about where the SIGSEGV was caught, not where it was generated. This doesn’t mean that the cause cannot be found, but it does mean that the FFST information such as the probe id is not necessarily the sort of unique eye-catcher described above.
Generating FFSTs on request
I mentioned above that it is possible to generate FFSTs manually. This can be done using the following commands:
amqldbgn -p PID (on Windows)
or
kill -USR2 PID (on UNIX platforms)
where PID is the process ID for a WebSphere MQ process. FFST reports generated in this way will have a probe id that ends in 255.

Q's operations

- Remote Queue Operations
New Remore Queue
=================
DEFINE QREMOTE (’RQ_NAME’) +
DESCR(’Description’) +
PUT(ENABLED) +
EFPSIST(NO) +
MAXDEPTH(200000) +
MSGDLVSQ(PRIORITY) +
XMITQ(’XQ_NAME’) +
TRIGTYPE (FIRST) +
RNAME(’RLQ_NAME’) +
RQMNAME(’RQM_NAME’) +
QDEPTHHI (80) +
QDEPTHLO (20) +
REPLACEDEFPSIST(NO) -> Persistant YES/NO
TRIGTYPE (FIRST) -> Trigger type (if present)
MAXDEPTH(20000) -> Max depth
MSGDLVSQ(PRIORITY) -> Message delivery meth
PUT -> Put (enable/disable)
XMITQ -> Transmit Queue name
RNAME -> Remore local queue name
RQNAME -> Remote Queue Manager name
QDEPTHHI -> High Queue depth
QDEPTHLO -> Low Queue Depth
REPLACE -> Replace if existing

Change the Queue properties
============================
alter qremote RQ_NAME [property]

Display Queue properties
========================
display qremote RQ_NAME

Give permissions to Queue
==========================
setmqaut -m RQ_NAME -n QM_NAME -t queue -g group/user [+browse +get +dsp +put]

Display existing permissions
=============================
dspmqaut -m LQ_NAME -n QM_NAME -t queue -g group/user


Websphere MQ - Transmit Queue Operations

New Transmit Queue
==================
DEFINE QLOCAL(’XQ_NAME’) +
DESCR (’Description’) +
DEFPSIST(NO) +
TRIGTYPE (FIRST) +
MAXDEPTH(200000) +
MSGDLVSQ(PRIORITY) +
USAGE(XMITQ) +
QDEPTHHI (80) +
QDEPTHLO (20) +
REPLACEDEFPSIST(NO) -> Persistant YES/NO
TRIGTYPE (FIRST) -> Trigger type (if present)
MAXDEPTH(20000) -> Max depth
MSGDLVSQ(PRIORITY) -> Message delivery meth
USAGE(XMITQ) -> Queue usage (XMITQ)
QDEPTHHI (80) -> High Queue depth
QDEPTHLO (20) -> Low queue depth
REPLACE -> Replace if existing

Change the Queue properties
============================
alter qlocal XQ_NAME [property]

Display Queue properties
========================
display qlocal LQ_NAME

Give permissions to Queue
==========================
setmqaut -m XQ_NAME -n QM_NAME -t queue -g group/user [+browse +get +dsp +put]

Display existing permissions
=============================
dspmqaut -m LQ_NAME -n QM_NAME -t queue -g group/user

Websphere MQ - Local Queue Operations

New Local Queue
================
DEFINE QLOCAL(’LQ_NAME’) +
DESCR (’description’) +
DEFPSIST(NO) +
TRIGTYPE (FIRST) +
MAXDEPTH(200000) +
MSGDLVSQ(PRIORITY) +
USAGE(NORMAL) +
QDEPTHHI (80) +
QDEPTHLO (20) +
REPLACE

DEFPSIST(NO) -> Persistant YES/NO
TRIGTYPE (FIRST) -> Trigger type
MAXDEPTH(20000) -> Max depth
MSGDLVSQ(PRIORITY) -> Message delivery meth
USAGE(NORMAL) -> Queue usage (NORMAL/XMITQ)
QDEPTHHI (80) -> High Queue depth
QDEPTHLO (20) -> Low queue depth
REPLACE -> Replace if existing

Change the Queue properties
============================
alter qlocal LQ_NAME [property]

Display Queue properties
========================
display qlocal LQ_NAME

Give permissions to Queue
==========================
setmqaut -m LQ_NAME -n QM_NAME -t queue -g group/user [+browse +get +dsp +put]

Display existing permissions
=============================
dspmqaut -m LQ_NAME -n QM_NAME -t queue -g group/user


Websphere MQ - Queue Manager Operations

Create new Queue manager
crtmqm QM_NAME

Display all Queue manages
dspmq

starting Queue Manager
srtmqm QM_NAME

Stopping Queue Manager
endmqm QM_NAME

Connect to Queue Manager
runmqsc QM_NAME

Delete Queue manager
dltmqm Queue_Manager

Websphere MQ - Listener Operations

New Listner
===========
def listener(LISTENER_NAME) trptype(tcp) port(PORT_NUMBER)

Start listener
===============
start listener (LISTENER_NAME)

Stop Listener
==============
stop listener (LISTENER_NAME)

Listener Status
===============
display lsstatus (LISTENER_NAME)

Websphere MQ - Receiver Channel Operations

New Receiver Channel
===================
DEFINE CHANNEL(CHANNEL_NAME) CHLTYPE(RCVR) REPLACE

Starting Channel
================
start channel (CHANNEL_NAME)

Stopping Channek
================
stop channel (CHANNEL_NAME)

Status of channel
=================
display chs (CHANNEL_NAME)

Display channel properties
==========================
display channel (CHANNEL_NAME)

Websphere MQ v6 Tutorial

MQ Series/MQ: - It is an IBM web sphere product which is evolved in 1990’s. MQ series does transportation from one point to other. It is an EAI tool (Middleware). WebSphere MQ.

VERSIONS:-5.0, 5.1, 5.3, 6.0, 7.0(new version).
Currently widely used version is 6.2
Note: - MQ series supports more than 35+ operating systems. It is platform independent. For every OS we have different MQ series software’s.

MQ series deals with two things, they are OBJECTS, SERVICES.
In OBJECTS we have
• QUEUES
• CHANNELS
• PROCESS
• AUTHENTICATION
• QUERY MANAGER.
In SERVICES we have LISTENERS.

Objects: - objects are used to handle the transactions with the help of services.

QUEUE MANAGER maintains all the objects and services.

QUEUE: it is a database structure which stores messages until the application or program receives messages.

TYPES OF QUEUES:-
• Local Queue
• Alias Queue
• Model Queue
• Remote Queue
• Repository Queue

Local Queue:-
A queue is local if it is owned by the queue manager to which the application program is connected. It is used to store messages for programs that use the same queue manager. For Example, program A and program B each has a queue for incoming messages and another queue for outgoing messages. Since the queue manager serves both programs, all four queues are local.
Note: Both programs do not have to run in the same workstation. Client workstations usually use a queue manager in a server machine.

Remote Queue:-
The queue which holds the address of the remote queue manager where the message has to be sent or delivered.
It is a logical queue where we cannot store the messages and get the messages.
Note: To send the messages we use only Remote Queue, none other than this

Message Flow from remote Queue
“Remote queue-> Transmission queue-> Channel->Network receiver channel-> Local queue (finally the message will reach here) “
CHANNEL Channel (123.456)channel name.
CHLTYPE (SDR) sender channel
TRPTYPE (TCP) Transport type using TCP protocol
CONNAME (127.0.0.1)(1414)?the channel will connect to the IP address specified in the conn name and looks for the queue manager which is having listener, port number(1414) and connects to the queue manager.
XMITQ (TQ)?the channel will receive the messages from transmission queue manager.

ALIAS QUEUE:-
Alias queues are not real queues but they are definitions. They are used to assign different names to the same physical queue.
Advantages of alias queue allow multiple programs to work with the same queue but with different attributes or properties.
Example:
Alias for LQ with different parameters
DEFINE QALIAS (PQ) TARGQ (LQ) GET (DISABLED) PUT (ENABLED)
DEFINE QALIAS (PQ) TARGQ (LQ) PUT (ENABLED) GET (DISABLED)
DEFINE QLOCAL (LQ)

MODEL QUEUE:-
A model queue is not a real queue. It is a collection of attributes that are used when a dynamic queue is created.

Repository Queue:-
Repository queues have existed since Version 5.1 and Version 2.1 for OS/390. They are used in conjunction with clustering and hold either a full or a partial repository of queue managers and queue manager objects in a cluster (or group) of queue managers.

TYPES OF LOCAL QUEUE:-
• Dead letter Queue
• Transmission Queue
• Initiation Queue
• Local Queue.

DEAD-LETTER QUEUE: - the enrooted (or) undelivered messages will be landed in to the dead letter queue.
We have one control command called runmqdlq.It is a control command which is used to route the messages through .rul table.
This is called dead letter handler. It is important that we need a dead letter queue defined for every queue manager.
Note:- For one Queue manager we can’t have two dead letter queues.
We have system defined objects called SYSTEM.DEAD.LETTER.QUEUE. Or we can use our own dead letter queue. The messages those are landed in the dead letter header (DLH). By seeing the dead letter header, we can find the reason and the destination.
RULE TABLE:-
Syntax:- DESTQ(DLQ) DESTQM(222) REASON(*) WAIT(NO) FWDQ(LQ) FWDQM(222) HEADER(NO)
Runmqdlq:-rule table path

TRANSMISION QUEUE:-TQ will receive messages from Remote queue and hits or sends the messages to the channel.

CHANNELS:-
It is a Networked program to transmit or pas the messages over the network. Channel will receive the messages from XMITQ which is defined in the definition of the channel. Transmission queue is also a local queue.

TYPES OF CHANNELS:-
• Message channels.
• MQI Channels.

MESSAGE CHANNELS:-Message channels are one way piping channels. They are used for sending or receiving the messages. Message channels are unidirectional.

TYPES OF MESSAGE CHANNELS:-
• Sender Channel(SDR)
• Receiver Channel(RCVR)
• Server Channel(SVR)
• Requester Channel(RQSTR)
• Cluster Sender Channel(CLUSSDR)
• Cluster Receiver Channel(CLUSRCVR)

MQI CHANNELS:-These channels are two way piping channels which can send and receive the messages in both ways.
TYPES:-
• Server Connection Channel (SVRCONN)
• Client Connection Channel (CLNTCONN)

COMBINATION OF CHANNELS:-
• Sender and Receiver
• Server and Requester
• Cluster sender and Cluster Receiver
• Server Receiver
• Sender Requester

LISTENER:-
• It is a service of MQ series
• Every Queue Manager will have a listener defined with a unique port number.
• (Default port number is:-1414)
• Listener acts as a mediator between external application or queue managers connecting to the queue manager.
• To contact the queue manager we should approach through Listener.

MQI COMMANDS:-
MQI Commands are of three types.
• CONTROL COMMANDS
• SCRIPT COMMANDS
• PCF (programmable command format) COMMANDS.

CONTROL COMMANDS case sensitive)
• Dspmqver :-to display MQ series version
• Dspmq :-to view all queue managers of MQ series.
• Crtmqm :-to create a queue manager
• Strmqm :-to start queue manager
• Runmqsc :-to enter in to particular queue manager
• Endmqm :-to end a queue manager
• Dltmqm :-to delete a queue manager
• Dspmqcsv :-to display command server
• Endmqcsv :-to end command server
• Strmqcsv :-to start command server
• Runmqlsr :-to run listener service
• Endmqlsr :-to end listener service
• Runmqchl :-to run a channel out of queue manager
• Runmqdlq :-to execute dead letter handle with the help of rule table
• Setmqaut :-to set authorizations for particular objects like queuemanager,queue’s channels, listeners to user or group
• Dspmqaut :-to display authorization for particular user
• Dmpmqaut :-to dump authorization for particular user
• Runmqchi :-to run a channel initiator for particular queue manager
• Runmqtrm :-to run trigger monitor on initiation queue for particular queue manager
• Rcdmqimg :-to take objects (or) record image of a particular queue manager objects
• Rcrmqobj :-to recreate the mq objects which are already recorded
• Replace :-s

SCRIPT COMMANDS:-
After entering in to queue manager we can find script commands. Script commands are same for every queue manager. (These Commands should be used in CAPITAL LETTERS)
• DEFINE :-To define/create MQ manager objects like queue, Channels, process, and listener.
• ALTER :-to update or modify the existing objects
• DISPLAY :-to view all the properties of a particular object or to Display all objects
• DELETE :-to delete created objects
• CLEAR :-to clear the message from the queue
• END :-to come out of the queue manager
• PING :-to check whether other side channel / queue manager is ready to accept our request.
• START :- to start the particular channel or listener
• STOP :-to stop particular channel or listener
• REFRESH :-used to refresh the security every time after giving or executing, set mgr or command for queue manager or object
• RESET :-used to reset channel,cluster,queue manager
• RESOLVE :-to resolve the channel which is in indoubt state
• SUSPEND :-to suspend a queue manager from a cluster environment
• RESUME :-to remove a queue manager from a cluster environment

CHANNEL STATES: - Channel states are of 5 types
• Running
• Inactive
• Retrying
• Stopped
• Paused(receiver channel)

1. RUNNING: - before going to Running state the status will be initialization and binding Initialization:-channel will initiate the listener Binding:-sender channel binds with receiver, after that it Goes to running state
2. INACTIVE:-we have one attribute called disconnect interval (DISCINT) with 6000 milli seconds (default) and it can be changed as of our convenience. If the channel is idle for a particular period defined in disconnect interval, the channel will go to inactive state.
3. RETRYING:-the channel goes to retrying state if the other side queue manager will not be available, network issue, may be listener not running, may be receiver channel is in pause state, and may be the receiver channel transportation type is different…. Etc.
4. PAUSED STATE:- this state is applicable for receiver (RCVR) channel. Paused state occurs when the receiving queue is full.
Note:-
1. If we do any changes to the channels, listeners, queue manager, to effect the changes we need to stop and then start them.
2. Before starting a channel listener should be in active / running, we can check by pinging the channel.
3. Ping is used to check whether the receiver is in active state or not.
Syntax: - PING CHANNEL (CHANNEL NAME)

MULTI-HOPPING gate way)
Passing the messages between more than one intermediate queue managers is called Multi-Hopping.
Note:-
For every queue, except remote queue we have two properties.
1. open input count ( Iproess )
2. open output count ( Oprocss )
3. the application which is connected and putting the messages is called “ O process “
4. The application which is processing(getting) the messages is calles “ I procss “

PROCEDURE TO CREATE MULTI-HOPPING:-
1. Create a queue manager QM1, QM2, QM3.
2. Start the queue managers QM1, Create a remote queue with attributes local queue name (Remote Queue Manager) i.e Rname QM3 in RQMname and the transmission queue called XMITQ (TQ).
3. Create a transmission queue called (TQ)
4. Create a sender channel from (QM1.QM2)
5. In Qm2 create, Create a receiver channel (QM1.QM2)
6. Create a transmission queue with name target queue manager name called QM3.
7. Create a sender channel from (QM2.QM3) with transmission queue called XMITQ (QM3)
8. In QM3 create a local queue called (LQ) which is defined in remote queue of QM1 Rqueue(QM1)
9. Create a receiver channel (QM2.QM3)
We should have two listeners in QM2 and QM3.

GENERAL ERRORS OCCURING IN REALTIME SCENARIO:-
1. Mqrc 2059 :- Qmanager not available
2. mqrc 2058 :- Qmanager name error
3. mqrc 2085 :-unknown object name
4. mqrc 2035 :- Not authorized
5. mqrc 2033 :-No message available.
(mqrc—mq reason code)

TRIGGERING:-
1. This is an automated event driven by MQ series
2. Triggering is an event which occurs when specific conditions are met on a queue
3. Triggering are of two types
1. CHANNEL TRIGGERING
2. APPLICATION TRIGGERING

CHANNEL TRIGGERING: - channel triggering is an event which fires the channel when ever a certain conditions are met on transmission queue.

Disconnect Interval of a Channel :-It is an attribute or property of the channel(DISCINT).if the channel is idle for particular interval of time the channel will go to inactive state.(default time is 6000 milli seconds)

TRIGGER CONDITIONS:-
• Trigger ON
• Trigger type(first(t.type),every, depth)
• Trigger data(channel name which is to be fired)
• Initiation queue(SYSTEM.CHANNEL.INITQ)
In command prompt:-
DEFINE QLOCAL (TQ) USAGE (XMITQ) TRIGGERTYPE (FIRST) TRIGDATA (111.222) INITQ (SYSTEM.CHANNEL.INITQ)
To make changes use alter command
ALTER QLOCAL (TQ) TRIGGER TRIGTYPE (FIRST) TRIGDATA (111.222) INITQ (SYSTEM.CHANNEL.INITQ)
If we want to remove the trigger condition put NO before trigger condition.

CHANNEL TRIGGERING PROCESS:-
After giving specific conditions to a transmission queue, whenever the messages comes to the transmission queue, the queue manager will look at the queue, if it is triggered the queue manager will fire a trigger message in to initiation queue(SYSTEM.CHANNEL.INITQ) with the information called trigger type, trigger data, the channel which is to be fired.
At the initiation queue (SYSTEM.CHANNEL.INITQ) channel initiator will be watching (monitoring) the initiation queue.
When ever the trigger message comes to initiation queue, the channel initiator will read the information and initiates the sender MCA (message channel agent).the sender message channel agent will start the channel (which is mentioned in the trigger data).
Note:-MCA (message channel agent) is a program which is defined automatically whenever a queue manager is created.
We have two types of MCA
• SENDER MCA(SDRMCA)
• RECEIVER MCA(RCVRMCA)

CHANNEL INITIATOR:-
It is a process running on a queue manager when queue manager is in running state. For every queue manager there will only one channel initiator
Note:- 1.In MQseries 5.3 we have to run this channel initiator as a separate process for every queue manager.
2.If we use “&” any process will run at background. this applicable for all.
Syntax:- runmqchi –m Qmanagername –q initq.
Example :- runmqchi –m QM1 –q SYSTEM.CHANNEL.INITQ
To run channel initiator for queue manager QM1.
In solaris / unix /linux /AIX we run the channel initiator as follows.
Runmqchi –m QM1 –q SYSTEM.CHANNEL.INITQ &

APPLICATION TRIGGERING:-when ever specific conditions met on a local queue application triggering works.

TRIGGER CONDITION:-
• Trigger ON
• Trigger type(first, every(t.type),depth)
• Initiation queue(our own defined local queue)
• Process
DEFINE QLOCAL (LQ) TRIGGER TRIGTYPE (EVERY) INITQ (IQ) PROCESS (NOTEPAD).
DEFINE PROCESS (NOTEPAD) APPLICID (NOTEPAD.EXE) APPLTYPE (WINDOWS)
Runmqtrm –m QM1 –q IQ

BACKGROUND PROCESS:-
1. When ever the message comes to triggered local queue, queue manager will fire trigger message with information called trigger type and the process definition (application which is to be triggered) in to the initiation queue (IQ) (our own queue).
2. At the initiation queue a long running time program called trigger monitor will be watching (monitoring) the initiation queue.
3. Whenever the trigger message occurs in the initiation the trigger monitor will pick the information and starts the application which is defined in the process.
DEFINE PROCESS (NOTEPAD) APPLICID (NOTEPAD.EXE) APPLYTYPE (WINDOWS NT)

COMMAND SERVER:-it is a background process for queue manager when the queue manager starts command server will be running (default)
Note: - we have one attribute (SCMDSERV) and we have two options in that
1. QMGR
2. MANUAL
By default the queue manager command server will be under control of (QMGR)
If we change the SCMDSERV attribute to manual then we need to start command server manually.

CONTROL COMMANDS FOR COMMAND SERVER:-
• Dspmqcsv
• Strmqcsv
• Endmqcsv
1. Dspmqcsv: - to display the command server for particular queue manager
Syntax:-dspmqcsv qmgrname
E.g.:- Dspmqcsv QM1.qmgr
2. Strmqcsv:-to start the command server for a particular queue manager
Syntax:-strmqcsv –a qmgrname
Eg:-strmqcsv Qm1
3. Endmqcsv:-to end the command server for a particular queue manager
Syntax:-endmqcsv –c –I qmgrname
Eg :- endmqcsv –I QM1(queue manager)
-c stops the command in a controlled manner.
-I stop the command immediately.

USE OF COMMAND SERVER:- The command server will allow commands to execute on a queue manager using
(SYSTEM.ADMIN.COMMAND QUEUE)
When the command server is stopped the commands, the commands will be stored in the command queue called
(SYSTEM.ADMIN.COMMAND QUEUE)
After command server comes up the commands would be executed those are in the command queue.

AUTHORIZATIONS:- MQseries provides authorizations(permissions) for the users in two levels
1. Qmanager level
2. Object level
MQMgroup:- This group is automatically created by MQseries after installation. It also creates one user (MUSR_MQADMIN)
The users should belong to MQM group so that they can have all the permissions to administer MQ series.

COMMANDS TO SET AUTHORIZATIONS:-
Setmqaut:- this command is used to set the authorizations.
Syntax:- setmqaut[-m qmgrname] [-n objname] –t objtype [-p principal /-g group] [-s service component ]

Dspmqaut :-to display the authorizations which are set to the queue manager.
Syntax:-dspmqaut[-M qmgrname] [-n objname ] –t objtype [-p principal/ -g group ] [-s service component]

Dspmqaut –m QM1 –t qmgr –p XX(new user)

The entity XX have the following authorizations for object QM1
• Inq
• Connect
• Altusr
• Crt
• Dlt
• Chg
• Dsp
• Setid
• Setall
Object level :-
Syntax:-
Setmqaut –m QM1 –n LQ –t queue –pXX +put
Dspmqaut –m QM1 –n LQ –t queue –p XX
The setmqaut command completed successfully

Semqaut –m QM1 –n(20.30) –t channel –pXX +allmqi
Runmqsc QM1
Starting MQSC for queue manager 1
• REFRESH CLUSTER
• REFRESH SECURITY(generally we refresh security)
Result: web sphere security cache refreshed

TROUBLE SHOOTING METHODS:
LOGS:- MQseries have two types of logs
1. TRANSMISSION LOGS
2. ERROR LOGS

TRANSMISSION LOGS:-the transactions like messages inbound(incoming) and outbound(outgoing) objects creation, permissions etc. are going to be written to the transaction logs for every queue manager
Default path for log files in Windows:-
[ c:\programfiles\IBM\websphere MQ\log\QMGR(QM1)\active directory\log files ]
Default path for log files in LINUX, UNIX, SOLARIS, AIX (other than windows):-
[ $/var/MQM/log/Qm1/active/logfiles ]

Transmission logs are of two types:-
1. CIRCULAR LOGS
2. LINEAR LOGS

LINEAR LOGS: - In linear logs we can recover objects which are damaged and we can take backup and clear the transactions.
By using linear logs we can restart, recover and Image backup. In this we need some administrative tasks to monitor the logs and to clear the logs.
CHECKPOINT:-It is nothing but creation of objects, which are stored as a transaction and are stored at Checkpoint (objects are LQ, TQ, and Channel…etc)
Creation of queue manager in linear logging:-
Syntax:-
Crtmqm –LL –Lf 2048 –Lp 10 –LS 1 QM2
• Lq to create a queue manager in linear logging
• Lf to specify the log file size
• Lp to specify the number of log primaries
• Ls to specify the number of secondary logs
Note:-1. In transaction logs we have log primary and log secondary.
2. We can view log primary files but we cannot view log secondary Files.
3. By default queue manager will take –Lp as 3 and –Ls as 2.
4. We can define log primary files maximum up to 250 files and log Secondary files maximum up to 254 files.
Log primary files maximum—250
Log secondary files maximum—254
Creation of image backup by using linear logs:
Syntax:- rcdmqimg
Rcdmqimg[-z] [-L] [-m Qmgrname ] –t objtype[generic object name]
Rcdmqimg –m Qm1 –t queue LQ
To recover or recreate:-
Rcrmqobj? this command is used to recover the objects.
Syntax:-rcrmqobj[-z] [-m Qmgrname] –t objtype[generic objname]
Eg:- rcrmqobj –m Qm1 –t q LQ

ERROR LOGS:-
The operations going on(running) on MQ series will be written to errorlogs.
We have two types of error logs,
1.MQseries level
2.Queue manager level errors
Queue manager level errors:-the operations and errors are written to the queue manager error folder.
Default path for windows :
[ c:\program files\IBM\websphere MQ\Qmgrs(QM1)\errors\logfiles ]
Path for UNIX, LINUX, and SOLARIS:-
[$/var/mqm/qmgrs/Qm1/errors/logfiles ]
MQ series level errors :- the operations or errors which are occurring on MQ series are considered as MQ series level errors.
Default path for windows :-
[ C:]program files\IBM\Websphere mq\errors\log files ]
Path for UNIX, LINUX, SOLARIS :-
[ $/var/mqm/errors/logfiles ]

MQ series Client :- The person or user or application trying to connect access MQseries server or queue manager they need MQ series client installed at their side

MQI channels :-The MQseries client will interact with MQ series server using server connection (SVRCONN) or Client connection channel(CLNTCONN)
In MQ client sid ewe have three environmental variables
1. MQSERVER ( MQI channels )
2. MQCHLTAB ( MQI channel tables )
3. MQCHLIB (MQI channel library )

Creation of server connection channel :-
DEFINE CHANNEL(SVR) CHLTYPE(SVRCONN) TRPTYPE(TCP) DESCR(‘SERVER CONNECTION CHANNEL(not mandatory))
Syntax:-
Set mqserver=server connection channel name/trptype/IP address(port)
Eg :- set Mq server=SVR\tcp\127.0.0.1(1000)
Set MQSERVER
Result:- svr\tcp\127.0.0.1(1000)

PERSISTENT AND NON-PERSISTENT MESSAGES :-
MQSeries differentiates
Between persistent and non-persistent messages. Delivery of persistent messages is assured; they Are written to logs to survive system failures. In an AS/400 these logs are Journal Receivers.
Non-persistent messages cannot be recovered after a system restart.

How a Client Sends a Request:-
The client starts a program that puts a message on a queue. For this function five MQSeries API calls are executed
• MQCONN to connect to the queue manager in the server
• MQOPEN to open the message queue QS1 for output
• MQPUT to put a message in the queue
• MQCLOSE to close the queue QS1
• MQDISC to disconnect from the queue manager

How the Client Receives a Reply :-
The client program knows the name of its input queue, here QA1 or QB1. The application can use two modes of communication: • Conversational
If the application uses this mode of communication with the server program, it waits for the message to arrive before it continues processing. This means, the reply queue is open and an MQGET with wait option has been issued.
The client application must be able to deal with two possibilities:
• The message arrives in time.
• The timer expires and no message is there.