====== Konfiguration Scheduler ======
===== Standard-Konfiguration  für alle Betriebssysteme =====
Für die Nutzung des Scheduler-Diensten ist in der Standard-Konfiguration keine explizite Anpassung notwendig.

Falls der Scheduler über den //dsm Client Acceptor Daemon (dsmcad)// gestartet werden soll, muss dies in der ''dsm.sys'' / ''dsm.opt'' durch die folgende Option eingestellt werden:
  MANAGEDService SCHEDULE
<file></file>
<WRAP center round tip 90%>
Der //dsmcad// wurde für Windows-Rechner empfohlen, weil er weniger Speicherressourcen benötigt, während das Backup //nicht// läuft. In Anbetracht der aktuellen RAM-Ausstattung von Servern und auch Endgeräten, fällt der Mehrverbrauch durch einen dauerhaft laufenden Scheduler nicht wirklich ins Gewicht. Es ist damit einfacher, direkt den Scheduler als Windows-Dienst zu konfigurieren.
Unter Linux hingegen lässt sich der //dsmcad// direkt über //init.d// bzw. den //systemd// starten und während für den Schedulers entsprechene Routinen erstellt werden müssen. Für Linux/BSD wird daher der //dsmcad// empfohlen.
</WRAP>

Darüber hinaus sollten Sie überlegen, die beiden folgenden Optionen zu nutzen:
  * ''SCHEDLOGMAX <MB>''
  * ''SCHEDLOGRetention <days>[D,S]''
