Time_out dump in BackGround job

Hi experts,
I am facing an issue while scheduling a Background Job.The entire scenario is as follows.
A RFC function module has been called in the Report Program.The code inside the RFC function module is fetching a data from the database table(Select Query has been written).But in Production server system is giving the Time_out DUMP at this select Query which is written inside RFC function module.
Table is having large number of records.For this Code optimization has been done already.
Moreover entire report has been scheduled in Background.But I came to know RFC will work in Foreground only even though entire report program is scheduled in Background.
Can anyone suggest how to solve this problem?
For your information time limit has been maintained for Foreground job.

Hi, Akhil, the rfc call is of course not run in foreground, but in dialog work process. Thats the same work process type, that performs requests of dialog users. Even though it does not sound much logically in first look, it has a logic. Also other limits for dialog users will apply.
If you have to run the FM through RFC, there is no way how to bypass the dialog work process runtime limit on destination system, it will just apply, in my opinion I would recommend you don't loose your time to work around this point. afaik it does not matter if you start it synchronously or asynchronously.
But as I wrote, you can try to throw a commit work in destination system occasionally, if you can (e.g. if you are not blocked in one big select query), you can also increase the runtime limit (but for all users on the same instance). You can redesign your application...
If you will study the dump, you will find that it occurred on the destination (accounting) system, not in the calling system - where you are really ok since you run in background work process.
Also, during the active RFC call you can monitor the destination system with SM66, where you will see this running process in DIA work process with the time increasing, before it will fail.
On the other hand if you will start SM66 on caller system, you will see the work process is BTC

Similar Messages

FM ARCHIVE_SCHEDULE_JOB giving dump as background job?

Hello Everyone,
I am scheduling a report in SM37 which consists of FM ARCHIVE_SCHEDULE_JOB.
And based on the output of FM, some Ztables are updated and some jobs are created in sm37.
Now, when i debugged the background job, i found out that Fm is giving Dump 'NO_RUNTIME_INFO' since sy-batch is not initial.
Due to which Ztables are not updated but the jobs are created....
Can anyone please help me what should i do on this case?
Edited by: Suruchi Razdan on Jun 2, 2011 9:45 AM

Hi Akshay,
II have copied the Std workflow WS20000075 into a custom one and in the latest end tab, i have selected "Workitem creaton" for Refer Date/Time field and given 5 mins. I have deactivated the workflow in which i have created the containers for date and time and used "Expresion" for latest end and also commented the zmethod in delegated object. Even now also the job is getting cancelled with the same error.
Any idea why is it happening ?
regards,
Trimurty

User WF_BATCH dumps with TIME_OUT for a background task

Hello,
Situation :
While executing a workflow with a task defined as background task, the workflow creates a dump in ST22 after around 40 minutes. dump is because of TIME_OUT exception. And the workflow stays in status InProcess forever.
Question:
In my opinion background tasks do not have a time limit because they are executed as backgound batch jobs with batch user WF_BATCH. Then why do I get a TIME_OUT error ?
Is my assumption that workflow background task are just handled like other background jobs (sm36) is wrong ?
More Details :
I have a workflow with a task defined as background task (Task -> Basic Data -> Execution -> Check box 'Background processing' selected).
This task calls a method defined as 'Synchronous' method.
This method calls a ABAP FM having a select statement which selects large volume of Data.
If I execute this FM in Dialog mode definately I get a TIME_OUT. I understand this.
But what I do not understand is , while executing in background I do not expect TIME_OUT error since background jobs do not have a time limit. They can even run for several days.
Please let me know in what cases does a background job throws a time_out exception.esp wrt workflow.
Thanks in Advance
Shivanand

Check this link.
http://mailman.mit.edu/pipermail/sap-wug/2003-April/008883.html
Thanks
Arghadip

RSCOLL00 OS collector job is cancelled and getting TIME_OUT dump

