Error 3 after OPEN DATASET if big data volume is processed, none otherwise

2
votes

The problem is that I received a ticket from the AMS support team, which I cannot debug because for given input parameters on the selection screen, the program is looping for 10 hours and that's why the program is set as a background job.

The point of the program is that it should save some data in xls file on the application server.

The important thing is that for some input parameters on the selection screen program WORKS (smaller date intervals, also fewer data to work with), but right now I have to explain to the consultant why the program cannot write that much data into the file on the application server.

To conclude, a Background job is linked to the program which is grabbing a lot of data from DB, in some cases when there is an enormous amount of the data, the program cannot open the file for output so there is no data in xls.

My question is, how big the limit for OUTPUT mode in OPEN DATASET is and why I get an "error opening file" when I have bigger intervals in the selection screen. 

OPEN DATASET lv_file FOR OUTPUT IN TEXT MODE ENCODING NON-UNICODE
  IGNORING CONVERSION ERRORS.
  IF sy-subrc EQ 0.  "PROGRAM FAILS HERE, SY-SUBRC eq 3
  |
  |

The program works when we select fewer data from DB, I have to provide the answer to the question: "why it fails when I grab a big amount of data.

Error in dialog mode :

error in dialog mode

Error in background mode :

error in background mode

1
abap
It's very surprising that sy-subrc = 3 because the ABAP documentation says that it may return only 0 or 8. An error at OPEN DATASET only in the context of high memory usage may think that it's related. Anyway, you should in parallel contact the SAP support to mention this weird issue. - Sandra Rossi
Hi, is there something provided in the following fields sy-msgno, sy-msgid, sy-msgty, sy-msgv1, sy-msgv2, sy-msgv3, sy-msgv4? - Jagger
It seems some other statement producing the 3 sy-subrc, try to add message clause to OPEN DATASET statement to produce more feedback - Suncatcher
In SM51, double click the second application server, that will open a new user session connected to that server and run your program in dialog mode with the small data set, so that to make sure SAP can write to the folder in that server too (both servers usually define each a soft link to a shared folder). Note that you can also see in which application server a job has been executed, by displaying its details (transaction code SM37). - Sandra Rossi
@SandraRossi I checked your proposal, the jobs which were finished correctly were pointing to one server, and jobs which were finished incorrectly were pointing to another server in which I don't have the authorization to open that folder in al11. I told my consultant to check with the client basis team about giving authorizations for that folder so i am waiting for respond from them. - Duhac

1 Answers

2
votes

UPDATE: this answer assumes that the original direction ("because of data volume") was based on a misinterpretation of what happened, because of a simple coincidence. It often happens, but I may be wrong of course. This assumption is based on the latest OP comment: "What i found interesting, that on the background job list, if there are 3 jobs for that user, two of them have failed and the target server was the 2nd one,but there is one job which succeeded in opening the file, his target system is system #1, but the difference is that that job had duration of ~1 hour and not 10 hours like two others.")

When you run a background job and there's an error opening a file from time to time, it may be due to the fact that you have an ABAP system with several application servers, and that one of them (at least) is not configured correctly to map a given folder to a "network" folder shared by all other application servers.

To make sure, you can see in which application server the failed job has been executed, by displaying its details (transaction code SM37). Then run the program twice, once in the application server where a job failed, once in the application server where a job succeeded, with the same input parameters.

It should succeed and fail accordingly.

To run a program in a given application server, there are two solutions:

  • Either start a job by indicating the desired target application server
  • Or switch your SAP GUI user session to the application server you want:
    • Use SM51 to display the list of all application servers
    • double click the concerned server
    • that opens the overview screen in a new user session started in that server
    • Enter /NSE38 in the command field and start the program in dialog (it will run in that server).

Now that it's almost certain this is the cause, you should ask the administrator to correct the issue, that in the given application server, he should add a "mapping" from the file folder to the shared folder (do the same as he did in other application servers).