1. Spool Overflow:
There are a limited amount of spool numbers in the spool system. These spool numbers are then re-used for new spools after spools are deleted.
If all spool numbers are used, then no new spools can be created and you will get SPOOL_INTERAL_ERROR(SPOOL OVERFLOW) errors. This can cause update processes to be blocked and can slow down or block the entire system in extreme cases. At the very least no printing is possible from the system.
The following actions are needed to resolve this and prevent a re-occurance:
1. Log on to the system in client 000 change the spool number range to 999,999 via transaction SNRO:
SNRO -> Change -> Click on button 'Number Ranges' -> Click on button Change 'Intervals'. In the "To No." column, change the upper limit of the interval SPO_NUM to 999,999. The value has no meaning in any other client than client 000.(see SAP note #48284)
2. Ensure that you daily spool deletion and consistency check jobs(reports RSPO1041 and RSPO1043) run daily with a suitable variant. The default retention period for spools is 8 days. You can increase or decrease this in the variant of the RSPO1041 job. You need to take into account the number of spools created each day, the required retention period and the spool number range setting.
3. There was a known issue with spools being incorrectly created with a deletion date 'Do not Delete'. This is described in SAP note #1422843 and is resolved by a kernel patch. A workaround is also described in the note.
2. Invalid writer-count:
In this case the dump is caused by locks on spool requests being deleted by spool consistency check for spools belonging to long running BTC jobs.
This can be for 2 different reasons:
- The spool consistency check job with report RSPO1043 or RSPO0043 is running with a variant with a variant where the setting "Release locks after .. minutes" is shorter than the default setting '10080'.
- Somebody is running the spool consistency check directly from transaction SPAD
When this setting is lower, then the problem can occur when the locks are deleted for a BTC job that is still running
The solution is to apply the code correction of SAP note #16534. The code correction ensure that 10080 is set as the default for write locks in report RSPO0043. This report is also ran when running the consistency check from SPAD.
The standard value for RSPO1043 is 10080 minutes, which is seven days. The problem should not occur with this value as usually no batch jobs will have a runtime of seven days.
In addition ensure that the variant in the daily deletion job does not have a setting shorter than the default setting '10080'.
3. No more memory for open spool:
You can haveSPOOL_INTERNAL_ERROR or SPOOL_NO_CONVERSION with this error. in the system log you may see R2B errors. Also in the work process trace file, there are errors 'ERROR => EmIAllocMmResourceEg: EgAlloc(.... '.
This error indicates that the global part of the extended memory is exhausted. Within the extended memory aallocation, there is a section reserved for global data like printing that are user-independent and work process-independent.
The amount of extended memory reserved for global tasks is controlled by the parameter em/global_area_MB.
For this problem, you need to increase the parameter em/global_area_MB as per SAP note #329021. In newer releases it may be possible to increase the parameter further if necessary.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.