I've way rusty on VMS, so I figured someone here can probably give me an
answer way faster than I can figure it out myself.
I brought SIGGE:: online two days ago. (VAX 7000-720). Started YCPIP
services as well. Now the disk is full. I'm guessing some logging
somewhere, as people are crazy about probing and poking. TELNET stopped
working, but I can log in fine from DECnet or LAT.
Can anyone tell me where logs go, and how to clean it up so I free some
disk.
Also, are there some known issue with the telnet server? If I telnet to
the machine, it's just constantly spewing out one character. Probably 0xff.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Johnny Billquist <bqt at softjar.se> writes:
>On 2015-08-10 16:55, Brian Schenkenberger, VAXman- wrote:
>> Johnny Billquist <bqt at softjar.se> writes:
>>
>>> Well, if I wanted then, even easier is to just set a version limit on=20
>>> the files. :-)
>>
>> Both your solution (version limits) and the periodic batch job purge will
>> not stop the unnecessary log file I/O, and both add to disk I/O and file
>> system activity. If this is a known problem with V5.1 and it's fixed in
>> V5.3, I'd suggest that you obtain that patch/version/eco and install it.
>> I, personally, loathe solutions to problems that elicit other problems or
>> increase resource loads.
>
>Agree. But besides, I do not (so far) have excessive number of
>generations of log files in the first place. I just felt that if I
>wanted to keep the number of kept generations low, I would just put a
>limit on them instead of having a batch job run regularly that did a
>purge...
Well, you're getting an implicit purge each time a new file is created with
a version limit. Probably much better than filling up a directory with log
files and then, purging but you're still purging.
>But the known problem in 5.1 that I was referring to was the total
>failure of the telnet daemon, by which is just spews 0xff after
>something manages to corrupt it. I also have a full disk, which I yet do
>now know for sure why.
>
>> FYI, eventually, your version limit solution will require intervention as
>> you inevitably crash and burn when you hit ;32,767.
>
>That is also true.
I had a client hit 32,767 on the day of the Mayan apocalypse. It wasn't the
end of the world but it was the end of their production for that day. ;)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Johnny Billquist <bqt at softjar.se> writes:
>Well, if I wanted then, even easier is to just set a version limit on=20
>the files. :-)
Both your solution (version limits) and the periodic batch job purge will
not stop the unnecessary log file I/O, and both add to disk I/O and file
system activity. If this is a known problem with V5.1 and it's fixed in
V5.3, I'd suggest that you obtain that patch/version/eco and install it.
I, personally, loathe solutions to problems that elicit other problems or
increase resource loads.
FYI, eventually, your version limit solution will require intervention as
you inevitably crash and burn when you hit ;32,767.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Johnny Billquist <bqt at softjar.se> writes:
>On 2015-08-10 15:23, Johnny Billquist wrote:
>> On 2015-08-10 15:18, Dave McGuire wrote:
>>> Where the TCP/IP logs go depends on which TCP/IP implementation you're
>>> running. Many system logs go to SYSTEM's home directory,
>>> sys$sysroot:[sysgmgr]. If you do a "purge *.log" there, that's a quick
>>> way to free up some space in an emergency. You're losing log data that
>>> way, of course, so it's a last resort, but it could get you up and
>>> running.
>>
>> The standard TCPIP from DEC. I forgot to say that it's running OVMS 7.3.
>>
>> $ tcpip
>> TCPIP> sho ver
>>
>> Compaq TCP/IP Services for OpenVMS VAX Version V5.1
>> on a VAX 7000-720 running OpenVMS V7.3
>>
>> TCPIP>
>
>Doh! I was just pointed to
>https://groups.google.com/forum/#!topic/comp.os.vms/xNVuDTj2X-E, which
>tells me that this is a known problem in V5.1 of TCPIP, which are fixed
>in V5.3. Anyone knows where I could find V5.3?
I've probably got it here.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
