View Full Version : QUSERSYS bei Systemwechsel
oopsy-dear
31-10-03, 07:35
Hi zusammen,
ich hab mal ne Frage. Wenn ich früher (V4) Maschinen umbaute/ austauschte. habe ich immer bei RSTLIB *ALLUSR den Paramweter ALWOBJDIF mit *all gesetzt. Dann kam QUSRSYS auf *Backlevel. Dann habe ich die QUSRSYS von der B2929 zurückgespielt und alles bello. Seit V5 funzt das nicht mehr, die QUSRSYS geht auf Error und wenn man Pech hat, muß man alles neu aufsetzen. Bei kleinen Installationen klimpere ich heute alles von Hand (TCP/IP;DIRE usw.) Bei großen Ssytemen ist das aufwendig. Ich habe schon mal überlegt, die Dateien, in denen die Infos über TCPIP,DIRE, SCHEDULE usw stehen aus der alten in die neue zu kopieren. Wie mach ihr das? Hat einen nen heißen TIP?
Vielen Dank im Vorraus
Hallo Oopsy-Dear,
das ist auch relativ einfach zu lösen ! Vor dem zurückspielen
der Original Qusrsys muss noch ein rclstg *full laufen.
Gruss TARASIK
oopsy-dear
31-10-03, 07:42
@tarasik,
vielen Dank für die schnelle Antwort, ich werd das mal probieren. Kennst Du vielleicht auch noch die Ursache dieses Phänomens und die Wirkung des RCLSTG??
OD
Hallo OD,
das passiert meistens den Kunden die auf dem Ursprungsrelease
nicht vor dem Releasewechsel diesen von IBM empfohlenen
rclstg *full ausführen.
Gruss TARASIK
Leider habe ich gerade mit der QUSRSYS enorme Schwierigkeiten bekommen.
Bei der Umstellung von V4R5 Maschine A auf V5R1 Maschine B wurde natürlich kein Release-Update durchgeführt, warum auch.
Dann, wie von euch beschrieben, die QUSRSYS erstellt.
Nun hatte ich aber ein Problem !!!!!
Es gibt da ein paar Dateien in der QUSRSYS, deren Format-ID sich NICHT geändert hat. Dadurch blieb der Stand aus V4R5 erhalten !
Leider (oder andere sagen endlich), hat die IBM ein paar neue Dienste bereitgestellt, die nun NICHT verfügbar waren !!!
Was war passiert ?
Beim Ersetzen erhalten die Ursprungsdateien neue Suffixe mit '0001', '0002', usw. Doch die IBM liefert nicht nur leere Dateien aus, so dass die neuen Dienste halt in den neuen Dateien steckten !!!
Vorschlag der IBM war dann: Tja, System putzen und komplett neu installieren (ja bin ich denn wahnsinnig).
Wir haben uns dann die Mühe gemacht, alle Dateien, die ersetzt wurden Stück für Stück zu vergleichen (übrigens incl. aller abhängigen LF's), die neueren Objekte ggf. wieder in Original umbenannt und die alten gelöscht bzw. bei Gleichheit der Formatebene die neuen Sätze per CPYF .... ERROR(*NOMAX) hinzugefügt.
Und siehe da: Die neuen Dienste standen zur Verfügung !
Mein Fazit daraus:
Sämtliche Generierungen können per CLP durchgeführt werden.
Alle *LIN/*CTL/*DEV-Objekte können (soweit benötigt) per RTVCFGSRC abgefragt werden.
Keine User-Objekte mehr in die QUSRSYS, da sie nun mal System-Objekte enthält und durch Release-Wechsel verändert wird.
Remote-Outq's (also die ohne *DEV-Objekte) in eine eigene Lib 'MYSYS', die ich der Bibliotheksliste (QSYSLIBL) ja vorschalten kann.
Und dann:
1. Wenn es geht einen Release-Wechsel durchführen
2. Wenn ich eine neue Maschine bekomme mit einem neuen Release dann halt nur meine eigenen Lib's (incl. MYSYS) und die nötigen Generierungen (*LIN/*CTL/*DEV/IP ...) per längst vorbereiteten (und auch aktuell gehaltenem) CLP durchführen !
PS:
Mit einem fehlenden RCLSTG hatte das übrigens alles nichts zu tun !!!
Hallo,
da gibt es ja auch noch den strobjcvn den die IBM nach dem
Releasewechsel auf ein 5 er Release empfiehlt.
Gruss TARASIK
Hallo,
hier noch ein paar Informationen:
V5R1 install
I ran into the same problem during some of the V5R1 installs that I have done. None of them were using Management Central. I'm not sure what kind of implications deleting these files will have if management central is used, so I would check into this more before deleting any of these files. I run the following 4 DLTF commands just before starting the upgrade: 1) DLTF FILE(QUSRSYS/QAYME*) RMVCST(*REMOVE) 2) DLTF FILE(QUSRSYS/QAYDS*) RMVCST(*REMOVE) 3) DLTF FILE(QUSRSYS/QAYIV*) RMVCST(*REMOVE) 4) DLTF FILE(QUSRSYS/QAYPS*) RMVCST(*REMOVE) I was told by IBM software support that this would prevent the errors from happening, and it does.
Another problem I have had is with SYS* files in QSYS2 that have end in 0001, 0002, etc. Here is what I did, also from IBM, to correct that problem. Again, I also do these just before starting the upgrade to V5R1.
1) WRKOBJ QSYS2/SYS* 2) If you see any files with a numeric extension (e.g. SYSCHK0001), rename them to their original name. The original name will be in the text over to the right. 3) If you try to rename one of these and you receive a message indicating that the file already exists, delete the ORIGINAL one and rename the one with the extension to the original name. For example, if you try to rename SYSCHK0001 to SYSCHKCST and the message says that SYSCHKCST already exists, delete the SYSCHKCST file and rename the SYSCHK0001 to SYSCHKCST.
One more thing to look out for. I always run the RCLSTG SELECT(*DBXREF) command before beginning the upgrade. I talked to IBM about this and they said it was a good idea. If this run successfully there is less chance for errors during the upgrade. If it ends with a message about QRCLAIM, report the error electronically through ECS, load & apply all *SERVICE PTF's, and try the RCLSTG command again. The times that I have encountered this, it has always fixed the problem.
I hope this will prevent some strss for someone!
Gruss TARASIK
oopsy-dear
31-10-03, 12:00
@fuerchau,
da hast du dir aber eine sysiphus-arbeit aufgehalst mit deinen dateivergleichen. M.E. muß ich doch die QUSRSYS nicht überschreiben, wenn ich keine benutzerspezifische Daten darin habe (Wer hat das?). Dann habe ich eine korrekte QUSRSYS des neuen rel. standes. Dann muß ich doch nur meine IP/ DIRE/ SCHED usw. informationen nachtragen. Das kann dann doch aber sehr aufwendig werden, vor allem bei großen Instállationen. Ich frage mich nur, ob es sinn macht, sich die entsprechenden dateien aus der alten QUSRSYS rauszufriemeln und die dann mit CPYF an die dateien der neuen QUSRSYS dranzuhängen. Ich hab das noch nicht gemacht, kann also nicht sagen, ob das funzt. Das sollte doch weniger Arbeit sein als vorher nen Rel. Wechsel auf einem alten prügel durchzuziehen, der dann vielleicht nen tag dauert. Und dann hast du das problem, das dir das keiner bezahlt! Dann kann man vielleicht noch besser das komplette alte System auf die neue Maschine spielen und dann auf der neuen nen Rel. Wechsel durchziehen, läuft dann meistens schneller!
Probleme mit konfigurationsobjekten, so wie du sie beschrieben hast, hatte ich nie. Ich spiel die aus ner 21er sicherung mit RSTCFG zurück und läuft.
Áuf jeden Fall sind wir uns einig, daß das konzept mit der QUSRSYS immer latente probleme hat und es keine ideallösung gibt. ODER??
Wie du schon sagst, Sysiphus, und wir hatten auch noch Glück dabei, da diverse Sachen mit CPYF nicht gehen (Journalisierung o.ä.). Es gab sogar Dateien, die gegen Einsicht (ausser User: QSYS) gesperrt sind (das kriegt auch nur IBM hin, DSPFD -> Lesen erlaubt: NEIN). Dafür gibts noch nicht mal ein Schlüsselwort und SQL GRANT ging auch nicht (geschweige denn CHGPF).
Die Config *DEV/*CTL/*LIN war ja auch kein Problem (stehen übrigens in QSYS). Ein Anpassung war jedoch erforderlich, da sich Ressourcen meist ändern.
Das Hauptproblem ist tatsächlich die gesamte IP-Config sowie SNADS (WRKDIRE).
Ich wollte mit meinem Bericht ja auch nur darauf hinweisen (da ja viele den Weg gehen) wo denn z.B. die neuen IP-Dienste (STRTCPSVR) geblieben sein könnten.
oopsy-dear
31-10-03, 13:07
@FUERCHAU
Ich kann mir schon vorstellen, das gewisse dinge gegen lesen und verändern geschützt sind. ´Vielleciht käme man ja auf ein geheimnisse der IBM oder, was noch schlimmer wäre, Jan und Allemann wuseln in der QUSRSYS rum und schießen da ales kreuz und quer und rufen dann beim softwaresupport an und sagen, daß nix mehr funktionert!! Aber den ultimativen Tip für Maschinenwechsel kann mir wohl doch keiner geben. Muß man wohl für jeden Fall selber checken. Schönes Wochenende!!