AS/400.. er uit, niet meer er in..

[Beat691]

We hebben hier op me werk een AS/400 staan we hebben de laatste tijd het probleem dat we niet meer via telnet de as400 in kunnen, maar de mensen die er in zitten die blijven er in tot dat ze er uit gaan, dan kunnen ze er niet meer in, connection refused.
Het gaat soms weken goed, en op een begeven moment komt hij met deze fouten
De as400 wordt elke nacht gereboot.... na reboot werkt het dus gewoon weer.
Pingen kunnen we de as400 nog wel en via het scherm dat naast de as/400 staat kunnen we er nog wel in(volgens mij gaat die over twinax) de gebruikers gaan via tcpip.

Heeft iemand enig idee wat dit kan zijn ?

Ik weet niet of versie en type van belang zijn, die weet ik namelijk niet, als dat van belang is zou ik dat eind van de middag even na moeten vragen...

[ Voor 12% gewijzigd door Beat691 op 08-06-2004 14:34 ]

[Equator]

Dat scherm dat naast je AS/400 staat is het console.. Die blijft meestal wel werken.

Ik heb het idee dat je netwerk niet lekker werkt.

...dan kunnen ze er niet meer in, connection refused.

Krijg je die zodra je probeert te connecten, of pas na het invoeren van username/password combo..

[Freee!!]

Heel stomme vraag misschien, maar waarom gebruiken jullie geen Client Access (of zelfs CA Expres) om verbinding te maken met die AS/400

Verder denk ik dat het wel heel nuttig is om het versie-nummer van de OS te weten (V?R?M?).

Nog een puntje: Zijn jullie bij met PTF's?

[Bas!]

Je rootconsole heeft niet zoveel met je netwerk van doen. Ik weet niet zo veel van as/400. Dit soort opmerkingen krijg je onder unix als je service die de connectie opzet dood is. Meestal gaat dit via inetd, maar het kan ook direct aan telnetd zijn. Inetd lijkt me logischer. Ik zou eens kijken of dat nog draait als je connection refused krijgt en het anders eens opstarten.
Dit alles onder voorbehoud, ik ken geen as/400, maar ik neem aan dat het niet ver af ligt van hoe unices en hun klonen het doen. (van solaris en AIX tot aan bsd en linux doen het zo)

[Freee!!]

Bas! schreef op 08 juni 2004 @ 15:08:
<fraai verhaal>

OS/400 is totaal niet met UNIX te vergelijken (nog even afgezien van het feit dat de AS/400 een EBCDIC-machine is).

[DiGyPh0]

Als je Client Access (Express)/iSeries Access gebruikt check dan eens of je hostservers wel gestart zijn.
In ieder geval moeten *signon en *central gestart zijn.
Dit kan je zien in iSeries Navigator, of als secofr inloggen en strhostsvr *signon uitvoeren. Of om zeker te zijn strhostsvr *all.

[Mark]

En als laatste, mocht je Client Access (al dan niet Express) gebruiken, hoe zit je met je licenses ?

Mr. Liu schreef op 08 juni 2004 @ 15:44:
[...]

OS/400 is totaal niet met UNIX te vergelijken (nog even afgezien van het feit dat de AS/400 een EBCDIC-machine is).

Dat zou ik niet te hard roepen. OS/400 en AIX gaan steeds dichter tegen elkaar zitten. Ontwikkelaars van OS400 (welke ik laatste tijd weer eens spreek vanwegge betatesten van v5r3m0) beweren dat 75% van beide systemen onder de motorkap al gelijk is

[ Voor 71% gewijzigd door Mark op 08-06-2004 18:54 ]

[mvdejong]

Ik ben UNIX-man, geen OS/400-man, maar als ik dit in een UNIX-omgeving tegenkom betekent het meestal dat als iemand uitlogt uit de telnet-sessie, de TCP/IP-verbinding in zijn laatste fase van afsluiting (FIN_WAIT_2) blijft wachten op een afmelding van de andere kant (terecht), maar te lang doet over een timeout (onterecht). Het gevolg is dat er een slot in de session-table open blijft, en op een gegeven moment is die vol.

Dit is op te lossen door een parameter in het OS danwel TCP/IP-stack aan te passen om een aanvaardbare timeout in te stellen. Let wel op dat als je die te kort stelt, de telnet-client een probleem kan krijgen, dus hou die timeout wel op enkele 10-tallen seconden, maar niet op het halve uur wat hier vaak de default voor is (en ook geen probleem geeft als de clients netjes afsluiten).

[SambalBij]

Dit zou kunnen duiden op een probleem met de display devices.
Kijk eens of je in de berichten van de QSYSOPR een melding ziet die het probleem verklaart.
Misschien zijn er geen devices beschikbaar om wat voor reden dan ook (sessie wel netjes afgemeld en beeindigd?)
Hoe staat de system valuu QAUTOVRT ingesteld?
Heb je, op het moment dat het probleem optreedt, nog QPADEVxxxxx devices staan op Vary on pending?