The real problem was not that the trace file filled up with trace
output. It only had normal console output in it. I'd like that to go to
the console, or in this case SECUSER.-- not the trace output file. Maybe
the fact that TCPIP quit when the trace file filled up was because it may
have been the trace function (only) that looks for a full trace file.
Jim
At 08:07 PM 1/5/2006, you wrote:
On Thursday, 01/05/2006 at 04:06 EST, Jim Bohnsack <[EMAIL PROTECTED]>
wrote:
> 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.
No, the stack will not reaccess the disk. Leave the disk R/W to TCPIP. In
your OBEYFILE, the first thing you do is NOTRACE ALL followed by "FILE
DUMMY FILE". The FILE directive causes the stack to close the current
trace file, making it visible to those with R/O links. You can copy it,
browse it, whatever you want. When you start the trace, precede it with
"FILE TRACE FILE" or whatever you were using before. It will close DUMMY
FILE, which doesn't have anything it it (in theory!!) and erases the
existing TRACE FILE before it starts to write.
BTW, we fixed the stack a long time ago to gracefully handle disk-full
conditions. If TCPIP abends or otherwise dies because the trace file is
full, feel free to open a PMR. It ain't s'posed to do that!
Alan Altmark
z/VM Development
IBM Endicott
Jim Bohnsack
Cornell Univ.
(607) 255-1760
