The suggestion here to put 'NOSCREEN' and 'FILE fn ft fm' in the PROFILE
TCPIP file to prevent a run away trace seemed to be so good that we decided
to put it in even tho it was just a few days before I left town for the
Christmas break. We normally run with the TCPIP console secuser'd to the
id running PROP and with sysoper privileges and didn't notice that when I
put these in place with an OBEYFILE command, that nothing was being sent to
the id running PROP. About a week after I left town, TCPIP stopped working
because the file that was pointed to with 'FILE fn ft fm' filled up the
TCPIP A-disk even tho we were not tracing anything. It's just the normal
telnet session established type of traffic. My counterpart here guessed
what the problem was and changed PROFILE TCPIP back, commenting out
NOSCREEN and FILE. Everything is fine now, but we are really puzzled. The
trace statement was 'NOTRACE ALL' which I thought meant don't trace
anything and since nothing is being traced, nothing would be put in FILE.
Has anyone else seen this? Have I just misread the doc?
Related to or caused by this, I'm coming in early this coming Sunday to
take TCPIP down, erase 'FILE fn ft fm' and restart TCPIP. I could get
write access to the disk by using a 'NETSTAT CP LINK * 191 191 RR', my
linking to the disk to erase the file, and then giving TCPIP back the disk
with another NETSTAT CP LINK command, but would it know to reaccess the
disk? It would be nice to do this on the fly and is probably necessary if
you are going to do any amount of tracing to a disk file at all.
Jim
At 03:58 AM 12/12/2005, you wrote:
Alan,
I remember this happening to me, and I didn't even start the trace
unintentionaly! :-)
When a TCPIP trace starts, by default it goes to TCPIP's console. In our
case, the problem is not so much that the spool was quickly filling up (that
can be taken care of), but the fact that we had a PROP user as a secondary
user to TCPIP. Since PROP cannot write the messages to a file on disk as
fast as TCPIP is generating them, they queue up and THAT can kill the
system. From then on, I always do a SET SECUSER TCPIP OFF before I start the
trace and/or do a trace to a file, not the console (FILE and NOSCREEN trace
statements).
This obviously won't help you if you start the trace accidentaly. Therefore,
if you do use PROP to manage TCPIP messages, put 'NOSCREEN' and 'FILE fn ft
fm' statements in the trace section of your relevant PROFILE TCPIP file.
That way you will still be able to have TCPIP messages managed by PROP,
while trace, if it accidentaly starts, will go to a file until it fills up
the minidisk. If the minidisk fills up, the trace output IS terminated.
And if you want to start the TCPIP trace to the console intentionaly (e.g.
if you need a large amount of space for the trace output and you have enough
spool space), do a CP SET SECUSER TCPIP OFF before you begin the trace and
then ocasionaly do a NETSTAT CP CLOSE CON and you'll be OK.
Cheers,
Ivica Brodaric
Tabcorp, Australia
Jim Bohnsack
Cornell Univ.
(607) 255-1760
