LAN Console - Bildschirm bleibt schwarz

[Ratlos]

Bin leider jetzt erst dazugekommen.
Der Bildschirm mit der Adresse 0/0 ist mir immer noch suspekt. Wo die herkommt.
Steht momentan auf anhängen anstehen. Ich habe irgendwie das Gefühl, dass es damit
zusammenhängt.
In der Subsystembeschreibung QCTL habe ich in den Datenstationseinträgen (Art) 3 Einträge gefunden.
*CONS, 5555, *ALL.
Das sagt mir jetzt nichts.

[Fuerchau]

*CONS steht für Konsole(n) (siehe SST), 5555 ist ein Schrott aus Urzeiten, *ALL heißt, alle anderen Terminals sind erlaubt, d.h., wenn der eingeschränkte Zustand beendet ist könnte sich jedes Terminal am QCTL anmelden.
Wichtig ist, was z.B. als Device im Systemwert QCONSOLE hinterlegt ist, dort ist häufig DSP01 (Twinax) hinterlegt. Wenn das Device dann angehängt wird (egal durch wen, ggf. ONLINE(*YES) der DEVD anpassen) könnten damit andere Konsolen bereits blockiert werden.
Wenn du kein Twinax hast, dann hänge das Device ab und stelle es auf ONLINE(*NO) um.

[Ratlos]

Im QCONSOLE steht der DSP01. Den hatte ich vorher schon mal abgehängt, und getestet, ob es daran liegt. Leider auch nicht. Habe ihn aber jetzt aber auf ONLINE(*NO) gesetzt.
Trotzdem vielen Dank.

[hel400]

Hallo nochmals, also hier noch ein paar Details und Hintergrundinfos:

Die 3 Einträge im QCTL sind richtig (Auslieferungszustand). Wichtig dabei ist, was in den Details ("5") steht. Bei *CONS muss in der letzten Zeile (Jobeingang oder so) der Wert "*SIGNON" stehen, bei allen anderen der Wert "*ENTER".
Das bedeutet, dass die Konsole automatisch in dieses Subsystem geroutet wird (*SIGNON) - alle anderen müssen manuell (*ENTER) dorthin gebracht werden (Cmd TFRJOB, wenn man zB. gerade im QINTER ist).
Das ist also alles ok.

Nun der Systemwert: Dieser ist ja NICHT änderbar. Ich gehe davon aus, dass Ihr KEINE Twinaxschirme mehr angeschlossen habt, trotzdem kann der DSPxx auf "anhängen anstehend" oder "Anmeldeanzeige" stehen - und das ist auch RICHTIG so.
Wenn man nun am PC die Ops-Konsole startet, dann nimmt das System den im Sysval QCONSOLE angegebenen Schirm und verwendet diesen (Twinaxschirm!!) als Einheitenbeschreibung für die PC-Sitzung. Wenn Du nach erfolgreichem Verbinden den Status ansiehst (WRKCFGSTS *DEV DSPxx) dann siehst Du, dass dieser (Twinax-)Schirm als AKTIV angezeigt wird und Dein Bildschirmjob diesem Schirm zugeordnet ist.
Selbst das setzen auf Online(*NO) bringt nichts (oder wenn überhaupt dann eher das Gegenteil..), weil diese Einheit als Konsole benötigt wird!

Somit wäre eigentlich alles richtig!

Ich kann mir jetzt zB. noch vorstellen, dass der PC mit der "zweiten" (zusätzlichen) Konsolsitzung mit der vorhandenen DSP-Konfiguration nicht zusammenpasst (Tastatur etc..?) und das System (warum auch immer) diesen nicht entsprechend umkonfigurieren kann.

--> VERSUCHE daher noch Folgendes: Den DSPxx (Sysval QCONSOLE) abhängen und LÖSCHEN, danach die OPS-Konsole neu verbinden. Nun sollte der Twinax-Schirm neu erstellt werden.

Gibt's ja gar nicht, dass das nicht lauffähig wird.
(und nochmals der Hinweis: "Statusleistenprotokoll" nachsehen, ob da etwas steht)

[Ratlos]

Vielen Dank für Deine Mühe.
Dachte mir auch, dass es so was nicht gibt. Ist aber anscheinend so.
Die Werte sind so, wie Du das geschrieben hast.
Das Statusleistenprotokoll ist leer. In der Statusleiste befindet sich auch kein Zeichen.

Ich habe die Einheitenbeschreibung DSP01 aus dem Systemwert QCONSOLE gelöscht,
nachdem ich die Konfiguration gesichert hatte.
Danach die Verbindung neu aufgebaut. DSP01 wurde nicht neu erstellt.
Ergebnis wie bisher.
Dann zum Kollegen gewetzt, und bei ihm die OpConsole gestartet. DSP01 wurde neu erstellt, und er hatte einen Anmeldebildschirm.
Im Subsystem QCTL gibt es allerdings einen Autostart Jobeintrag von einem Softwarehaus. Ist mir zufällig aufgefallen, als ich nachgesehen hatte, ob ein Joblog erstellt wird. Da wird bei jedem Start der Operation Konsole ein Joblog erstellt. Steht aber nichts besonders drin.
Ich werde jetzt mal bei der IBM nachfragen. Vielleicht fällt denen was ein.
Noch mal danke, und einen schönen Abend.

[hel400]

Na bin ja mal gespannt (sehr interessantes Problem jedenfalls :-) )

2 letzte Punkte noch:

1) Wenn Du Deine Konfiguration der Ops-Konsole und die Deines Kollegen am PC ansiehst:
Zu welcher IP-Adresse verbinden sich diese Konsolen (ist das sicher dieselbe?).

2) Betriebssysteme der beiden PCs - auch identisch?
Oder hat Deiner etwa Winwows 10?

[Ratlos]

Die Lösung war ziemlich banal.
Das Service Pack der Client Access Version V7R1 war es.
Das war der einzige Unterschied.
Kollege hatte die V6R1, und ich die V7R1.

Noch einmal vielen Dank an alle.

Viele Grüße

[Ratlos]

Noch mal ein UPDATE.

Das Service Pack war es anscheinend doch nicht.
Habe heute die Konsole wieder gestartet. Das gleiche Problem wie bisher.

Dann habe ich noch mal überlegt, warum es das letzte mal ging. Ich hatte das Service Pack installiert,
danach neu gestartet. Dann natürlich gleich die Service Konsole ausprobiert.


Also habe ich nun meine 5250 Sitzungen geschlossen, und OPS-Konsole neu gestartet. Anmeldemaske war sofort da.
Dann dachte ich mir: Starte die 5250 zur OPS-Konsole. Die kamen nicht. Konsole beendet. 5250 Sitzungen waren wieder da.

Fragt mich bitte nicht, warum das so ist. Ich lasse das jetzt mal so.

[DKSPROFI]

Moin,

jetzt erinnere ich mich wieder. Die OPS-Konsole hat - zumindestens bei meinem PC - NUR alleine und niemals gleichzeitig mit einer anderen 5250 Sitzung funktioniert. Sowohl unter WIN7 als auch WIN10. Hat mich aber nicht weiter gestört.

mfg

DKSPROFI