• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.


    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

Node Replication stuck or even not running


We have 10 TSM Severs with this configuration:

TSM Version 7.1.7

TSM SERVER A/B/C --->> node replication to TSM SERVER D
--->> node replication to TSM SERVER H
---------->> node replication to TSM SERVER J

All of this replication jobs are getting failed since many weeks. During the night we are replicating around 2MB to 40GB. Between the servers we have up to 100Mbit and we calculated that with our bandwidth it should be easy possible to replicate the nodes.

We still opened a TSM PMR and IBM told us, that the error is in our network. We checked the whole company network with our network architects and there is no error during the replication.

Our question is:
Does anybody know something else what we could do, to get the replication running. Would be very great to hear from you.



ADSM.ORG Moderator
We checked the whole company network with our network architects and there is no error during the replication.
Keep in mind that the network actually starts with the TCP/IP stack of the OS of the source and ends with the TCP/IP stack of the target OS. Most network admins only start with the physical network where the network cable connects to the NIC. Essentially only focusing on 4 lower-levels of the 7 OSI layers, leaving the 3 upper-level to system administrators. Which is why many network admins report there are no network problems, when in reality it's that there is no errors on the portion they support.

So what is often overlook is:
- NIC settings
- NIC driver and firmware
- NIC errors
Hy marclant,

Thanks for your answer. Yes we know that the network admins only check the "physical network". So we also checked the NIC´s (Hardware and Windows settings), tried different drivers, also flashed to the newest firmware, checked Windows Eventlogs. But there is nothing to find.

Therefore we think we have a "TSM" problem and not a network problem.


ADSM.ORG Moderator
Networking problems don't always manifest themselves in the form of errors. A sniffer trace with Wireshark or similar between the source and target may be needed.

You also have not posted the errors you get when it fails, so only general recommendations can be made.

We are already on the latest "7" Version --> 7.1.7

We will also check the Wireshark sniffing logs once more. But is there any other idea what we could do? Thank you very much.

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 18 18.8%
  • Keep using TSM for Spectrum Protect.

    Votes: 58 60.4%
  • Let's be formal and just say Spectrum Protect

    Votes: 12 12.5%
  • Other (please comement)

    Votes: 8 8.3%

Forum statistics

Latest member