Lokale Beschreibung für TUSTEP auf den Anlagen des ZDV: Batch

5. Ausf^uhren von TUSTEP-Kommandofolgen im Batch

5.1 Batchkontrolle auf dem Text-Server und anderen Workstations

5.2 Batchkontrolle auf dem Compute-Server

Auf dem Text-Server und Compute-Server (aber nicht im AFS-Pool!)
ist es möglich, Kommandofolgen im Batch ausführen zu lassen. Der
Batchlauf wird mit einem Kommando vom Dialog aus gestartet,  die
Abarbeitung  erfolgt  dann unabhängig von der Dialogsitzung. Das
ist z. B. sinnvoll, damit bei langen Kommandofolgen das Terminal
nicht blockiert ist, um es sofort für andere Arbeiten im  Dialog
freizuhaben  oder  auch  die Dialogsitzung beenden zu können und
nicht auf die Abarbeitung der Kommandofolge warten zu müssen.
   Mit dem Standard-Makro *TUE werden  TUSTEP-Kommandofolgen  im
Batch  ausgeführt. Das Makro entspricht dem Kommando TUE mit al-
len Spezifikationen. Es ergänzt  automatisch  die  für  das  Be-
triebssystem notwendigen Steueranweisungen.
    
Gib Kommando >
 
#*tue,dateiname,segmentname   <CR>
Die Kommandofolge, die in der Datei  
dateiname
  in  dem  Segment

segmentname
 steht, wird im Batch ausgeführt. Die Angabe von wei-
teren Spezifikationen ist wie beim Kommando TUE möglich.
   Für die Ausführung der Kommandofolge im Batch wird  eine  ei-
