Want to know what all TSM administrators did in the last 24 hours in TSM?
# dsmadmc -comma -id=readonly -password=readonly query actlog s=ANR2017I begind=-1 begint=09:00 endd=today endt=09:00 | grep -v -i readonly | grep -v -i ibm-oc-server1
This assumes you have an administrator account configured, known as
readonly with password
readonly, which has no privileges.
This command will show you all administrator actions from 9 AM yesterday until 9 AM today.
In case you wish to create a readonly user within TSM, run the following command:
register admin readonly readonly contact="Readonly account'
There is no need to grant any authority to the readonly account. By just creating the readonly account, this account can perform read actions, such as querying the activity log, and can not make any changes.
Tivoli Storage Manager (TSM) is a backup system. Not just any backup system, but probably the best there is. It exists for over a decade and is a product of IBM. It used to be known as ADSM (Adstar Distributed Storage Manager); later on it was renamed to TSM (Tivoli Storage Manager) and nowadays it is known as ITSM (IBM Tivoli Storage Manager).
One of the most important benefits of TSM is the fact that it runs on many systems; it has a broad hardware support. TSM runs on AIX, HP-UX, Linux, Sun Solaris, and Windows. Client software for even more operating systems exist (Such as Mac, Netware, OS400, Tru64UNIX), thus enabling the backup of other operating systems to TSM.
Another important aspect of TSM: the progressive incremental backup. Only files that are changed or are new to the system are backed up, therefore
eliminating unnecessary data transfers, and gives you faster backup times. Progressive incremental backups needs to backup less data, thus saving network bandwith, tapes and management overhead. No more full backups are required.
TSM can be combined with several Tivoli Data Protection agents. These are add-ons to TSM, which enable you to create backups of several databases (e.g. Oracle or DB2), ERP applications (e.g. SAP/R3), mail (e.g. Exchange), and others. These TDP agents also enables online backups, so vital systems can stay online during backups.
Besides backup and restore, TSM also includes functions for archiving/retrieval and hierarchical storage management, to free up disk space normally used by files that aren't accessed for an extended period of time.
TSM can be administered centrally, either via the command-line or via a Web-based Enterprise Console. TSM is based on a (DB2) database, which needs zero management. All information of backups, backup versions and overhead is stored in the TSM database. TSM has its own powerfull scheduler, for either backup schedules or TSM maintenance schedules (so-called administrative schedules) which automate a lot of house-keeping jobs in TSM.
TSM stores its backup data in a variety of storage pools, which can consist of various sequential (tape) media or direct-access (disk) media. The storage pools are very flexible and data can be moved from one storage pool to another (migration). Building a hierarchy of storage pools is possible, thus enabling fast backups to disk storage pools and later on, migration from disk to tape storage pools. Data storage is based on policies, defined by the administrator in TSM. These policies include information on how many backup versions to store, and how long to retain the backups.
Note: From TSM 5.3 the Web Admin GUI is no longer supported. Because of popular demand, IBM has made the TSM 5.2 Web Admin GUI available for TSM 5.3.
To enable "etherchannel" or "bonding" in Linux nomenclature:
- Add these two lines to /etc/modprobe.conf:
alias bond0 bonding
options bond0 miimon=100 mode=1 primary=eth0
Entry "mode=1" simply means active/standby. Entry "miimon" is the number in milliseconds to wait before determining a link dead (Change eth0 to match your primary device, if it is different. Blades sometimes have eth4 as the primary device).
- In /etc/sysconfig/network-scripts create ifcfg-bond0 with the following (of course, change the network info to match your own):
DEVICE=bond0
BROADCAST=10.250.19.255
IPADDR=10.250.19.194
NETMASK=255.255.255.0
GATEWAY=10.250.19.1
ONBOOT=yes
BOOTPROTO=none
- Change ifcfg-eth0 and ifcfg-eth1 (or whatever they are) to resemble this:
DEVICE=eth0
HWADDR=00:22:64:9B:54:9C
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPPROTO=none
Leave the value of HWADDR to whatever it is in your file. This is important. It is this devices MAC Address.
- Run /etc/init.d/network restart. You will want to do at least this part from the console, in case something goes wrong.
- Once you get your "OK" and the prompt comes back, do an ifconfig -a. You should see bond0.
- Make sure you can ping your default gateway. After that, all should be good.
Note: When making back up copies of the ifcfg-* files, you must either move the backup files out of this directory or change your backup copy strategy for these files. The primary network script that reads these files, basically runs: ls ifcg-*. It then creates an interface based on the part after the dash ("-"). So if you run, for example:
# cp ifcfg-eth0 ifcfg-eth0.bak
You will end up with an alias device of eth0 called eth0.bak. Instead do this:
# cp ifcfg-eth0 bak.$(date +%Y%m%d).ifcfg-eth0
That foils the configuration script and allows to keep backup/backout copies in the same directory with the working copies.
Having an appropriate amount of swap space is important for optimal system performance. Simple commands allow monitoring swap space utilization. To get a summary of total system swap space, use the swap command:
# swap -s
total: 597744k bytes allocated + 99760k reserved = 697504k used, 095216k available
The output of this command shows the amount of swap space used (697504KB in this example) and available (95216KB), and further breaks down the used swap space into allocated and reserved. Allocated space represents swap space currently in use. Reserved space is in limbo, not available, not in use, but reserved for future use.
To get details on the individual devices or files that constitute the swap space, use:
# swap -l
swapfile dev swaplo blocks free
/dev/dsk/c0t0d0s1 32,1 16 2624560 2624560 /dev/dsk/c0t8d0s1 32,57 16 2624560 2624560
The swapfile column is the device or filename of the swap component. The dev column shows the major and minor device numbers for devices or zeros for a file. Blocks is the total size of the swap component in 512 byte blocks (divide by two for KB) and free shows the number of 512 byte blocks unused.
A number of external links, related to Sun Solaris:
Official SUN sites:
Related sites:
The
Sun Solaris Operating Systems is a UNIX based operating system, derived from
Berkeley. It is quite widely used, but mostly for smaller systems, like webservers.
Nowadays it is called OpenSolaris, which is available for download at opensolaris.org.
A number of external links, related to WebSphere MQ:
Official IBM sites:
Related links:
WebSphere MQ, previously known as MQ Series, is a tool to transfer message and data from one system to another, a means of program-to-program communication. Basically, one program puts a message in a queue and the other program reads from the queue. This can be synchronous or asynchronous. It's time independant, communicating applications do not have to be active at the same time.
MQSeries runs on a variety of platforms. The MQSeries products enable programs to communicate with each other across a network of unlike components, such as processors, subsystems, operating systems and communication protocols. MQSeries programs use a consistent application program interface (API) across all platforms.
The figure shows the main parts of an MQSeries application at run time. Programs use MQSeries API calls, that is the Message Queue Interface (MQI), to communicate with a queue manager (MQM), the run-time program of MQSeries. For the queue manager to do its work, it refers to objects, such as queues and channels. The queue manager itself is an object as well.
What is Messaging and Queuing?
Message queuing is a method of program-to-program communication. Programs within an application communicate by writing and retrieving application-specific data (messages) to/from queues, without having a private, dedicated, logical connection to link them.
Messaging means that programs communicate with each other by sending data in messages and not by calling each other directly.
Queuing means that programs communicate through queues. Programs communicating through queues need not be executed concurrently.
This figure shows how two programs, A and B, communicate with each other. We see two queues; one is the "output" queue for A and at the same time the "input" queue for B, while the second queue is used for replies flowing from B to A. The squares between the queues and the programs represent the Message Queuing Interface (API) the program uses to communicate with MQSeries' run-time program, the queue manager. As said before, the API is a simple multi platform API consisting of 13 calls.
About the queue manager
The heart of MQSeries is the message queue manager (MQM), MQSeries' run-time program. Its job is to manage queues and messages for applications. It provides the Message Queuing Interface (MQI) for communication with applications. Application programs invoke functions of the queue manager by issuing API calls. For example, the MQPUT API call puts a message on a MQSeriesqueue to be read by another program using the MQGET API call. This scenario is shown in the next figure.
A program may send messages to another program that runs in the same machine as the queue manager (shown above), or to a program that runs in a remote system, such as a server or a host. The remote system has its own queue manager with its own queues. This scenario is shown in the next figure.
The queue manager transfers messages to other queue managers via channels using existing network facilities, such as TCP/IP, SNA or SPX. Multiple queue managers can reside in the same machine. They also need channels to communicate.
Application programmers do not need to know where the program to which they are sending messages runs. They put their messages on a queue and let the queue manager worry about the destination machine and how to get the messages there. MQSeries knows what to do when the remote system is not available or the target program is not running or busy. For the queue manager to do its work, it refers to objects that are defined by an administrator, usually when the queue manager is created or when a new application is added. MQSeries for Windows provides graphical user interfaces; other platforms use the command line interface or panels.
If the databases of the Libary Server and Resource Manager are installed in different DB2 instances, but on the same server host, you should catalog the Library Server database within the instance of the Resource Manager, to enable the Resource Manager to access the Library Server database. The Resource Manager needs to access the Libary Server database to validate any security tokens, the Library Server creates when people import or retreive any documents from the Resource Manager.
In the next procedure, the following texts need to be updated to your own situation:
- instance_name_resource_manager -> Name of the instance of the Resource Manager.
- hostname -> The short hostname of your server.
- resource_manager_database -> The name of the Resource Manager database.
- resource_manager_instance_owner -> The owner/userid of the Resource Manager instance.
- library_server_database -> The name of the Library Server database.
- instance_name_library_server -> Name of the instance of the Library Server.
- library_server_instance_owner -> The owner/userid of the Library Server instance.
- Log in as the database instance owner of the Resource Manager.
- Open or create the sqllib/profile.env file and add the following lines, to enable TCP/IP communication and the automatic restart:
DB2ENVLIST='EXTSHM'
DB2COMM='tcpip'
DB2AUTOSTART='TRUE'
- Open or create the sqllib/userprofile file and add the following lines:
ICMROOT=/usr/lpp/icm
ICMDLL=/home/db2fenc1
ICMCOMP=/usr/vacpp/bin
CMCOMMON=/usr/lpp/cmb/cmgmt
EXTSHM=ON
PATH=$PATH:$ICMROOT/bin/DB2
LIBPATH=$ICMROOT/lib:$ICMROOT/inso:$LIBPATH
export ICMROOT ICMDLL ICMCOMP CMCOMMON EXTSHM PATH LIBPATH
- Log off.
- Log in as the database instance owner of the Library Server.
- Open or create the sqllib/profile.env file and add the following lines, to enable TCP/IP communication and the automatic restart:
DB2ENVLIST='LIBPATH IMCROOT ICMDLL ICMCOMP EXTSHM CMCOMMON'
DB2COMM='tcpip'
DB2AUTOSTART='TRUE'
- Open or create the sqllib/userprofile file and add the following lines:
ICMROOT=/usr/lpp/icm
ICMDLL=/home/db2fenc1
ICMCOMP=/usr/vacpp/bin
CMCOMMON=/usr/lpp/cmb/cmgmt
EXTSHM=ON
PATH=$PATH:$ICMROOT/bin/DB
LIBPATH=$ICMROOT/lib:$ICMROOT/inso:$LIBPATH
export ICMROOT ICMDLL ICMCOMP CMCOMMON EXTSHM PATH LIBPATH
- Catalog the Resource Manager database instance:
db2 catalog local node instance_name instance instance_name system ostype aix
- Refresh the database directory cache:
db2 terminate
- Catalog the Resource Manager database in the system database directory:
db2 catalog db resource_manager_database at node instance_name_resource_manager
- Refresh the database directory cache:
db2 terminate
- Try to connect to the Resource Manager database:
db2 connect to resource_manager_database user resource_manager_instance_owner
- Disconnect the connection:
db2 terminate
- Log off.
In the same way as the Library Server connects to the Resource Manager database, the Resource Manager needs access to the Library Server database.
Perform te following steps on the Resource Manager machine with the Resource Manager instance owner:
- Log in as the Resource Manager instance owner.
- Catalog the Resource Manager database instance:
db2 catalog local node instance_name_resource_manager instance instance_name_resource_manager system ostype aix
- Catalog the Library Server database in the system database directory:
db2 catalog db library_server_database at node instance_name_library_server
- Refresh the database directory cache:
db2 terminate
- Try to connect to the Library Server database:
db2 connect to library_server-database user library_serveR_instance_owner
- Disconnect the connection:
db2 terminate
- Log off.
- Log in as the Library Server instance owner.
db2 catalog tcpip node CMCDB2 remote hostname server db2c_library_server_instance
- Log off.
- Log in as the Resource Manager instance owner.
db2 catalog tcpip node CMCDB2 remote hostname server db2c_resource_manager_instance
- Log off.
- Log in as root and modify /etc/services:
db2c_library_server_instance 50000/tcp
db2c_resource_manager_instance 50001/tcp
Check if you can find both databases. Log in as the resource manager instance owner. Run:
db2 list database directory
Then connect to both databases.
When you start the Resource Manager, you should see 3 java processes, when you run db2 list applications. If you don't see these processes, you probably forgot to set the DB2 environment, before starting the Resource Manager. Run BEFORE starting the Resource Manager:
. ./home/db2inst1/sqllib/db2profile
Number of results found: 469.
Displaying results: 381 - 390.
