Sicherung QFILEUPR

[Robi]

Benutzerprofile hat sich nix geändert.
Aber wie ich eben erfahren habe gibt es einen neuen Job, der IFS Dateien erzeugt, kann das die Ursache sein?

[Fuerchau]

Neue Objekte im IFS verändern nicht das USRPRF.
http://www-01.ibm.com/support/docvie...d=nas8N1017833
Es gibt allerdings Programme wie STRSQL, die in angehängten USRSPC-Objekten diverse Informationen speichern. Dies kann man per DSPOBJD *ALL *USRPRF mal prüfen, wer denn da so viel angehängt hat.

[Robi]

Danke Euch!
mit dem DSPOBJD *ALL *USRPRF habe ich ein Usrprf gefunden,
dessen Größe das 100 Fache des 'normalen' ist.
ein WRKOBJOWN zeigt, das der user der Owner der vielen IFS Dateien ist.

WAS macht den die Sicherung so langsam / das Usrprf so groß, wenn das Usrprf
durch die IFS Dokumente nicht verändert wird?

[Fuerchau]

Ich habe da mal einen DMPSYSOBJ gemacht. Es scheint so zu sein, dass eine Liste der eigenen Objekte nebst den dazugehörigen Berechtigungen am USRPRF angehängt ist, also je mehr Objekte, desto länger die Liste.
Wobei die Objekttypen hier leider in Hex dargestellt werden und es mal wieder nur per API ggf. möglich ist, die Objektart "sprechend" umzuwandeln.
Nicht umsonst gibts ja neben dem RSTUSRPRF zusätzlich den RSTAUT. Irgendwo müssen diese Informationen ja liegen.

[Robi]

Ok, so komm ich aber nicht weiter,
die IFS Objekte müssen ja schließlich sein, die sind ja nicht zum Spaß vorhanden.
Das muß ich also akzeptieren.

Weitere 'Bremse' ist das sichern eines QAOSDI* Journal recievers
Text: "JOURNAL RECEIVER FOR DIA FILES"
Das Log weist darauf hin, das er im aktiven zustand nicht vollständig gesichert wurde.
Schnell: 73 minuten
Langsam: 216 minuten

Wäre es möglich die Journalisierung von ???was-auch-immer??? vor der Sicherung zu beenden!
Wenn ja, wie?

Danke

[Fuerchau]

Journalisierung vor der Sicherung beenden ist schädlich, da dies ausßerdem je Objekt einzeln durchgeführt werden müsste.
Das Problem ist eher, dass die Programme noch aktiv sind und deshalb Transaktionen offen sind. Somit wird auf den/die Journalempfänger jeweils 2 Minuten (Default) gewartet um dann ohne Sicherung dieses Objektes weiter zu machen.

Sow wie es aussieht, ist dieses Journal für die "Document Library" zuständig. Dafür musst du den Dienst QZLSFILE (Hostservice) beenden um die Objekte freizugeben.

Ich denke, da werden dir noch einige Objekte begegnen, wenn du im laufenden Betrieb sicherst.

[Robi]

Danke

Tja,
ich dachte immer der save21 geht nur im eingeschrängten Zustand ... = alle ist zu/aus/beendet!

Da die Kiste nicht mehr in unserem zuständigkeitsbereich liegt weis ich eigendlich gar nicht genau, was gemacht wird.
Ich muß nur suchen, wo der imennse Zeit unterschied herkommt.

[Fuerchau]

Sperren können da schon lässtig sein.
Wie gesagt, ein ENDSBS kann da schon mal länger dauern und wenn dann die Sicherung bereits startet gibts halt manchmal Zeitprobleme.
Dann ist da auch die Frage, ob ein ENDSBS *ALL gemacht wird und somit auch QSERVER und QUSRWRK beendet werden die schließlich für die TCP-/Hostservices zuständig sind.

Was die Zuständigkeit angeht so frag doch mal nach, wieso die Dauer interessant ist?
Schließlich könnt ihr eure Platten doch auch zu 95% auslasten und dann dauert die Sicherung wohl noch länger.
Wenn ich mir ein Auto miete wird ja auch nicht gefragt, wie viele Leute ich mitnehme.

[Robi]

Endsbs läuft anscheinend nicht. (steht nicht im Joblog)
Diverse Jobs und Diesnste werden aber beendet
u.a. QZLSFILE jobs

das würde ich gerne verhindern / beschleunigen

