To prevent spool problems when running while GateD tracing is activated, GateD can be configured to spin off the log at specified intervals.
Depending on your environment, you may need to leave GateD tracing active in order to capture all necessary doc as a problem occurs. This has been problematic in the past as the GateD trace information can be quite extensive, causing potential problems with the JES spool, especially when the stack remains active for long periods of time.
To prevent this problem while still allowing tracing to capture problems that cannot be recreated at will, we have added the ability to spin off the GateD log in a manner similar to the SPIN parameter in the LOGGING statement for the T01LOG. The below steps outline how to implement this on your stack.
GATEDLOG Statement Syntax GATEDLOG [ CLASS( class ) ] [ DEST( destination ) } [ FORM( form ) ] [ WRITER( writer ) ] [ SPIN( [ LINES( lines) ] [ MINUTES( minutes ) ] [ SYNC ] | NOSPIN ]If you are not sure where to place this within your TCPCFG, a logical location is just below the line where you have defined your GTDCFGxx member.
//GTDLOG DD SYSOUT=&SOUT,FREE=CLOSE //GTDERR DD SYSOUT=&SOUT,FREE=CLOSEwill allow the output from both DD statements to be spun off for processing of some sort; archive, deletion from JES, etc.
GATEDLOG SPIN(MINUTES (120) SYNC)
GATEDLOG CLASS(J) DEST(RMT32) SPIN(LINES(50000) TIME(7200) )
NOTE: Once you have defined and implemented the GATEDLOG statement, changes can also be made dynamically without cycling the stack.
For complete information regarding implementation, including any messages that may appear, please refer to APAR QI61150, which contains the combined information that would normally appear in the various TCPaccess manuals.