Hi...
Am using ECC 5.0 , In our PRD system progaram name RSCOLL00 OS collector job and its getting TIME_OUT dump for the particular job.
And i've seen that an error SQL error 3997 occuredin that job log.
And this are the dump following search criteria
"TIME_OUT" C
"SAPLSALC" or "LSALCU16"
"SALC_MT_READ"
pls do the needful ASAP.
thanks,
Gopinath.

Hi Gopinath,
If your problem is still pending pls paste the complete dump message in this form so that we can give solution accordingly.
If you problem has been solved then mentions here complete dump message and solution which is applied by you.
Anil

Dumps generting due to background job failing

Hi Experts,
The following backround job getting failed frequently caused dumps generation,
Background running with the below program,
Dump::
Can you please some one help me on this issue.
Rgds,
Venkat

Hi All,
Thanks for your valuable suggestions.
We are investigating the issue with PI team meanwhile job has disabled.
Will update you once it resolved.
Thanks & Regards,
Venkat

Is it possible for a background program to produce TIME_OUT Dump?

Hello Experts,
When i have analyzed the Dumps using Tcode ST22 in my production system, I found many dumps.
My doubt is that, is it possible for a program scheduled to run in background to produce TIME_OUT dump?
I faced a scenario like this. What could be done to avoid this?
Can this be because of some settings problem? If so, what kind of settings has to be changed?
Thanks and Best Regards,
Suresh

Hi,
As far as time out for Background programs are concern I think there is no time out for programes executing in background
First try to improve performance of your program like read with binary search , create table index etc.
Then consult basis ppl in this regard they can set big time out slot so that your probram will not go into dump.
Regards
Bikas

SAPMSSY1 TIME_OUT dump

Category               ABAP Programming Error
Runtime Errors         TIME_OUT
ABAP Program           SAPMSSY1
Application Component BC-MID-RFC
Date and Time          03.05.2014 09:04:14
|Short text                                                                                        |
|    Time limit exceeded.                                                                          |
|What happened?                                                                                    |
|    The program "SAPMSSY1" has exceeded the maximum permitted runtime without                     |
|    interruption and has therefore been terminated.                                               |
|                                                                                                  |
|What can you do?                                                                                  |
|    Note down which actions and inputs caused the error.                                          |
|                                                                                                  |
|                                                                                                  |
|    To process the problem further, contact you SAP system                                        |
|    administrator.                                                                                |
|                                                                                                  |
|    Using Transaction ST22 for ABAP Dump Analysis, you can look                                   |
|    at and manage termination messages, and you can also                                          |
|    keep them for a long time.                                                                    |
|Error analysis                                                                                    |
|    After a specific time, the program is terminated to make the work area                        |
|    available to other users who may be waiting.                                                  |
|    This is to prevent a work area being blocked unnecessarily long by, for                       |
|    example:                                                                                      |
|    - Endless loops (DO, WHILE, ...),                                                             |
|    - Database accesses with a large result set                                                   |
|    - Database accesses without a suitable index (full table scan)                                |
|                                                                                                  |
|    The maximum runtime of a program is limited by the system profile                             |
|    parameter "rdisp/max_wprun_time". The current setting is 600 seconds. If this                 |
|     time limit is                                                                                |
|    exceeded, the system attempts to cancel any running SQL statement or                          |
|    signals the ABAP processor to stop the running program. Then the system                       |
|    waits another 60 seconds maximum. If the program is then still active,                        |
|    the work process is restarted.                                                                |
|How to correct the error                                                                          |
|    Programs with long runtime should generally be started as background                          |
|    jobs. If this is not possible, you can increase the system profile                            |
|    parameter "rdisp/max_wprun_time".                                                             |
|                                                                                                  |
|    Depending on the cause of the error, you may have to take one of the                          |
|    following measures:                                                                           |
|    - Endless loop: Correct program;                                                              |
|    - Dataset resulting from database access is too large:                                        |
|      Instead of "SELECT * ... ENDSELECT", use "SELECT * INTO internal table                      |
|      (for example);                                                                              |
|    - Database has unsuitable index: Check index generation.                                      |
|                                                                                                  |
|    If the error occures in a non-modified SAP program, you may be able to                        |
|    find an interim solution in an SAP Note.                                                      |
|    If you have access to SAP Notes, carry out a search with the following                        |
|    keywords:                                                                                     |
|                                                                                                  |
|    "TIME_OUT" " "                                                                                |
|    "SAPMSSY1" or "SAPMSSY1"                                                                      |
|    "REMOTE_FUNCTION_CALL"                                                                        |
|                                                                                                  |
|    If you cannot solve the problem yourself and want to send an error                            |
|    notification to SAP, include the following information:                                       |
|                                                                                                  |
|    1. The description of the current problem (short dump)                                        |
|                                                                                                  |
|       To save the description, choose "System->List->Save->Local File                            |
|    (Unconverted)".                                                                               |
|                                                                                                  |
|    2. Corresponding system log                                                                   |
|                                                                                                  |
|       Display the system log by calling transaction SM21.                                        |
|       Restrict the time interval to 10 minutes before and five minutes                           |
|    after the short dump. Then choose "System->List->Save->Local File                             |
|    (Unconverted)".                                                                               |
|                                                                                                  |
|    3. If the problem occurs in a problem of your own or a modified SAP                           |
|    program: The source code of the program                                                       |
|       In the editor, choose "Utilities->More                                                     |
|    Utilities->Upload/Download->Download".                                                        |
|                                                                                                  |
|    4. Details about the conditions under which the error occurred or which                       |
|    actions and input led to the error.                                                           |
|                                                                                                  |

