SYS$QUEUE_MANAGER Stopped and FTP service stopped working

[Navipa]

All,

we have VAX 4000-50/OpenVMS 6.1 and TCPIP (UCX) v3.2.

Due to disk space issue, the sys$queue_manager stopped working and waiting to get the free space released. We released diskspace and que manager started working, but we were not able to FTP to the server from windows using ws_ftp, but we could able to Telnetg, but after rebooting the server, we were able to FTP to and from the VMS server. I don't see any enties in the UCX$FTPD log, but there was a user process (show sys) which was holding UCX$FTPC_4356 for many hours. Any idea?

[KIP]

Interesting and glad it is working fine for you now.  

Here's a possiblility to explore:

Any part of the procedures that would involve queues would have stopped without queue manager running. 

For example:

If your FTP procedures include any email notifications then the hold-up could be releated to the "SMTP" queue that would have been stopped with queue manager not running:

__

VMS $> sh que tcpip$smtp*/full
Generic server queue TCPIP$SMTP
/GENERIC=(TCPIP$SMTP_CLUS_N1,TCPIP$SMTP_CLUS_N2) /OWNER=[1,4] /PROTECTION=(S:M,O:D,G:R,W:S)

__

I found this once when our smtp queues were stopped inadvertanly and no Exchange Emails were going out from OpenVMS as a result.

Once the queues were started all pending items processed fine.

FWIW

Regards,

Kip

[Hoff]

Not sure what you expect, here...

What happens when OpenVMS and TCP/IP Services runs out of space has always been indeterminate.

Errors in code paths that don't usually get errors tends to reveal latent bugs in OpenVMS and in TCP/IP Services, after all.

Log files can't be reliably written in these out-of-space events, either.

Instrument your system and detect and try to warn on pending low-space conditions, if you can.   Unfortunately, sometimes these cases happen fast when something runs away while writing,  and there's not much that can be done.   But at least the more usual gradually-filling-disk cases can be given some advanced warning, and maybe avoid the outage.   Some DCL that runs periodically — every fifteen minutes or once an hour — that starts squawking when some locally-defined percentage of total capacity is reached, or such.

Out of curiousity, what's with all the decades-old software versions getting posted around here lately?   That VAX 4000 model 50 is a collectors item, too — those were rare.   Time to look at replacements — either emulation or at Itanium, or maybe at x86-64 native when VSI finishes with that port.