Ich hatte (habe?) ein Problem mit der Workplace-Shell.
Der Startup-Folder wurden nicht richtig abgearbeitet. X-Center und Toolbar musste ich manuell starten.
Öfter hängte sich das System gleich nach dem Starten (beim Aufbau der Workplace-Shell) auf.
Mit F1-0 habe ich bereits die Installation auf eine (früher funktionierende)
Konfiguration zurückgesetzt. Das scheint (vorerst?) geholfen zu haben.
Ich habe bemerkt, dass unter verschiedenen IDs (31 ohne CPU-Last und 108 mit CPU-Last) zwei mal pmshell.exe geladen wird (auch bei der jetzigen Konfiguration). Ist das normal oder vielleicht die Ursache meines Problems?
Die PID 31 lässt sich dabei nicht über CAD (kill) beenden.
Ein Chkdsk F über eine Parallel-Installation hatte übrigens nichts gebracht.
2xpmshell.exe
Das wird doch normalerweise seit OS/2 Version 2 in der CONFIG.SYS so festgelegt.andreas hat geschrieben: ↑Mi 1. Apr 2020, 12:28 Ich hatte (habe?) ein Problem mit der Workplace-Shell.
...
Ich habe bemerkt, dass unter verschiedenen IDs (31 ohne CPU-Last und 108 mit CPU-Last) zwei mal pmshell.exe geladen wird (auch bei der jetzigen Konfiguration). Ist das normal oder vielleicht die Ursache meines Problems?
1. PROTSHELL=C:\OS2\PMSHELL.EXE
2. SET RUNWORKPLACE=C:\OS2\PMSHELL.EXE
Dies für den beschriebenen Anwendungsfall ändern zu wollen, ist wohl nur für bestimmte Analysezwecke ratsam.
-
Martin Vieregg
- Beiträge: 459
- Registriert: Di 19. Aug 2014, 09:30
Ich würde mal schauen, ob es an den OS2\OS2*.INI Dateien liegt. Erstmal mit Checkini /C die Ini-Dateien säubern. Wenn das nichts hilft, auf einen älteren Stand zurücksetzen. (Falls nicht klar ist, wie das geht, bitte hier melden.) Deinen Fall habe ich noch nicht erlebt, aber dass pmshell.exe beim Hochfahren hängt.
Der erste Prozess lädt den PM, der zweite die WPS, also ganz normal.
Andreas Schnellbacher
Wie schon geschrieben, 2x ist richtig. Und das eine nicht killbar ist, auch. Was ich nicht verstehe ist deine Bemerkung "(31 ohne CPU-Last und 108 mit CPU-Last)". Wenn du die PID meinst, meine 2 pmshells haben nach dem Systemstart die PIDs 56 & 64. Klar, wenn du die eine Instanz killst und wieder neu startest bekommt sie eine andere, üblicherweise höhere PID. Wenn deine 2. pmshell schon nach dem Start 108 hätte, dann musstest du ungewöhnlich viele Prozesse davor in der config.sys laden.
Zum Startup-Folder Problem - suche nach checkini und cleanini (und ev. unimaint, xfix, DMT). Backup davor ist aber immer gut.
Zum Startup-Folder Problem - suche nach checkini und cleanini (und ev. unimaint, xfix, DMT). Backup davor ist aber immer gut.
Wer das OS/2 Toolkit installiert hat (ist ja bei jedem eComstation und ArcaOS dabei):
eine umfassende Erklärung findet sich im "Workplace Shell Programming Guide" unter "About Workplace Shell Processes and Threads". Ist auch für Nichtprogrammierer gut zu verstehen.
eine umfassende Erklärung findet sich im "Workplace Shell Programming Guide" unter "About Workplace Shell Processes and Threads". Ist auch für Nichtprogrammierer gut zu verstehen.
Aufruf zu dem, was Lars empfohlen hat:
Code: Alles auswählen
start view wpsguide "About Workplace Shell Processes and Threads"Andreas Schnellbacher
-
Martin Vieregg
- Beiträge: 459
- Registriert: Di 19. Aug 2014, 09:30
Ist mir noch nie aufgefallen. Im GO Prozess-Tool sieht man über die Einrückungen, dass das zweite PMSHELL vom ersten PMSHELL aufgerufen wurde. (Die Einrückungen sieht man mit TOP nicht.)Wie schon geschrieben, 2x ist richtig.
Das ist auch völlig richtig und erwartbar.
Die erste Instanz von PMSHELL.EXE wird als Konsolenapplikation im Hintergrund gestartet. Diese erste Instanz startet dann die zweite Instanz als PM Applikation. Unter anderem ist es Aufgabe der ersten Instanz, die zweite neu zu starten wenn diese abstürzt oder, wie mit XWPS machbar, beendet wird. Außerdem hat die erste Instanz noch Aufgaben beim Systemabschluss.
Die zweite Instanz macht dann den ganzen für den Benutzer interessanten Rest: sie ist quasi die Realisierung der WPS. Interessant ist hierbei, dass wenn man eine normale Applikation startet (via WPS oder per Kommandozeile), dass diese nicht als Kind der zweiten Instanz läuft sondern als Kind der ersten Instanz (damit eine Applikation nicht auch noch die ganze WPS mit sich reißen kann wenn sie abstürzt). Das kann man einfach mittels TOP nachprüfen.
Wie gesagt, steht alles in der erwähnten Programmier INF Datei.
Die erste Instanz von PMSHELL.EXE wird als Konsolenapplikation im Hintergrund gestartet. Diese erste Instanz startet dann die zweite Instanz als PM Applikation. Unter anderem ist es Aufgabe der ersten Instanz, die zweite neu zu starten wenn diese abstürzt oder, wie mit XWPS machbar, beendet wird. Außerdem hat die erste Instanz noch Aufgaben beim Systemabschluss.
Die zweite Instanz macht dann den ganzen für den Benutzer interessanten Rest: sie ist quasi die Realisierung der WPS. Interessant ist hierbei, dass wenn man eine normale Applikation startet (via WPS oder per Kommandozeile), dass diese nicht als Kind der zweiten Instanz läuft sondern als Kind der ersten Instanz (damit eine Applikation nicht auch noch die ganze WPS mit sich reißen kann wenn sie abstürzt). Das kann man einfach mittels TOP nachprüfen.
Wie gesagt, steht alles in der erwähnten Programmier INF Datei.
danke für die Antworten.
Ok, es liegt offenbar nicht an pmshell.exe.
Hatte mehrfach ini-checks durchgeführt mit den angesprochenen Programmen.
Leider hat das nichts gebracht. D.h. nach wie vor wird weder die Toolbar noch das XCenter
gestartet. Muss das jetzt immer manuell tun, wobei auch hier immer vor allem das XCenter zickt und es mehrere Anläufe braucht. Auch ein anderes Programm in meinem Startup-Folder (Watchdog) muss ich übrigens jetzt manuell starten, wird also nicht automatisch gestartet. Die sonstigen Programme im Startup-Folder starten aber wie gewohnt.
Ok, es liegt offenbar nicht an pmshell.exe.
Hatte mehrfach ini-checks durchgeführt mit den angesprochenen Programmen.
Leider hat das nichts gebracht. D.h. nach wie vor wird weder die Toolbar noch das XCenter
gestartet. Muss das jetzt immer manuell tun, wobei auch hier immer vor allem das XCenter zickt und es mehrere Anläufe braucht. Auch ein anderes Programm in meinem Startup-Folder (Watchdog) muss ich übrigens jetzt manuell starten, wird also nicht automatisch gestartet. Die sonstigen Programme im Startup-Folder starten aber wie gewohnt.
Ich hatte mal das Problem, dass das Starten solcher WPS-Apps nur verzögert funktioniert hatte. Dazu ist ein XWP-Startup-Folder geeignet, der auf "Every Desktop restart" gestellt ist. Da kannst Du dann bequem Verzögerungszeiten angeben. Teste das erstmal mit einem Objekt.
Sonst gibt's noch andere Werkzeuge und mit REXX ginge das auch.
Sonst gibt's noch andere Werkzeuge und mit REXX ginge das auch.
Andreas Schnellbacher
leider bringt die Verwendung des XWorkplace-Systemstartordners keine Abhinlfe. Auch von dort startet weder das XCenter noch die Toolbar.
Ich muss diese noch immer manuell starten, wobei es - reproduzierbar - immer mehrerer Anläufe bedarf.
Ich muss diese noch immer manuell starten, wobei es - reproduzierbar - immer mehrerer Anläufe bedarf.
Das ergibt mit der wenigen Info nicht vollständig Sinn. Das, was Du von Hand machst, lässt sich auf jeden Fall auch automatisieren.
Gut, die max. Verzögerung lässt sich nur auf 1 s + (3 s pro Objekt) stellen. Dann würd ich mal bei Herwigs RexxAutoStart nachgucken, ob das nicht auch längere Zeiten kann.
Auf jeden Fall, hat Dein System ein Problem. Früher oder später wird irgendetwas anderes nicht mehr gehen. Häufig ist eine Neuinstallation der mit Abstand schnellste Weg.
Auf meinem alten System war es z.B. die alte HDD, die unerklärliche Probleme gemacht hat. Einige wenige Dateien waren nicht mehr lesbar und es kam dann zu unerklärlichen Hängern. Bitte auch so etwas nie außer Acht lassen. Ach ja, das "neue" System, 3 ... 4 Jahre alt, aber nur einige Male mal kurz angeworfen um es zu testen, bis ich gemerkt hatte, dass nur 2 GB unterstützt werden, hatte ähnliche Probleme: Die also fast unbenutzte SSD von Kingston hatte 2 Fehler. Die Partition musste ich lang formatieren, damit sie wieder benutzbar wurde. Ich rechne jeden Moment mit weiteren Ausfällen - nicht gerade normal.
Gut, die max. Verzögerung lässt sich nur auf 1 s + (3 s pro Objekt) stellen. Dann würd ich mal bei Herwigs RexxAutoStart nachgucken, ob das nicht auch längere Zeiten kann.
Auf jeden Fall, hat Dein System ein Problem. Früher oder später wird irgendetwas anderes nicht mehr gehen. Häufig ist eine Neuinstallation der mit Abstand schnellste Weg.
Auf meinem alten System war es z.B. die alte HDD, die unerklärliche Probleme gemacht hat. Einige wenige Dateien waren nicht mehr lesbar und es kam dann zu unerklärlichen Hängern. Bitte auch so etwas nie außer Acht lassen. Ach ja, das "neue" System, 3 ... 4 Jahre alt, aber nur einige Male mal kurz angeworfen um es zu testen, bis ich gemerkt hatte, dass nur 2 GB unterstützt werden, hatte ähnliche Probleme: Die also fast unbenutzte SSD von Kingston hatte 2 Fehler. Die Partition musste ich lang formatieren, damit sie wieder benutzbar wurde. Ich rechne jeden Moment mit weiteren Ausfällen - nicht gerade normal.
Andreas Schnellbacher
Wenn du XWorkplace installiert hast solltest du prüfen ob dein Startup Folder auch wirklich ein Startup Folder ist und ob er die richtige Object ID hat:
1) rechter Mausklick auf den Startup Folder -> Properties / Eigenschaften
2) Reiter "Symbol" auswählen
2) Dann auf Knopf Details ...
3) Jetzt prüfen ob "(Klasse: WPStartup)" gesetzt ist und Objekt-ID = <WP_START>
So ähnlich funktioniert das auch mit einem XWorkplace Startup Folder nur dass hier "(Klasse: XFldStartup)" und Objekt-ID = <XWP_STARTUP> steht
Wenn entweder die Klasse nicht stimmt oder die Objekt-ID nicht richtig gesetzt ist funktioniert der Startup Folder nicht als solcher sondern ist einfach nur ein Ordner wie jeder andere auch und damit für deine Zwecke nutzlos.
Reparieren:
a) die nicht funktionierenden Startup Folder löschen. Notfalls mittels eines Setup String Objektes und NODELETE=NO; Eintrag (siehe weiter unten) als löschbar markieren. Danach sollte man es löschen können (bitte nicht in den Papierkorb !)
b) wenn die Klasse nicht stimmt: über XWorkplace WPS-Klassenliste ein Objekt des entsprechenden Typs neu anlegen
c) wenn die Objekt-ID nicht stimmt (oder nach b) ein neuer Startup Folder erzeugt wurde): über den Templates Folder ein "Setup string" Objekt auf dem Desktop anlegen. Das Objekt öffnen und im Feld "Konfigurations-String" folgendes anlegen: OBJECTID=<WP_START>;
(bzw. OBJECTID=<XWP_STARTUP>) und dann den neu erzeugten Startup Folder auf das Freifeld ziehen oder das Setup String objekt schließen und den Startup Folder auf das Setup String Objekt ziehen.
1) rechter Mausklick auf den Startup Folder -> Properties / Eigenschaften
2) Reiter "Symbol" auswählen
2) Dann auf Knopf Details ...
3) Jetzt prüfen ob "(Klasse: WPStartup)" gesetzt ist und Objekt-ID = <WP_START>
So ähnlich funktioniert das auch mit einem XWorkplace Startup Folder nur dass hier "(Klasse: XFldStartup)" und Objekt-ID = <XWP_STARTUP> steht
Wenn entweder die Klasse nicht stimmt oder die Objekt-ID nicht richtig gesetzt ist funktioniert der Startup Folder nicht als solcher sondern ist einfach nur ein Ordner wie jeder andere auch und damit für deine Zwecke nutzlos.
Reparieren:
a) die nicht funktionierenden Startup Folder löschen. Notfalls mittels eines Setup String Objektes und NODELETE=NO; Eintrag (siehe weiter unten) als löschbar markieren. Danach sollte man es löschen können (bitte nicht in den Papierkorb !)
b) wenn die Klasse nicht stimmt: über XWorkplace WPS-Klassenliste ein Objekt des entsprechenden Typs neu anlegen
c) wenn die Objekt-ID nicht stimmt (oder nach b) ein neuer Startup Folder erzeugt wurde): über den Templates Folder ein "Setup string" Objekt auf dem Desktop anlegen. Das Objekt öffnen und im Feld "Konfigurations-String" folgendes anlegen: OBJECTID=<WP_START>;
(bzw. OBJECTID=<XWP_STARTUP>) und dann den neu erzeugten Startup Folder auf das Freifeld ziehen oder das Setup String objekt schließen und den Startup Folder auf das Setup String Objekt ziehen.