gene  TUSTEP-Sitzung  initialisiert  (auch TUSTEP.INI wird dabei
abgearbeitet; ggf.  kann  mit  Mitteln  der  Makroprogrammierung
(#makro) eine Verzweigung innerhalb von TUSTEP.INI für Batch und
Dialog  vorgenommen werden). Alle Dateien, die für die Kommando-
folge des Batchlaufs benötigt werden, müssen innerhalb der  Kom-
mandofolge angemeldet bzw. eingerichtet werden. Wird die gesamte
Kommandofolge  ohne  Fehler durchlaufen, so wird am Ende die TU-
STEP-Sitzung dieses Batchlaufes mit NORMIERE beendet, d. h. alle
Scratch-Dateien werden gelöscht. Die Ergebnisse der Kommandofol-
ge, mit denen man weiterarbeiten will, müssen daher in permanen-
ten Dateien abgelegt werden, denn nur sie sind nach  dem  Batch-
lauf zugänglich.
   Ein Protokoll des Batchlaufes  wird  vom  Betriebssystem  ge-
führt. Das Protokoll gibt darüber Auskunft, ob die Kommandofolge
des  Batchlaufs  fehlerfrei  zu Ende gekommen ist. Allein an den
Ergebnisdateien sieht man dies nicht ohne weiteres.  Wie  dieses
Protokoll zugänglich ist, ist abhängig vom Rechner.

Wird die Kommandofolge durch einen Fehler  unterbrochen  (Fehler
in  einem  TUSTEP-Kommando,  Abbruch  durch das System), so wird
(außer bei ausgeschaltetem FEHLERHALT)  der  Batchlauf  beendet,
die zu dem Batchlauf gehörende TUSTEP-Sitzung bleibt aber erhal-
ten. Diese TUSTEP-Sitzung kann man dann, wie jede andere TUSTEP-
Sitzung,  im Dialog fortsetzen (Informieren über die vorhandenen
Sitzungen mit 
tustep  @ 
; Aufrufen der Sitzung mit  
tustep  nn
die  Batchsitzung  erkennt  man an der zusätzlichen Angabe BATCH
beim Auflisten der Sitzungen). Man kann mit  der  TUSTEP-Sitzung
weiterarbeiten,  sich Zwischenergebnisse sichern und die TUSTEP-
Sitzung beenden, damit alle dazugehörenden Scratch-Dateien  wie-
der gelöscht werden.

Wird versucht eine laufende Batch-Sitzung im  Dialog  fortzuset-
zen, kommt es zu undefinierten Fehlern. 

5.1 Batchkontrolle auf dem Text-Server und anderen Workstations

Das Verfahren auf dem Text-Server (AIX-Workstation RS/6000; Name
im Netz 
textserv
) zur Batchkontrolle ist gleich wie auf  anderen
UNIX-Workstations.

Protokoll eines Batchlaufs

Der Batchlauf wird vom System protokolliert. Das Protokoll  wird
als 
mail
 zugeschickt und kann mit den üblichen Mitteln der 
mail
Verwaltung angeschaut werden.
Aufrufen von 
mail
    
% 
 
mail   <CR>
Die 
mail-utility
 meldet sich mit ihrem 
prompt
 (
&
). Es  sind  nun
u. a. die folgende Befehle möglich:
Anschauen der 
mail
 mit der Nummer 
nn
    
& 
 
nn   <CR>
Abspeichern der 
mail
 mit der Nummer 
nn
  in  eine  SDF-Datei,  um
diese ggf. mit TUSTEP- Mitteln anschauen zu können:
    
& 
 
save nn dateiname   <CR>
Löschen der 
mail
 mit der Nummer 
nn
    
& 
 
del nn   <CR>
Verlassen der 
mail-utility
    
& 
 
quit   <CR>
(Detaillierte Informationen zum Umgang mit 
mail
 stehen  auf  dem

x400link
  in  der  Datei  
/usr/local/info/mail.readme
 zur Verfü-
gung.)

Status des Batchlaufs

Informationen über den Status des Batchlaufs bekommt man mit dem
Befehl:
    
% 
 
ps ux   <CR>
Ist der Batchlauf hier nicht mehr zu finden, so ist er  beendet,
und das Protokoll steht als 
mail
 zur Verfügung.
   Aufgelistet werden alle laufenden Prozesse des Users mit fol-
genden Informationen:
PID      Prozeß-ID, mit der der Prozeß im System eindeutig iden-
         tifiziert wird.
STAT     Status des Prozesses (
R
 = Running;  Informationen  über
         die weiteren Abkürzungen mit 
man ps
STIME    Startzeit des Prozesses.
TIME     Verbrauchte Zeit des Prozesses. Gibt man den  
ps
-Befehl
         mehrmals,  kann  man an der Änderung dieser Zahl erken-
         nen, daß der Prozeß arbeitet.
COMMAND  Kommando, das der Prozeß ausführt.  Den  Batchlauf  er-
         kennt  man  an  dem Kommando 
/soft/tustep/xx
, das durch
         ihn ausgeführt wird.

Abbrechen eines Batchlaufs

Über die Prozeß-ID 
PID
, die man durch 
ps ux
 (s. o.) erhält, kann
der Batchlauf abgebrochen werden:
    
% 
 
kill -9 PID   <CR>
 

5.2 Batchkontrolle auf dem Compute-Server

Der Compute-Server hat gegenüber den  Workstations  ein  anderes
Verfahren der Batchkontrolle.

Warteschlangen für die Batchabarbeitung

Auf dem Compute-Server gibt es für Batchläufe fünf  Warteschlan-
gen  für  verschiedenen  Zeitbedarf,  die  mit unterschiedlicher
Priorität behandelt werden (siehe BI 92/11+12, S. 8). Batchläufe
mit großem Bedarf an CPU-Zeit  werden  mit  niedriger  Priorität
behandelt,  d. h.  sie haben in Konkurrenz mit anderen laufenden
Programmen nur ein geringes Anrecht auf CPU-Leistung; Batchläufe
mit wenig Bedarf an CPU-Zeit bekommen eine hohe  Priorität.  Er-
reicht  ein  Batchlauf das Zeitlimit seiner Schlange, so wird er
vom System abgebrochen. Die Schlangen sind:
Name        alternative Namen                          Zeitlimit
short       s, SHORT, S, short_queue                      15 min
normall     n                                             60 min
long        l, LONG, L, long_queue                      4 h
verylong    v, VERYLONG, very, V, verylong_queue       24 h
extralong   e, extra                                   72 h
Bringt man eine Kommandofolge mit *TUE zur Ausführung im  Batch,
so  kann  zu  der Spezifikation ZUSATZ eine zuvor definierte Sy-
stemvariable angegeben werden,  die  besagt,  in  welche  Warte-
schlange  der Batchlauf kommen soll. Wird zu ZUSATZ nichts ange-
geben, so kommt der Batchlaufe in die Schlange 
normal
   Die Definition der Systemvariablen sieht folgendermaßen aus:
    
Gib Kommando >
 
setenv VARIABLE "-q queuename"   <CR>
Beispiel:
Will man die Kommandofolge der  Datei  STAPEL  in  der  Schlange

short
,  die  man  mit der Variablen KURZ angeben will, ausführen
lassen, sind folgende zwei Befehle nötig:
    
% 
 
setenv KURZ "-q short"   <CR>
    
Gib Kommando >
 
#*tue, stapel, zusatz=kurz   <CR>
Hinweis:
Wer häufig Kommandofolgen im Batch ausführt, wird sich die  ent-
sprechenden  Systemvariablen in der Datei 
.cshrc
 definieren, da-
mit sie immer zur Verfügung stehen.
   Die Spezifikation ZUSATZ gibt es genauso auch bei den Magnet-
band-Makros *MBL, *MBA, *MBI, *MBE und *MBK.

Protokoll eines Batchlaufs

Der Batchlauf wird vom System protokolliert und in  einer  Datei
ausgegeben.  Die  Datei  taucht in der Dateiliste (Auflisten mit
UNIX-Befehl 
ls
; das TUSTEP-Kommando 
#li,da
 zeigt die Datei nicht
an, da ihr Name nicht den TUSTEP- Konventionen entspricht)  auf,
sobald  der Batchlauf abgearbeitet oder durch einen Fehler been-
det ist. Die Datei heißt:
         SCR.nnn.oxxxxx
(
nnn
 steht für die dreistellige Nummer  der  Dialogsitzung,  von
der  der  Batchlauf abgesetzt wurde; 
xxxxxx
 steht für eine fünf-
stellige laufende Nummer des Batchlaufs, die vom System vergeben
wird; z. B. SCR.001_o10785).
Die Protokoll-Datei läßt sich mit den  Mitteln  des  Betriebssy-
stems  anschauen  (z. B.  
more
) oder in eine Datei mit einem den
TUSTEP-Konventionen entsprechenden Namen umbenennen, um sie  mit
TUSTEP-Mitteln anschauen zu können (z. B. 
mv SCR.001_o10785 out-

put
   Tauchen während der Abarbeitung des  Batchlaufs  Systemfehler
auf, so werden sie in der Datei
         SCR.nnn.exxxxx
protokolliert.
   Die beiden Protokoll-Dateien sind permanente Dateien, die man
- um Platz zu sparen - wieder löschen sollte (z. B. 
rm SCR.*.*

Status des Batchlaufs

Mit dem Befehl 
qstat
 kann man die Warteschlangen abfragen, um zu
sehen, ob der eigene  Batchlauf  wartet  (QUEUE)  oder  arbeitet
(RUNNING).  Ist  der Batchlauf hier nicht mehr zu finden, so ist
er beendet und die Datei mit dem Protokoll steht in der Dateili-
ste.
Abfragen aller Warteschlangen:
    
% 
 
qstat   <CR>
Abfragen einer bestimmten Warteschlange (z. B. 
qstat short
    
% 
 
qstat queuename   <CR>
Man erhält dabei für den eigenen Batchlauf die  
request-id
,  mit
der er im System identifiziert werden kann.
Abfragen einer bestimmten Warteschlange nach  ausführlicher  In-
formation für den eigenen Batchlauf:
    
% 
 
qstat -l queuename   <CR>
Abfragen einer bestimmten Warteschlange nach kurzer  Information
für alle Batchläufe:
    
% 
 
qstat -a queuename   <CR>

Löschen eines Batchlaufs aus der Schlange

Über die 
request-id
, die man durch 
qstat
 (s. o.)  bekommt,  kann
der Batchlauf wieder aus der Schlange entfernt werden oder seine
Abarbeitung abgebrochen werden:
    
% 
 
qdel -9 request-id   <CR>