Hi Bacon
Can you please check the user / transaction details which caused this error ? You will get that information in the dump itself.
Secondly is the dump occurring repeatedly.
From the dump details you have provided , it looks like there has been a RFC call in dialog mode which has exceeded runtime.
To resolve as a one time issue - also you have the possibility to increase the maximum run time parameter temporarily in the system
Thanks
Rishi

System exception while deleting the file from app server in background job

Hi All,
I have a issue while the deleting the file from application server.
I am using the statement DELETE DATASET in my program to delete the file from app server.
I am able to delete the file from the app server when i run the program from app server.
When i run the same report from background job i am getting the message called System exception.
Is there any secuirity which i need to get the issue.
Thank You,
Taragini

Hi All,
I get all the authorization sto delete the file from application serever.
Thing is i am able to run the program sucessfully in foreground but not in the background .
It i snot giving any short dump also just JOB is cancelled with the exception 'Job cancelled after system exception ERROR_MESSAGE'.
Can anybody please give me suggestion
Thanks,
Taragini

Job failure ( report RFFDKU00 scheduled for background job)

Hi Experts,
    When iam scheduling the report RFFDKU00 for background job. Job is getting cancelled with status "ABAP/4 processor: DBIF_RSQL_SQL_ERROR" . when iam obesrving this job it is going to dump at this select query
"     select ausbk belnr gjahr bzkey buzei
033370                  from vbsegs into table t_vbsegsfields
033380            where bukrs in r_bukrs
033390            and not ( fdlev = space
033400                  and fdgrp = space
033410                  and fdtag = init_date
033420                  and fdwbt = 0 )
033430            and not saknr in r_cm_sk   "
Can anyone helpme to deal with this issues ,
thanks in advance,
Kranthi

note 167301 might help.

Background Job " RDDVERSI" getting terminated

