I’m attempting to connect to an AS/400e server running OS/400 V4R3M0 from a Windows XP machine using AS/400 Client Access V3R2M0. Although I can ping and telnet into the server on port 23, I encounter the following errors when testing the connection in Client Access:

- Errore Winsock, funzione connect codice di ritorno 10061
- Impossibile collegarsi al definitore server (porta 449) sul sistema AS/400E
- Errore di comunicazione durante la convalida delle informazioni sulla riservatezza sul sistema AS/400E

These errors suggest the “service map” server (as-svrmap), which should run on port 449, isn’t active. My NETSTAT *CNN output confirms nothing is listening on port 449:

Ind.             Porta      Porta
remoto           remota     locale      T. inat.  Stato
...
*                *          telnet     000:00:35  Ascolto
*                *          tftp       000:19:09  *UDP
*                *          1026       000:19:08  *UDP
*                *          as-cent >  000:19:29  Ascolto
...

Attempts to start the server with STRHOSTSVR SERVER(*SVRMAP) RQDPCL(*TCP) do not change this, and DSPJOBLOG shows:

3 > STRHOSTSVR SERVER(*SVRMAP) RQDPCL(*TCP)
    La specifica di instradamento con numero di sequenza 2541 esiste già.
    Il valore di confronto è in conflitto con la specifica di instradamento 2541.
    Il lavoro 604638/QUSER/QZSOSMAPD è stato sottomesso alla coda lavori QSYSNOMAX nella libreria QSYS.

I believe this is a standard warning which can be ignored since other services show similar messages on startup but successfully list in NETSTAT *CNN.

Furthermore, DSPLOG revealed that QZSOSMAPD starts and stops within a second:

CPF1124  00  INFORMAT.    Lavoro 604526/QUSER/QZSOSMAPD avviato il 21/02/24 alle 15:46:32 nel sottosistema QSYSWRK in QSYS. Lavoro immesso nel sistema il 21/02/24 alle 15:46:32.
CPF1164  00  COMPLETAM.   Lavoro 604526/QUSER/QZSOSMAPD terminato il 21/02/24 alle 15:46:32; impiegati 1 secondi; codice di chiusura 0.

This abrupt stopping is likely why as-svrmap isn’t appearing in NETSTAT *CNN. However, the reason behind this behavior remains unclear.

Finally, after listing the installed licensed programs with GO LICPGM -> 10, I verified the key related products using CHKPRDOPT PRDID(<PRDID>), all of which reported no errors.

I’m running out of troubleshooting ideas — any suggestions on how to resolve this connection issue? Thank you!