cancel
Showing results for 
Search instead for 
Did you mean: 

/SAPAPO/TS_BATCH_RUN -DYNPRO_SEND_IN_BACKGROUND dump

0 Kudos

Hi Gurus,

I am running a macro mass processing  job via /SAPAPO/TS_BATCH_RUN. When this job is run through a system user id the spool gives out the following warning message "Characteristic of selection not part of aggregation level " , the job log gives the following message" Screen output without connection to user " and a SM21 log is generated (Dump Attached ) .

However when the same is run through a dialog user id the job runs successfully executing the macros.There is no authorization issue here as the system user id has the all powerful SAP_ALL profile . Since Jobs are not recommended to be run with dialog user ids we have to use the system user id only here. When I run the macro interactively in foreground I do not face any problem .

The SM21 log points to a 'DYNPRO_SEND_IN_BACKGROUND' run time error which dumps at a call screen statement. This is definitely the root cause here as when using a system user id in background call screen will surely not work , and will obviously work in dialog . But I need this to be working  with the system user id . In fact the same thing was working  last week but I think somewhere something got changed which is leading to this problem .

Any hints please ?

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Hari,

      I wasn't sure in your description, but did you try logging into the system using background user id and running the job on-line? You'd have to re-set the user-id to dialog (work with BASIS). This may be an authorization issue. If it is, then the process will fail with the background job user. You can then run an SU53 and ask the Security group to provide the proper authorization for this user.

Regards,

Roger Weinberg

0 Kudos

Hello Weinberg ,

Just found the solution. No need to reset the user to dialog . The propagation range for the background user id was not set to SAPALL.I added this in the /SAPAPO/RRP_AUTH table . Now it works as expected.

Like you mentioned I guess running the  job interactively with the background user id would have also solved the problem . I always ran it interactively with my id .

Thanks !

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Lakshmi,

Hi Lakshmi,

It’s great to hear that the problem is resolved.

The authorizations of the background user id is a common issue for both background jobs and for transaction flow via CIF.

I look forward to corresponding with you in the future. 

Regards, Roger Weinberg