00   01.08.16  23:29:29,219722  QIZARTV      QSYS        0084     QSRSLCP2    QSYS 
  Nachricht . . . :   Systeminformationen wurden abgerufen.                        
00   02.08.16  03:05:59,700262  QJOSAVRC     QSYS        023E     QSRSVPST    QSYS 
  Nachricht . . . :   Empfänger QAOSDI9624 in QUSRSYS gesichert, während er        
    zugeordnet war.                                                                
  Ursache  . . . . :  Der Journalempfänger QAOSDI9624 in Bibliothek QUSRSYS        
    wurde gesichert, während er dem Journal zugeordnet war. Diese                  
    Sicherungskopie des Journalempfängers QAOSDI9624 ist nicht vollständig, da     
    die Journaleinträge nach der Sicherung weiterhin in den Empfänger gestellt

Über 3, 5 Stunden für einen Reciever sichern?
da muß doch die Ursache mit dem 'wärend er dem Journal zugeordnet war' zusammenhängen oder?

[Fuerchau]

Bist du sicher, dass zwischen den beiden Einträgen nichts anderes steht?
Wenn kein ENDSBS gemacht wird, kann es sein, dass eben viele Objekte noch in Benutzung sind.
Die Sicherung macht nun mal auf jedem Objekt einen ALCOBJ und wartet ggf. mit der Standardwartezeit je Objekt einzeln darauf, dass die Sperre erhalten wird. Erst wenn alle benötigten Sperren gesetzt werden können wird überhaupt mit der Sicherung angefangen.
Ich denke eher da läuft irgendwas schief bei euch.

Wie groß ist denn der Empfänger QAOSDI9624 überhaupt?
Vielleicht hilft ja hier mal ein CHGJRN und manuelles killen des alten Empfängers.

[Robi]

Bist du sicher, dass zwischen den beiden Einträgen nichts anderes steht?

JA!
unmittelbar davor ist
- Sicherung *ibm fertig
- Sicherung *Allusr der art *Full wird gestartet
-Sicherung der Bibliothek *ALLUSR auf Einheiten TAPMLB01 starten
- Datenträger MS0701 auf Einheit TAPMLB01 hat Dichte *ULTRIUM
- Netzwerkattribute abgerufen.

dann kommt das dokumentierte:
- Systemwerte abgerufen
- Empfänger QAOSDI9624 in QUSRSYS gesichert, während er zugeordnet war

Wenn kein ENDSBS gemacht wird, kann es sein, dass eben viele Objekte noch in Benutzung sind.

In Benutzung kann (eigendlich) nicht sein!
Außer durch Jobs die vom Dienstleister selber initiiert werden (wie dieser Sicherungsablauf). Da werden jobs nach QBATch submittet, das SBS läuft auf jeden Fall noch. QPGMR, QCTL und QINTER werden im Log nicht erwähnt, also müßten die aktiv sein. Aber NIX!!! arbeitet hier um diese Zeit.

Ich denke eher da läuft irgendwas schief bei euch.

Ganz gewaltig!
Aber ich komm nicht drauf, habe auch keine Sourcen wie das in diesem BRMS hinterlegt ist.

                                                             Bibliothek 1 v
 Objekt . . . . . . . :   QAOSDI9624      Attribut . . . . . . :           
   Bibliothek . . . . :     QUSRSYS       Eigner . . . . . . . :   QDOC    
 Bibl.-ASP-Einheit  . :   *SYSBAS         Bibl.-ASP-Gruppe . . :   *SYSBAS 
 Art  . . . . . . . . :   *JRNRCV         Primärgruppe . . . . :   *NONE   
                                                                           
 Speicherinformation:                                                      
   Größe  . . . . . . . . . . . . . . . :   2682880                        
   Offline-Größe  . . . . . . . . . . . :   2682880                        
   Zugeordnete Speicherbereichsgröße  . :   36864                          
   Optim. Speicherbereichsausrichtung . :   J                              
   Freigegeben  . . . . . . . . . . . . :   N                              
   Verdichtet . . . . . . . . . . . . . :   Nicht auswählbar               
   Objekt-ASP-Einheit . . . . . . . . . :   1                              
     Objektüberlauf . . . . . . . . . . :   N                              
   Objekt-ASP-Einheit . . . . . . . . . :   *SYSBAS                        
   Objekt-ASP-Gruppe  . . . . . . . . . :   *SYSBAS

Was sind diese DIA Files?
JOURNAL RECEIVER FOR DIA FILES