Extrem unterscheidliche Sicherungsdauer bei der Systemsicherung

[hel400]

Hallo Bussibaer,

ein paar Gedanken meinerseits dazu:

Zunächst die Frage an Dich, ob diese Zeiten auch 100% richtig sind?
Warum ich so Frage: Du beschreibst, dass Ihr die Zeiten zwischen den einzelnen Screens notiert, da "wir nicht vor der Kiste sitzen". Wie ist das gemeint?
Evtl. mal den Parameter "Eingabeaufforderung für Befehle" auf "N" setzen und die genauen Zeiten dann mit DSPLOG nachsehen.
Oder das Ganze überhaupt in einen Batchjob packen.

Evtl. interessant wären auch die Zeiten für jede einzelne Bibliothek (im DSPLOG nachsehen). Ist die Zeitdifferenz auf alle Bibliotheken aufgeteilt oder gibt's da evtl. eine Lib, die besonders stark schwankt?

Wie sieht's da weiters mit Spoolfiles aus?
Hatte letzte Woche einen Fall, da ging die *NONSYS-zeit von 5 auf 2(!) Stunden zurück, nur wegen Tonnen von (unnötiger) Spoolfiles.

Weiters ist auffällig, dass auch im IFS (SAV) sehr große Differenzen sind, fast noch mehr als beim SAVLIB!
Kann es sein, dass hier die Anzahl und/oder Größen der Objekte stark schwanken?

[Fuerchau]

Da es sich ja noch immer im Streaming-Bänder handelt kann es auch ein Qualitätsproblem sein.
Beim Schreiben werden die Daten direkt mit dem dahinterliegenden Lesekopf gelesen und geprüft.
Bei Fehler wird der Datenblock wiederholt. Erst wenn eine gewisse Wiederholrate überschritten ist, wird der Vorgang abgebrochen.
Bei schlechter Qualität kann sich somit der Schreibvorgang einfach verlängern.

Da ihr die Bänder wohl zyklisch verwendet, prüft doch einfach ob die Zeiten von bestimmten Bändern abhängen.
Wie viel nun gesichert wurde kann man notfalls per DSPTAP rausfinden. Allerdings nur, wenn auch Folgebänder benötigt wurden. Man kann dann an Hand der belegten Kapazität feststellen wie hoch der prozentuale Fehleranteil dann ist (wenn z.B. nur die Hälfte drauf ging).
Diese Bänder sind dann ggf. gegen neuere auszutauschen.

[KingofKning]

Dann würde ich doch lieber im SST nachsehen ob die Bänder Fehler haben.

GG

[bussibaer]

Also im SST gab es keine Fehler (gleich geluschert). Aber das was Furchau sagt könnte vielleicht eine Lösung sein. Wir werden mal neue Bänder nehmen und das beobachten. Leider, oder zum Glück, wird nur ein Band benötigt.

Andrea: Das ist ein eingebautes tape, was wir als tape auch benutzen (TAP01).

hel400: Der Datenbestand schwankt, das ist klar, aber nicht so doll. Spools werden auf der Kiste nicht so viele erzeugt.

[Fuerchau]

Schreibwiederholungen werden nicht als Fehler gemeldet, da sie keine sind.
Dies ist beim Streamen ein ganz normaler Vorgang.
Wie das System das derzeit verwendet weiß ich nicht, aber es kam früher auch schon mal vor, dass ein 2. Band angefordert wurde obwohl alles auf 1 Band passen sollt, es gab also keine Wiederholungsbeschränkung.
Auf dem 1. Band konnte mal gerade 10% gesichert werden, so kaputt war das.
Was da bei der Wiederherstellung passiert wäre...

[hel400]

Wenn's um Bandfehler geht, hilft das oft weiter:

PRTERRLOG TYPE(*VOLSTAT) VOLTYPE(nnnn)

(mit "DSPDEVD TAPxx" die Type nachsehen, diesen Wert dann bei VOLTYPE eintragen).

Wenn jedes Band einen eigenen, eindeutigen Namen hat, sieht man's noch besser.

[bussibaer]

Danke, werde ich mal schauen, was ich da vielleicht noch finde.