Hi gurus,
When we check in SM37, We are seeing a background job that is getting terminated. In the job log it says DATASET_NOT_OPEN, Job cancelled. It is trying to run "RDDVERSI" program.
It is creating a Dump in ST22 and when we check the Dump in ST22, it says "The file "/usr/sap/trans/tmp/D01V985854.P01" has not been opened".
I checked the log in the trans directory and it gives me following error. Path of the Log "usr/sap/trans/log/D01V985854.P01".
1AEPU320 See job log"RDDVERSI""07435800""P01"
1 ETP184 CREATE VERSIONS BEFORE IMPORT
1 ETP110 end date and time   : "20070912074448"
1 ETP111 exit code           : "12"
1 ETP199 ######################################
1 ETP199X######################################
1 ETP184 CREATE VERSIONS BEFORE IMPORT
1 ETP101 transport order     : "D01K985854"
1 ETP102 system              : "P01"
1 ETP108 tp path             : "tp"
1 ETP109 version and release : "340.16.24" "640"
1 ETP198
1AETR012XProgram terminated (job: "RDDVERSI", no.: "07460000")
1AEPU320 See job log"RDDVERSI""07460000""P01"
1 ETP184 CREATE VERSIONS BEFORE IMPORT
1 ETP110 end date and time   : "20070912074651"
1 ETP111 exit code           : "12"
1 ETP199 ######################################
I think when it is trying to import a transport request, it is trying to create a version of it and it is not able to create that.
Can anybody help me in solving this problem?
Any Help is appreciated
Regards,
Swaroop.

Can you run this program in the foreground with a user that has the same permissions. If you get an authorization error again, check with transaction se53 on which objects you are missing authorization.
For these objects you can create an additional authorization profile...
Kind regards,
Mark

Background Job Run - Error Msg

Hi all,
When i run my report as background job it is failing.
In report i have checked one condition n if that do not satisfy it will give error. but in any situation the background job fails though condition satifies but the spool is getin created.
when i debug the report it gives no error in that report but after it gives System message '' Job cancelled after system exception ERROR_MESSAGE''.
any guidelines will be appreciated...
regards,
vikas.

