Very fast growing STDERR# File

Question

Hi experts,
I have stderr# files on two app-servers, which are growing very fast.
Problem is, I can't open the files via ST11 as they are to big.
Is there a guide, which explains what is it about and how I can manage this file (reset, ...)?
May it be a locking-log?
As I have a few entries in SM21 about failed locking.
I also can find entries about "call recv failed" and "comm error, cpic return code 020".
Thx in advance

Answer 1

Dear Christian,
Stderr* are used to record syslog and logon check, when the system is up, there should be only one being used, you can delete the others. for example, if the stderr1 is being used, then you can delete the stderr0.
stderr2,stderr3... Otherwise only shutting down the application server will allow deletion. When deleted the files will be created
again and only increase in size if the original issue causing it still exists, switching is internal and not controlled by size.
Some causes of 'stderr4' growth:
In the case of repeated input/output errors of a TemSe object (in particular in the background), large portions of trace information are written to stderr. This information is not necessary and not useful in this quantity.
Please review carefully following Notes :
   48400 : Reorganization of TemSe and Spool
  (here delete old 'temse' objects)
RSPO0041 (or RSPO1041), RSBTCDEL: To delete old TemSe objects
RSPO1043 and RSTS0020 for the consistency check.
1140307 : STDERR1 or STDERR3 becomes unusually large
Please also run a Consistency Check of DB Tables as follows:
1. Run Transaction SM65
2. Select Goto ... Additional tests
3. Select "Consistency check DB Tables" and click execute.
4. Once you get the results check to see if you have any inconsistencies
   in any of your tables.
5. If there are any inconsistencies reported then run the "Background
   Procesing Analyses" (SM65 .. Goto ... Additional Tests) again.
   This time check both the "Consistency check DB Tables" and the
   "Remove Inconsistencies" option.
6. Run this a couple of times until all inconsistencies are removed from
   the tables.
Make sure you run this SM65 check when the system is quiet and no other batch jobs are running as this would put a lock on the TBTCO table till it finishes.  This table may be needed by any other batch job that is running or scheduled to run at the time SM65 checks are running.
Running these jobs daily should ensure that the stderr files do not increase at this rate in the future.
If the system is running smoothly, these files should not grow very fast, because most of they just record the error information when it happening.
For more information about stderr please refer to the following note:
   12715: Collective note: problems with SCSA
          (the Note contains the information about what is in the  stderr and how it created).
Regards,
Abhishek