cancel
Showing results for 
Search instead for 
Did you mean: 

Spool error: internal error 0000000028/ 128 in spooler (Object not found)

Former Member
0 Kudos

I have a background job that reads an input file and writes errors to the spool, we are having intermtiant problems with the spool with this job. 

Most of the time this job works fine the spool thumbnail is on the job in SM37 and I an view the spool fine from SM37 or SP01.

The odd time I get spool issues, this is presented in a couple of different ways:

  1. The job in SM37 has the spool thumbnail, when I click on it to view the spool from SM37 I get the following msg:
    • internal error 0000000028/       128 in spooler (Object not found)
  2. The job in SM37 does not have the spool thumbnail, when go into SP01 I can see the spool for the job, but when I try to view it fro SP01 I get the following msg:
    • internal error 0000000028/       128 in spooler (Object not found
  3. The job in SM37 does NOT have the spool thumbnail, when go into SP01 I can see the spool for the job and I can view it fine.  The link between SM37 and SP01 does not seem to be working.

This job has been run daily for 4 months now, we have only seen this problem on 2 times.  I can take these 2 files and run them on any of our test systems and get the same result.  If I run the program in the foregound the program everything is fine.

Any ideas?

Thanks,

Jerry

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Answers (5)

Answers (5)

Former Member
0 Kudos

Hello,

I have the same issue there linked to an SAP standard program rglexe00 therefore I don't think that I can apply any development solution.

Have you found a solution to this problem ?

Best Regards, Manuel

Former Member
0 Kudos

Jerry

I just tried your code however when I use the NOCOMMIT = 'X' then the INS action does not work and I do not create the record that I need to create not sure how this is working for you ?

Former Member
0 Kudos

William, after seeing your comment I looked at this again and found that this change never made it into production.  Higher priority work came up and we had to put it back on the shelf.  Unfortunately I dont' have time to get into this now.

Here's a thought if you moved the WRITE outside of the INFOTYPE update loop can you remove the NOCOMMIT parm again?

Former Member
0 Kudos

Hi,

We encountered this same error message, where all the spool of one job were getting this error. But spools of other jobs in the system were fine.

In our case, the line size of the output is larger than the maximum width of the spool format (255 character). When we checked the source code, the source code is written in ALV (ABA List Viewer) format which is why the error occurs.

The permanent solution is to rewrite the source code from ALV to 'WRITE' commands so that the spool can be truncated to the first 255 characters and viewed in sp01.

A temporary workaround is to save the output of the report into the SapWorkDir via "Spool Report > Export as Text".

Br,

Prabhakar

Former Member
0 Kudos

Interesting in our case we were already using the write stmt.

How did the 'Spool report > export as text' work for you?  To export a spool don't you have to be in the spool request?

Former Member
0 Kudos

Having the same problem, can you share how to solve it

Former Member
0 Kudos
I usually post a reply when I have found the answer to a question I posted.  This one dragged out so long I guess I forgot.  Thanks for the reminder.
I’m trying to re-trace my steps to say how I found the solution, it’s turning out to be as difficult as finding the solution the first time.
Our problem was in a HR inbound interface program that called 'HR_INFOTYPE_OPERATION'.  The problem only occurred when the program was run in the background.  I tracked the problem down to a combination of the commit that happens in this function and the WRITE inside in the same loop seemed to cause a memory problem that appeared as a few different types of spool/TEMSE errors.  For this reason I added the nocommit parameter and moved the WRITE of the ERROR table to after the data processing loop this seemed to clear up my issue.
Originally we had:
Loop at i_tab     
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
Exporting
Nocommit      = ‘’
Importing
return        = t_returnkey           = gv_key.
If t_return in not initial
Write error msg
endif.
endloop
With this we had a couple of different problems
  1. when the internal table was large and the program is run in the background the job would run for ever; eg 12,000 records took over 8 hours and we stopped it.
    • I can't find the exact links that directed me to  the answer.  I do recall that they considered it a best practice when using the FM HR_INFOTYPE_OPEATION to follow it with a call to FM HR_PSBUFFER_INITIALIZE.
    • I did find this link, it give more details, it talks about performance issues with logical DB ogical DB http://www.saptechnical.com/Tutorials/HRABAP/Buffers/Index.htm
  2. the spool/TEMSE errors (this thread)
    • This error showed itself in a number of different ways and took a lot longer to fix. From experience and the way this error was appearing I figured it had to be an memory error.  I could not find a way to force a memory dump at particular points in the program (as I have done
      in other languages) and continue running.
    • I don’t recall exactly what directed me to this but I found the combination of the commit that happens in this function and the WRITE inside in the same loop
New version of code:
Loop at i_tab    
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
Exporting
Nocommit      = ‘X’
Importing
return        = t_return
key           = gv_key.
CALL FUNCTION 'HR_PSBUFFER_INITIALIZE'.
If t_return in not initial
Append t_return to t_error_tab
endif.
endloop
Loop at t_error_tab into w_error_line
Write w_error_line
Endloop
After this making these changes we have not had either issue.

CORRECTION - This change was NOT fully tested and did NOT make it into production.  Higher priority work came up and we have not gone back to this.  I apologize for the confusion.

Hope this helps

bxiv
Active Contributor
0 Kudos

Little late with a suggestion here, but on your sm37 screen can you issue a /osu53 and see if you have authorizations?  Or at the very least do a su53 on both sm37 & sp01 and verify that authorizations are not your issue.

Former Member
0 Kudos

Thanks, for the suggestion it did not provide any information, but it did help me with another issue I was having.