thankx for your reply..
it is not giving me any dump or something neither my report contains any popup window.
thing is that i am checking one error value at the event END-OF-SELECTION and giving some error mesg depending upon that.
when i check this in debug mode in background mode itself (thr' JDBG or SM50) the value of error mesg is empty...so idealy the report is executed fine but when after words i go for F8 it gives me that error message.
regards,
vikas

RESCCC - Generate cost collector as background job.

Hello,
I am trying to generate the cost collector. normally this is a two screen procedure. In the first screen I input the parameters and then execute it.
In the next screen the list of cost collectors appear with the red & white circle icon at the top. When I select the cost collectors and click on the icon, it generates the cost collectors and they are now ready for the next period.
We have a timeout setting of 900 seconds set in our system. As a result any foreground job that runs for more than that leads to a short dump. We cannot change this parameter.
Thats why I was trying to run the report as a background job. When I am running the background job, after a while when I am checking the status of the job I can find that the job has successfully finished.
The problem is that in this case I dont get the second screen from where I could select the cost collectors and then 'generate' them using the red & white circular icon. That screen just doesn,t come at all.
Can someone please tell me that if i run this as a background job then how may I get to the screen (the second screen) from where i can select the cost collectors and generate them?
Regards,
Suvarghya Dutta

Hello,
when RESCCC is run as background job the cost collectors for all specified settlement units should be generated without the need to select them in a second screen.
Please check that you have made the selections for settlement units and also the settlement period start and end date properly for your background job. If it still doesn't work please check the protocol of the background job for messages.
Regards, Franz

GETWA_NOT_ASSIGNED in RMVKON00 (background job)

Hello everyone
We're having the following recurring problem:
There's a job running the first of every month, it uses an ALV GRID with this statement: REUSE_ALV_GRID_DISPLAY.
When it's run normally (not scheduled) it works perfectly, but when it is scheduled we get a GETWA_NOT_ASSIGNED shortdump.
We have adjusted RMVKON00 (to ZRMVKON00) to add 2 columns to the ALV display by following the strategy of creating a work area and adding it to the ALV's internal table structure.
Function call Code
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
 EXPORTING
 i_buffer_active = space
 i_callback_program = c_repid
 i_callback_pf_status_set = c_pf_status_set
 i_callback_user_command = c_user_command
 i_structure_name = 'I_TAB'
 it_fieldcat = tab_fieldcat[]
 it_sort = tab_sort[]
 is_layout = s_layout
 i_save = c_save
 is_variant = s_variant
 it_events = tab_events[]
 TABLES
 t_outtab = i_tab.
I_TAB setup
TYPES: BEGIN OF watype,
 mandt LIKE rkwa-mandt,
 mblnr LIKE rkwa-mblnr,
 mjahr LIKE rkwa-mjahr,
 zeile LIKE rkwa-zeile,
 status LIKE rkwa-status,
 bldat LIKE rkwa-bldat,
 budat LIKE rkwa-budat,
 bukrs LIKE rkwa-bukrs,
 sobkz LIKE rkwa-sobkz,
 lifnr LIKE rkwa-lifnr,
 werks LIKE rkwa-werks,
 matnr LIKE rkwa-matnr,
 shkzg LIKE rkwa-shkzg,
 gsber LIKE rkwa-gsber,
 bwaer LIKE rkwa-bwaer,
 wrbtr LIKE rkwa-wrbtr,
 bstme LIKE rkwa-bstme,
 bstmg LIKE rkwa-bstmg,
 hkont LIKE rkwa-hkont,
 mwskz LIKE rkwa-mwskz,
 belnr LIKE rkwa-belnr,
 gjahr LIKE rkwa-gjahr,
 buzei LIKE rkwa-buzei,
 navnw LIKE rkwa-navnw,
 prctr LIKE rkwa-prctr,
 text LIKE zconalv-text,
 name1 LIKE lfa1-name1,
 maktx LIKE makt-maktx,
 END OF watype.
DATA: alv_itab TYPE watype.
I_TAB fill in FORM alv_list
Fill itab with current rkwa table, and add corresponding
Vendor name & Material Desc.
DATA: i_tab TYPE TABLE OF watype,
 i_tabRow TYPE watype.
LOOP AT t_alv_list.
MOVE-CORRESPONDING t_alv_list TO i_tabRow.
SELECT SINGLE name1 INTO i_tabRow-name1
FROM LFA1
WHERE lifnr = t_alv_list-lifnr.
SELECT SINGLE maktx INTO i_tabRow-maktx
FROM MAKT
WHERE matnr = t_alv_list-matnr.
INSERT i_tabRow INTO TABLE i_tab.
This is an extract of the shortdump:
Transaction......... " "
Program............. "SAPLKKBL "
Screen.............. "SAPLKKBL 0500"
Screen line......... 3
Information on where termination occurred
The termination occurred in the ABAP/4 program "SAPLKKBL " in
"CHECKBOX_OUT".
The main program was "ZRMVKON00 ".
The termination occurred in line 1148
of the source code of program "LKKBLF01 " (when calling the editor 11480).
The program "SAPLKKBL " was started as a background job.
Any help is much appreciated.
Edit: shortdump extract added
Message was edited by: Tim Schraepen

I have found the thing that was causing the error!
If you look at the short dump it says something about program LKKBLF01 on line 1148.
I went to take a look at that line.
 if not r_sum is initial or <box> = '-'.
That <box> statement got me thinking that the layout could be the cause, so I commented out the layout parameter line like this:
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
 EXPORTING
 i_buffer_active = space
 i_callback_program = c_repid
 i_callback_pf_status_set = c_pf_status_set
 i_callback_user_command = c_user_command
 i_structure_name = 'ZRKWA'
 i_structure_name = 'T_ALV_LIST'
 it_fieldcat = tab_fieldcat[]
 it_sort = tab_sort[]
* is_layout = s_layout i_save = c_save
 is_variant = s_variant
 it_events = tab_events[]
 TABLES
 t_outtab = i_tab.
 t_outtab = t_alv_list.
And it worked!
Here's an important note I found in the documentation about that parameter:
Interaction
box_fieldname
Value range: SPACE, field name of the internal output table
If the list should have checkboxes at the beginning of each list row (to allow the user to select multiple rows at once), you must fill this parameter with the field name of the internal output table that represents the selection column for selecting rows with the help of checkboxes.
The field is always displayed as a checkbox at the beginning of each list row without a list heading.
I don't know why this has something to do with it, but my problem is solved. I will look into it further and update when I've found a better solution.
Thank you for all your help Christian.
I really appreciate it.

Page-break in alv background job for alv output variant not coming correctl

Hi,
I have created an ALV grid report. When i run the report in background i get the output with correct page-break on FIELD1. Now when i run the report in background with an "ALV output variant" (its the ALV variant that controls the fields display in the output; this is not the program variant), i do not get the page-break on FIELD1. I have already build the sort criteria and using:
gs_sort-group = '* '. "New-Page
Please let me know what could be reason for not getting the page-break in background when i am using the alv output variant and how do i correct this problem.
Regards,
Rakesh

Hello Everyone,
I have solved the problem. While running the program in background, we get the page-breaks when we use the below part of code in the sort catalogue with the condition that the program variant should not use any ALV layout variant.
gs_sort-group = '* '. "New-Page
If you are using the ALV layout variant in the program variant then we can check the ROWPOS, COLPOS, and NO_OUT for that ALV layout variant and pass them along in the fieldcatalog table. You should be careful with not to pass the layout variant in the DISVARIANT. You can notice that i have cleared it and simply passing the program name into that.
*C-- Process separately for jobs running in Background. Actually
*C-- sortcat-group solves the problem only in Foreground. In background
*C-- when ALV layout variant is not selected then it works otherwise it
*C-- fails. So for background jobs we are reading the fieldcat and then
*C-- passing the same in the display FM.
IF sy-batch = 'X'.
 CALL FUNCTION 'REUSE_ALV_VARIANT_SELECT'
 EXPORTING
 i_dialog = ' '
 i_user_specific = ' '
 i_default = ' '
* I_TABNAME_HEADER =
* I_TABNAME_ITEM =
 it_default_fieldcat = gt_fieldcat
 i_layout = gs_layout
* I_BYPASSING_BUFFER =
* I_BUFFER_ACTIVE =
 IMPORTING
* E_EXIT =
 et_fieldcat = lt_fieldcat
* et_sort = gt_sort[]
* ET_FILTER =
* es_layout = gs_layout
 CHANGING
 cs_variant = gs_disvariant
 EXCEPTIONS
 wrong_input = 1
 fc_not_complete = 2
 not_found = 3
 program_error = 4
 OTHERS = 5
 IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
 ENDIF.
 CLEAR gs_fieldcat.
 LOOP AT gt_fieldcat INTO gs_fieldcat.
*C-- Transfer all position changes to gt_fieldcat from lt_fieldcat
 CLEAR ls_fieldcat.
 READ TABLE lt_fieldcat
 INTO ls_fieldcat
 WITH KEY fieldname = gs_fieldcat-fieldname.
 IF sy-subrc = 0.
 gs_fieldcat-row_pos = ls_fieldcat-row_pos.
 gs_fieldcat-col_pos = ls_fieldcat-col_pos.
 gs_fieldcat-no_out = ls_fieldcat-no_out.
 MODIFY gt_fieldcat FROM gs_fieldcat INDEX sy-tabix.
 CLEAR gs_fieldcat.
 ENDIF.
 ENDLOOP.
*C-- Clear the disvariant for the background job as it contains the ALV
*C-- layout varinat
 CLEAR gs_disvariant.
 gs_disvariant-report = 'ZGPPMP0001'.
Then pass gt_fieldcat to 'REUSE_ALV_GRID_DISPLAY'.
The reason i'm doing it this way is that when we pass the layout variant name, the contents in gt_fieldcat were getting modified.
One more thing i'd like to point out is that that, i tried to delete the fields with no_out = 'x'. Now when i ran the program in background with all the fields in sort catalog (suppose there are 2 fields field1 and field2) also in fieldcatalog it ran fine. In the next run in background i removed one of the fields in sort catalog from the fieldcatalog (delete the fields with no_out = 'x') and i got dump. Basically i had hidden field1 and so the code which was deleting fields with no_out = 'x' deleted this field from gt_fieldcat. So basically we should not delete fields with no_out = 'x'.
I was getting ABAP runtime errors MESSAGE_TYPE_X in the following part of the standard code.
000310 LOOP AT CT_SORT INTO LS_SORT.
000320
000330 READ TABLE IT_FIELDCAT ASSIGNING <LS_FIELDCAT>
000340 WITH KEY FIELDNAME = LS_SORT-FIELDNAME BINARY SEARCH.
000350 IF SY-SUBRC NE 0.
 > MESSAGE X000(0K).
000370 ENDIF.
000380
000390 LS_SORT-SELTEXT = <LS_FIELDCAT>-SELTEXT.
i have just mentioned this part because when i checked the forum many people were getting such errors "MESSAGE_TYPE_X". This could also be one of the reasons.

DYNPRO_SEND_IN_BACKGROUND when submitting a background job, when creating a

Hi.
We create sales orders via EDI. When certain sales orders are created, we execute user exists on the Sales Order save. During the User Exit, we submit/create (job_open_adk function, the submit command, and the job_close_adk function) a background job.
The background, is created and executed successfully, but we get 2
short dumps everytime.
The short dump is:
DYNPRO_SEND_IN_BACKGROUND
The description is:
Screen output without connection to user.
The short dump is for the user WF-BATCH.
I've used DEBUG and the shortdump occurs on the submit command.
submit zsd
to sap-spool
destination 'null'
immediately ''
keep in spool 'X'
without spool dynpro
and return
user l_user via job tbtcjob-jobname
number tbtcjob-jobcount
with p_vbeln = l_order
with p_ebeln = l_po
with p_uname = l_user.
Nothing should be displayed on the screen.
I used 'without spool dynpro' to prevent the 'Print Screen List' window
from appearing.
I've put this code into a TEST program. I ran the test program
myself. (under my ID) The program run perfectly. No
shortdump.
Similar code is used in other programs and it works perfectly - no shortdumps.
The short dump occurs when we use ALE/EDI to create a sales order.
The short dump has the ID WF-BATCH on it.
I'm guessing the problem is with the WF-BATCH ID. Are printer setting
missing on a Work Flow ID?
Any ideas why the 'without spool dynpro' parameter doesn't work for the
WF-BATCH ID?
I've tried searching OSS and I looked at the on-line help/documentation
on Submit. I saw a recommentation to use the
fuction 'GET_PRINT_PARAMETERS' to set all of the print parameters. I
tried this, but still got the short dumps.
Any suggestion on how I can run the Submit command and not get a short dump?
thanks,
Michelle

Hi,
Try this notes:
0100915 RSBDCREO: System hangs or parameters not effective
0377038 HR-CA-ALE: DYNPRO_SEND_IN_BACKGROUND for HR doc. d
0105165 Dump "DYNPRO_SEND_IN_BACKGROUND" in prog.SAPMSSY0
0169303 Warning messages displayed for settlement mass pro
0428489 VL10: Dump 'DYNPRO_SEND_IN_BACKGROUND' with backgr
[[http://forums.sdn.sap.com/thread.jspa?threadID=14875|http://forums.sdn.sap.com/thread.jspa?threadID=14875]]
Regards
HM

Time_out dump in BackGround job

Similar Messages

Maybe you are looking for