Expiration of TSM data

how can it possible

I guess that the main confusion is that when you backing up the same data to another management class, the OLD data is rebound to that management class. Then the data retention policies are used toward the data, that in the class. Watch for the following in your dsmsched.log:

Total number of objects rebound:

Or, in your activity log:

ANE4960I (Session: 216, Node: TSMSERV)  Total number of objects rebound: 0 (SESSION: 216)  

If you wish to keep copies on different media, you can define copy storage pools on the media and backup primary storage pool into the copy storage pools. However, all the data will be held by the same management class under the same data retention policies.

is it possible to configure it wiith different node names

Different node names sounds as a solution to what you're trying to accomplish. Data from each node name will be managed independently.

how can we do it
please explain it with examples

create multiple opt/sys files with different node names and run multiple schedulers for those names.
but really - this is not the way TSM should work. normally it does restore to any point of time expired data omitted.
so you just set policy to keep data as long as you need (like half-year and 30 copies) and get them back with comfort.

can u please give the examples

Examples of what? IBM site full of scenarious for eager to learn.
post your .opt file and I will explain change to be made.

Basically, you need to have multiple schedulers running with different node names, each node is assigned to a different management class on the server.

TSM supports point-in-time recovery, not tape rotation schemes.
Do you have problems with that?

This is my dsm.sys

SErvername  TSMSERVER
   COMMMethod         TCPip
   TCPPort            1500
   TCPServeraddress   TSMSERVER.abl.com.pk
PASSWORDAccess generate
passworddir /etc/security/tsm

**************************** Weekly backup of MQ Server *****************

SErvername  TSM_weekly
   COMMMethod         TCPip
   TCPPort            1500
   TCPServeraddress   TSMSERVER.abl.com.pk
PASSWORDAccess generate
passworddir /etc/security/tsm
INCLUDE /.../* weekly_mq_mgt_class

****************************  Monthly Backup of MQ Server *****************

SErvername  TSM_monthly
   COMMMethod         TCPip
   TCPPort            1500
   TCPServeraddress   TSMSERVER.abl.com.pk
PASSWORDAccess generate
passworddir /etc/security/tsm
INCLUDE /.../* monthly_mq_mgt_class

TSM normally does incremental backups, so backing up every day creates very small load on storage.
You have to create 2 more .opt files and select them for 2 extra schedulers - dsmc -c monthly.opt sched

But read TSM admins guide - the way you try is the inefficient one TSM tries to avoid.
4 months every day will be 130 versions for 130 days - piece of cake since 99% of files never change.

I've requested that this question be deleted for the following reason:

No comment has been added to this question in more than 21 days, so it is now classified as abandoned.

I have recommended this question be closed as follows:

Not enough information to confirm an answer.

If you feel this question should be closed differently, post an objection and a moderator will read all objections and then close it as they feel fit. If no one objects, this question will be closed automatically the way described above.

Experts-Exchange Auto Deleter

#25032277 explains everything.
TSM is automated backup management software that does everything behind the scenes.