FYI.

I have seen this problem on numerous occasions and with various client versions 
(Version 7, Release 1, Level 2.2 -> Version 8, Release 1, Level 2.0).
Our analysis is that it is indeed related to replication (we have two servers 
that cross-replicate to each other).
And to the fact that we often perform multiple backup sessions in parallel (SQL 
agent jobs that kick off dsmc.exe per database; we don't use TDP).

It seems that each session wants to write replication failover values to the 
options file.
And when multiple sessions try to do that in parallel, they collide with each 
other and end up completely wrecking the options file.

Workaround we have implemented: allow TSM to write failover values to the 
options file just once and then mark it readonly.
Subsequent sessions can't write to it anymore and hence can't destroy the 
options file.
Only drawback: each TSM session now causes the following alert to be written to 
dsmerror.log:

ANS4058I A write failure occurred while attempting to save node replication 
failover values to the options file.

We know what causes these alerts and choose to ignore them.
The backups themselves are not affected.

Rgds,

Frederik de Kezel | Industrial Windows Server Infrastructure
ArcelorMittal Gent

Industrial Automation & Modelling (IAM)
John Kennedylaan 51 | 9042 Gent | Belgium
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Zoltan Forray
Sent: donderdag 25 januari 2018 16:05
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] dsm.opt file being corrupted/blanked

**This Message originated from a Non-ArcelorMittal source**


Folks,

Wondering if anyone has seen this issue. The first time I saw it a few months 
back, I ignored it as a one-time issue.  But it just happened again so I am 
digging deeper.

This time (don't recall what the OS/client version was for the first
incident) it is a Windows 2008 R2 server with BA 7.1.0.0 (yes I know - 
0-releases are always problematic).

OS tech noticed the backups failing and went to investigate.  Trying to start 
the CLI - it hung.  Checked the dsm.opt file and found it blank/empty? It has 
been backing up for a long, long time with no reason to make any changes to the 
dsm.opt file.

AFAIK, the only thing that should be mucking with the dsm.opt file, aside from 
manually editing it, is replication.  So, is this replication related or a 
client bug?  Did some quick Googling without any luck on a known problem/fix.

--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor 
Administrator VMware Administrator Virginia Commonwealth University UCC/Office 
of Technology Services www.ucc.vcu.edu zforray AT vcu DOT edu - 804-828-4807 
Don't be a phishing victim - VCU and other reputable organizations will never 
use email to request that you reply with your password, social security number 
or confidential personal information. For more details visit 
http://phishing.vcu.edu/