1828663 Members
1480 Online
109984 Solutions
New Discussion

IOSB 8340 Error

 
Rockman_1
New Member

IOSB 8340 Error

This just popped up recently. Users are experiencing long delays when printing. I searched the forum and could not find this specific error message.

UCX$TELNETSYM - (PRNT) open_socket_ast invoked with bad IOSB 8340: remote node is not currently reachable

We have not made any changes to the system and have no idea why we are experiencing this network issue.

Any ideas?

Thanks everyone!
5 REPLIES 5
Garry Fruth
Trusted Contributor

Re: IOSB 8340 Error

Perhaps you have a network problem. Are you able to telnet to the printers? If they are HP printers, can you telnet to the printer on port 9100?
Rockman_1
New Member

Re: IOSB 8340 Error

These printers are on our NT network and they print fine from Windows. I don't think it is a network problem per say, but maybe a problem with the VAX server's connection to the network maybe? They do print eventually from VMS but there is a 1-2 minute wait time. Once it prints the first job though, other jobs will print right away. However, if no jobs print for a little while, the connection is lost and we have to go through the same process all over again.

Garry Fruth
Trusted Contributor

Re: IOSB 8340 Error

I would suggest trying to telnet to the printer using the same port as specified on the print queue. If it takes 1 to 2 minutes to telnet to the printer, that would rule out ucs$telnetsym.
Volker Halle
Honored Contributor

Re: IOSB 8340 Error

Rockman,

could there be a problem with DNS lookup from your VAX systems ?

Try $ UCX PING printername and $ UCX PING printer-ip-address - any difference ?

If so, check $ UCX SHOW NAME and access to the name servers.

The fact that the 2nd job prints fast, may indicate, that the problem is during connection establishment. If the IP-connection to the printer exists, printing is fast.

Volker.
Jan van den Ende
Honored Contributor

Re: IOSB 8340 Error

Rockman,

this is from memory from some time back, but I do remember a similar issue, and I _think_ that was also on M$ NT.
With us, the issue actually was on the NT side: after a job was printed, the NT print server held on to the printer for some timeout period.
So, if within that period another NT printjob was queued, it already HAD the printer, and could print immediately.
But, during the timeout period, the NT server held the printer, blocking it from serving any other connection.
We found out eventually, because Unix systems had exactly the same symptoms as VMS, and once either Unix or VMS came through, all jobs from both were processed.

This may, or may not, be what is hitting you, but it is worth investigating.

Proost.

Have one on me.

Jan
Don't rust yours pelled jacker to fine doll missed aches.