Geschäftskontext
Nach einem Hardwarefehler muss ein kritischer Worker-Knoten dringend ersetzt werden. Der Operations-Manager muss den Beitrittsprozess des neuen Knotens genau überwachen. Das Skript muss den Status wiederholt abfragen und den Statuscode bei jedem Aufruf überprüfen, um sofort auf Anomalien (z.B. wenn der Knoten im 'pending'-Status hängen bleibt) reagieren zu können.
Datenaufbereitung
Keine Datenerstellung erforderlich.
Kopiert!
| 1 | /* Keine Datenerstellung erforderlich. */ |
Étapes de réalisation
1
Erster Abruf des Knotenstatus zu Beginn des Beitrittsprozesses.
Kopiert!
| 1 | PROC CAS; |
| 2 | SESSION.addNodeStatus RESULT=r_t1 STATUS=st_t1; |
| 3 | PRINT "Prüfung T1:"; |
| 4 | IF st_t1.statusCode == 0 THEN PRINT r_t1; |
| 5 | ELSE PRINT st_t1; |
| 6 | RUN; |
2
Zweiter Abruf nach einer simulierten Wartezeit, um den Fortschritt zu überprüfen.
Kopiert!
| 1 | /* Annahme: Zwischen T1 und T2 vergeht etwas Zeit */ |
| 2 | PROC CAS; |
| 3 | SESSION.addNodeStatus RESULT=r_t2 STATUS=st_t2; |
| 4 | PRINT "Prüfung T2:"; |
| 5 | IF st_t2.statusCode == 0 THEN PRINT r_t2; |
| 6 | ELSE PRINT st_t2; |
| 7 | RUN; |
Erwartetes Ergebnis
Das Skript führt die Aktion mehrmals erfolgreich aus. Bei jedem Aufruf wird der Statuscode überprüft, um die Zuverlässigkeit des Befehls selbst sicherzustellen. Die ausgegebene Tabelle 'r_t1' könnte den Knoten im Status 'Beitritt' zeigen, während 'r_t2' ihn im Status 'Aktiv' zeigt. Das Szenario validiert, dass die Aktion für kontinuierliches Monitoring in einem automatisierten Skript robust genug ist und zuverlässige Statuscodes liefert.