Spectrum Protect Maintenance Mode

Print pagePDF pageEmail page

In Spectrum Protect v7.1.3 an additional method to place the server in maintenance mode was introduced. In the documentation maintenance mode is described as “….the preferred method for starting the server before you begin maintenance or reconfiguration tasks”. Actions like verifying a server upgrade or a restored server database comes to mind. During maintenance mode, operations that might disrupt maintenance or reconfiguration tasks are automatically disabled. Basically all tasks that are related to the adjustment and movement of data. These are:

  • Administrative schedules
  • Client schedules
  • Reclamation
  • Expiration
  • Migration
  • Client sessions are actively refused

During maintenance mode, the manual start of reclamation, expiration and migration is allowed.

The DSMSERV utility is now extended and placing a server in maintenance mode is now as simple as issuing: DSMSERV MAINTENANCE


Check for the output of ANR3415I:


This is the corresponding help text:


A piece of history for the old timers
In the past maintenance mode was called starting the server in “Stand-alone” (sometimes “Single-user”) mode. But that list also included disabling all administrative sessions. The above list can be translated to:

DescriptionOption or commandRemark
Disable administrative and client schedulesDISABLESCheds YesTranslates to: ANR2718W Schedule manager disabled
Reclamation and migrationNOMIGRRECL
ExpirationEXPINterval 0
Administrative and client sessions are actively refusedDISAble SESSions CLIent

The only noticeable difference is that in the new, out of the box, maintenance mode it is not purely stand-alone as other administrators then yourself are allowed to connect to the Spectrum Protect server. But that can be easily fixed with the “disable sessions all” command.

To place a server in stand-alone mode: halt the server, place NOMIGRRECL, DISABLESCHEDS YES and EXPINTERVAL in dsmserv.opt, start the server and type “disable sessions all” as soon as it is available.

The return to normal mode: halt the server, remove the options from dsmserv.opt, start the server and type “enable sessions all”.

This was the procedure for many years, but now there is the convenient DSMSERV MAINTENANCE option. Explore it and update all your DR procedures :-)

For an IBM Training demo of this, check this YouTube video:

—- Tommy Hueber

Restore TSM client data across nodes

Print pagePDF pageEmail page

This article describes several methods to restore Spectrum Protect (TSM) client data between nodes (set access, fromnode, virtualnodename, asnodename). This can be convenient if machine A crashes and you’ll need to restore machine A’s data on machine B. That’s just one example and there are different use cases for this. As you found this article, you’ll have a good reason for it.

The information provided in this article is not new – it is actually very old. VIRTUALNODENAME is used for restoring or retrieving (some or all) files to another workstation. FROMNODE is used for restoring or retrieving files from another client node and access needs to be granted. You can be very specific in the authorization rules. ASNODENAME allows an agent node to backup/restore and archieve/retrieve data on behalf of a target node. There is some overlap between the provided methods, so you have to pick the best one in your scenario.

Let’s assume these 2 nodes: HANNIBAL and FACE. In all methods, HANNIBAL backups a testfile and FACE needs a way to restore that file on its own system. Replace their names with the names of your machines.

Continue reading

Pointing out the obvious: No-query restore

Print pagePDF pageEmail page

The no-query restore (for the remainder of this article NQR) has been around forever. Let’s not get into details since which version and the changes made per release (if any) to client or server-side, but it is in there since ADSM v3+.

What I noticed over the years is that the majority of people (customers and business partners) are just referring to NQR as “a faster restore”. When asked for details the majority of them know about the multi-sessions capabilities, but that’s about it. In this article I’ll try to explain the differences between a classic restore and a NQR restore, as I was unable to find a more than basic explanation of this subject. If this sounds too basic to you, which I can imagine, skip this article.

First, let’s talk about the “Standard query restore”, aka “Classic restore”. For the remainder of this article called SQR.


Continue reading

Node replication and access=destroyed

Print pagePDF pageEmail page

During normal operations, node replication will flow from source server to target server. If an error occurs that might be from target server to source server. For example, with TSM v7.1.1’ “recover damaged files from a replication server” feature, when a file on the source is marked as damaged it will be replicated back from the target. That’s all clear. But what happens when a volume on the target server is set to destroyed? The short answer is….nothing will happen. Destroyed volumes are ignored by the node replication processes. Or so it seems.
Continue reading