Über **einen** der beiden Parameter wird die maximale Größe des Scheduler-Logs festgelegt, entweder über die Dateigröße in MegaByte (//ERRORLOGMAX <MB>//) oder die Aufbewahrungszeit in Tagen (//SCHEDLOGRentenion <days>[D,S]//), die zusätzlichen bei Angaben bei der Option //ERRORLOGRentenion// legen den Umgang mit älteren Logeinträgen fest: 
    * ''D'' -- Löschen der Daten, (Voreinstellung)
    * ''S'' -- Sichern der Daten in einer weiteren Datei //dsmschedlog.pru//.
  
===== Konfiguration bei mehreren Knoten auf einer Maschine =====
==== Windows ====
Die Konfiguration mehrerer Scheduler ist unter Windows ziemlich einfach:
  - Erstellen Sie für jeden Scheduler eine eigene ''dsm.opt''-Datei.
  - Weisen Sie bei der Konfiguration des Scheduler-Services die passenden ''dsm.opt''-Datei dem Service zu.

Fertig!
==== Linux ====


Die Steuerung erfolgt über die Optionsdatei, der Start der Scheduler durch den DSMcad:

Soll ein Rechner über mehrere Scheduler gesichert werden, so sind für diesen mehrere Knotennamen oder mehrere Server definiert. In beiden Fällen gibt es mehrere //SErvername <NAME>//-Einträge und Serverdefinitionen in der Konfigurtaionsdatei //dsm.sys//.
Meist gibt es auch mehrere Optionsdatein //dsm.opt// in unterschiedlichen Ordnern oder mit abweichenden Namen.

Die zu nutzenden Optionsdatei kann entweder im Aufruf der CLI (//dsmc -optfile=<NAME>//) oder GUI (//dsmj -optfile=<NAME>//) angegeben werden, alternativ kann die Umgebungsvariable //DSM_CONFIG// mit dem Namen der passenden Optionsdatei besetzt werden.

Dieser letztgenannte Weg kann genutzt werden, um mehrere Scheduler über den DSMcad auf einem Knoten laufen zu lassen.
=== Umsetzung -- Systemd ===
Services werden bei //systemd//-Linuxen über entsprechende //service//-Dateien beschrieben. Im Rahmen der Installation des SP-Clients wird eine ''dsmcad.service''-Datei erzeugt und im Konfigurations-Pfad des Clients (i.d.R. ''/opt/tivoli/tsm/client/ba/bin/'') abgelegt. Der 

== Vorbereiten ==
Ansatz für mehrere Client-Instanzen besteht nun darin, diese Datei als Vorlage zu nehmen, zu kopieren und anzupassen und anschließend in das systemd-Verzeichnis zu 
  * .. kopieren / verschieben:
<code>
cp /opt/tivoli/tsm/client/ba/bin/dsmcad.service /opt/tivoli/tsm/client/ba/bin/dsmcad.instance1.service
</code>
  * .. Editieren
<code>
ln -s /opt/tivoli/tsm/client/ba/bin/dsmcad.instance1.service /usr/lib/systemd/system/
</code>
<WRAP center round important 100%>
Nach jeder Änderung an einer Datei im ''/usr/lib/systemd/system''-Verzeichnis muss das Verzeichnis neu eingeladen werden (''systemctl daemon-reload''). 
</WRAP>

Die Anpassung der //.service//-Datei umfasst dabei:
  - Es ist eine Zeile hinzufügen, die auf das jeweilige //opt//-File verweist, z.B. <code>Environment="DSM_CONFIG=/opt/tivoli/tsm/client/ba/bin/instance1.opt</code>
  - Das Binary für die Option //ExecStart// ist auf die Kopie des //dsmcad// zu ändern, z.B. <code>ExecStart=/usr/bin/dsmcad.instance1</code> 
 
Außerdem muss das //dsmcad//-Binary kopiert werden, es bietet sich an den Knotennanmen anhängen:
<code>cp /opt/tivoli/tsm/client/ba/bin/dsmcad cp /opt/tivoli/tsm/client/ba/bin/dsmcad.instance1</code>
<WRAP center round important 100%>
  * Da //ExecStart// in das Verzeichnis ''/usr/bin'' zeigt, muss das Binary vom ''dsmcad.instance1'' auch dorthin kopiert / verlinkt werden:\\ ''ln -s /opt/tivoli/tsm/client/ba/bin/dsmcad.instance1 /usr/bin/''
  * Das Startskript funktioiniert offensichtlich nicht, wenn bei ''ExecStart'' direkt auf das Binary im Pfad \\ ''/opt/tivoli/tsm/client/ba/bin/'' verwiesen wird -- warum es dann aber ein Symlink tut? 8-o
</WRAP>
== Ausführen ==
  - Der Start erfolgt "ganz normal" über das //systemctl//-Kommando, z.B. <code> systemctl start dsmcad.instance1</code>
  - Ebenso die Etablierung als Dienst beim Systemstart, z.B.:<code> systemctl enable dsmcad.instance1</code>
=== Umsetzung -- Init-V--Ansatz ===
  * Der Start des //dsmcad// erfolgt über das Skript //rc.dsmcad//, dieses liegt in der Regel unter ///etc/init.d/dsmcad// als symbolischer Link zu ///opt/tivoli/tsm/client/ba/bin/rc.dsmcad//). Für mehrere Knoten auf einem Host, muss dieses kopieren und umbenannt werden, z.B. <code>cd /etc/init.d/ && cp rc.dsmcad rc.dsmcad.knoten_1</code>
  * Um die verschiedenen Prozesse unterscheiden zu können (z.B auch für das ''service <Name> [start|stop]''), sollte auch das benutzte Binary (//dsmcad//) kopiert werden, z.B. <code>cp /opt/tivoli/tsm/client/ba/bin/dsmcad /opt/tivoli/tsm/client/ba/bin/dsmcad.knoten_1</code>Es kann dann eindeutig identifiziert werden.
  * Im kopierten Skript (//rc.dsmcad.knoten_1//)<WRAP center round important 90%>
Achtung: Die Datei ist  per default auch für ''root'' nur lesbar!
</WRAP>
    *  eine Zeile ergänzen, die die Variable //DSM_CONFIG// auf die passenden Optionsdatei verweisen lässt, z.B.:<code>export DSM_CONFIG=/opt/tivoli/tsm/client/ba/bin/dsm-node1.opt</code>
    * Den Namen des Binaries im Skript (Zeile //DSMCAD_BIN=...//) anpassen, z.B.<code>DSMCAD_BIN=$DSMCAD_DIR/dsmcad.node1</code>
  * Das geänderte Skript kann nun wie das Original-Skript mittels der Parameter //start//, //stop// //restart// und //status// benutzt werden.
<WRAP center round tip 90%>
Liegt das neue Skript im Verzeichnis //etc/init.d// (bzw. liegt dort ein symbolischer Link zum geänderten Skript) kann auch der geänderte DSMcad über die üblichen Wege als Dienst gestartet werden.

z.B.
  * SuSE: <code>chkconfig dsmcad-Server_1 on</code> \\ bzw. zum Start in Runlevel 3 und 5:\\ <code>chkconfig dsmcad-Server_1 35 </code>
  * generisch:
  * <code>
cd /etc/init.d/
for i in $(ls rc.dsmcad*); 
do 
  ln -s /etc/init.d/$i /etc/init.d/rc3.d/K01$i
  ln -s /etc/init.d/$i /etc/init.d/rc3.d/S15$i
done
</code>
</WRAP>
==== OSX ====
sollte wie bei Linux funktionieren (nicht getestet).